[MacPorts] #65569: emacs and legacy-support: `openat` broken?

[MacPorts]

#65569: emacs and legacy-support: `openat` broken?
-------------------------+-------------------------------------------------
  Reporter:  lemzwerg    |      Owner:  drkp
      Type:  defect      |     Status:  assigned
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:
Resolution:              |   Keywords:  lion mountainlion snowleopard
      Port:  emacs       |  mavericks
  legacy-support         |
-------------------------+-------------------------------------------------

Comment (by acjones8):

 Out of curiosity, I've tried compiling Emacs 29.1 for 10.5 PPC, and I ran
 into this bug as well. Truth be told, I don't think I have enough
 experience to solve this on my own, but I tried debugging `temacs` and
 `legacy-support` with GDB, and I may have found a few clues.

 The issue starts in `src/callproc.c`, on line 1987.
 `file_accessible_directory_p()` gets called, seemingly to check if the
 directory is valid. We step through some lines of code that initialize a
 few variables, and we end up at `file_access_p()`. We then get to an if
 statement that checks whether `faccessat (AT_FDCWD, file, amode,
 AT_EACCESS) == 0`. Stepping into `faccessat()` brings us to
 `rpl_faccessat()`, which calls `orig_faccessat(fd, file, mode, flag)`,
 when then calls `faccessat()` again - but this time, it seems to resolve
 to legacy-support's implementation.

 The thing here is that the fd argument for `faccessat()` gets set to -2,
 when AT_FDCWD is supposed to be the value of a file descriptor for the
 current location. Ordinarily, file descriptors are always positive, and
 negative values represent an error... strangely enough, according to the
 Linux man page, `faccessat()` is apparently supposed to ignore the file
 descriptor if the path is absolute (which it is in this case), and should
 attempt to access the file regardless of where the fd points.

 Confirming this, if I dig around in legacy-support's source code, I find
 that the implementation of `faccessat()` calls `getattrlistat()`, which
 calls `ATCALL()`, which calls `_ATCALL()`, which explicitly checks if the
 first character in the path is '/'.

 I don't know enough about how all of this works under the hood to make
 full sense of it, but AT_FDCWD returning -2 seems very suspicious, as does
 the behavior of `faccessat()` not changing whether or not the path is
 absolute. I'll continue digging and see if I can make any further
 progress, but hopefully this at least gives someone more knowledgeable
 than myself a starting point.

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