[MacPorts] #67882: m4 @1.4.19_1: Installation fails with file name too long error

[MacPorts]

#67882: m4 @1.4.19_1: Installation fails with file name too long error
------------------------+--------------------
  Reporter:  nathanpc   |      Owner:  (none)
      Type:  defect     |     Status:  closed
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:  2.8.1
Resolution:  duplicate  |   Keywords:
      Port:  m4         |
------------------------+--------------------

Comment (by ballapete):

 `Paul Eggert` seems to have the solution:
 https://lists.gnu.org/archive/html/bug-gnulib/2022-01/msg00085.html. I
 fail to understand…

 The `C test programme` is:

 {{{
  1        if (1)
  2          {
  3            static char const dir_name[] = "confdir-14B---";
  4            size_t desired_depth = ((TARGET_LEN - 1 - initial_cwd_len)
  5                                    / sizeof dir_name);
  6            size_t d;
  7            for (d = 0; d < desired_depth; d++)
  8              {
  9                if (mkdir (dir_name, S_IRWXU) < 0 || chdir (dir_name) <
 0)
 10                  {
 11                    if (! (errno == ERANGE || errno == ENAMETOOLONG
 12                           || errno == ENOENT))
 13                      fail = 3; /* Unable to construct deep hierarchy.
 */
 14                    break;
 15                  }
 16              }         /* end of for loop */
 17
 18            /* If libc has the bug in question, this invocation of
 getcwd
 19               results in a failed assertion.  */
 20            cwd = getcwd (NULL, 0);
 21            if (cwd == NULL)
 22              fail = 4; /* getcwd didn't assert, but it failed for a
 long name
 23                           where the answer could have been learned.  */
 24            free (cwd);
 25
 26            /* Call rmdir first, in case the above chdir failed.  */
 27            rmdir (dir_name);
 28            while (0 < d--)
 29              {
 30                if (chdir ("..") < 0)
 31                  {
 32                    fail = 5;
 33                    break;
 34                  }
 35                rmdir (dir_name);
 36              }         /* end of while loop */
 37          }
 }}}

 On line #9 it first creates the subdirectory and, when successful, changes
 into it. If it had no success it breaks out of the for loop.

 On line #20 a pointer to the pathname of the last directory created is
 stored in array cwd. If pathname could not be determined, the NULL pointer
 is returned. This is tested in the next two lines and the storage for
 pathname gets cleared (free'd), line #24.

 On line #27 a possibly not existing sub-directory ("confdir-14B---") is
 removed. Can this work? Does it provoke the report "…: No space left on
 device"?

 On line #28 starts a while loop in which the current working directory is
 changed to the parent directory ("..") and if successful the now sub-
 directory "confdir-14B---" is removed (line #35), otherwise an error is
 raised and the while loop is quit at one (line #30–33).

 Is my interpretation correct? Which is the test Paul Eggert sees but not
 me?

 IMO `rmdir()` seems to fail. So why not leaving out (patching away) the
 line #26–36 and doing the clean-up in two steps (mv branch to X, then rm
 -rf remaining confdir-14B--- and X) with reliable system utilities? There
 also seems to be difference in the behaviour of `rmdir()`: Inside the
 MacPorts environment it tends to fail while in some user's environment it
 seems to succeed?

 I cannot see any reason for a new bug report…

-- 
Ticket URL: <https://trac.macports.org/ticket/67882#comment:3>
MacPorts <https://www.macports.org/>
Ports system for macOS