fastfetch-cli / fastfetch-cli/fastfetch
Don't rely on path_max
- Dominant language
- C
- Stars
- 24.6k
- Forks
- 890
- Avg merge
- 1d 42m
- Merged PRs (30d)
- 17
Description
Hi,
Following up to my comment in https://github.com/fastfetch-cli/fastfetch/issues/1895#issuecomment-3206602801 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?
Contributor guide
Assessment
This issue has not been assessed yet.