fastfetch-cli / fastfetch-cli/fastfetch

Don't rely on path_max

Open
#2,091 2 comments 1 reaction 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.