Don't rely on path_max

[yelninei]

Hi,

Following up to my comment in #1895 (comment) on PATH_MAX.

I would like to get rid of the -DPATH_MAX=4096 hack for hurd.

I had a look where PATH_MAX is used and it is used only for realpath(3) and readlink(2) to allocate a buffer that will be "big enough".

For realpath glibc will allocate a buffer for us with the result when the output is NULL. (this case is not specified by posix). I don't think this is something that other libcs implement though.

The man page for readlink also suggests to not rely on PATH_MAX and suggests to use stat.st_size from lstat and malloc a buffer manually.

The problem with this approach is that while lstat on /proc returns sensible values on hurd e.g. on linux the size is 0 so the PATH_MAX approach is still needed.

Also there are currently at least 2 static inline realpath aliases for windows.

terminalshell_linux has a FF_EXE_PATH_LEN instead.

Before I start to make this work would it make sense to consolidate this into new helpers to not litter #ifdef PATH_MAX everywhere?

[CarterLi]

For realpath glibc will allocate a buffer for us with the result when the output is NULL. (this case is not specified by posix). I don't think this is something that other libcs implement though.

All platforms supported by fastfetch (including SunOS and Haiku) supports the behavior, but I don't like the extra memory allocation.

The man page for readlink also suggests to not rely on PATH_MAX and suggests to use stat.st_size from lstat and malloc a buffer manually.

Another syscall is even worse.

---

What's the real benefit of removing PATH_MAX? I still don't get it.

[yelninei]

PATH_MAX is not defined on hurd as the arbitrary path limit does not exist.

even on other systems this limit while theoretically set is not enforced and one can create a file name that is longer than path_max so relying on it is flawed.

I'll just leave some quotes

glibc: https://sourceware.org/glibc/manual/latest/html_node/Limits-for-Files.html#index-PATH_005fMAX

The GNU C Library does not enforce this limit even if PATH_MAX is defined.

man 3 realpath: https://www.man7.org/linux/man-pages/man3/realpath.3.html

The POSIX.1-2001 standard version of this function is broken by
design, since it is impossible to determine a suitable size for
the output buffer, resolved_path. According to POSIX.1-2001 a
buffer of size PATH_MAX suffices, but PATH_MAX need not be a
defined constant, and may have to be obtained using pathconf(3).
And asking pathconf(3) does not really help, since, on the one
hand POSIX warns that the result of pathconf(3) may be huge and
unsuitable for mallocing memory, and on the other hand pathconf(3)
may return -1 to signify that PATH_MAX is not bounded. The
resolved_path == NULL feature, not standardized in POSIX.1-2001,
but standardized in POSIX.1-2008, allows this design problem to be
avoided.

man 2 readlink https://www.man7.org/linux/man-pages/man2/readlink.2.html

   Using a statically sized buffer might not provide enough room for

   the symbolic link contents.  The required size for the buffer can
   be obtained from the stat.st_size value returned by a call to
   lstat(2) on the link.  However, the number of bytes written by
   readlink() and readlinkat() should be checked to make sure that
   the size of the symbolic link did not increase between the calls.
   Dynamically allocating the buffer for readlink() and readlinkat()
   also addresses a common portability problem when using PATH_MAX
   for the buffer size, as this constant is not guaranteed to be
   defined per POSIX if the system does not have such limit.