[BUG] Consistently attempt to fit paths into an adequately sized array

[lenormf]

Version of Kakoune

any

Reproducer

The codebase doesn’t always store paths into arrays of a consistent size. Some use PATH_MAX, some add +1 to that, and there might be some hardcoded sizes too.

Outcome

Opening files in deeply nested directories on different filesystems might yield different outcomes.

Expectations

Maybe using PATH_MAX is enough. Maybe not appending a free byte, due to the macro potentially not including a trailing null byte in some instances, is enough.

Ideally, pathconf should be used to fetch the PC_PATH_MAX configuration option for the target filesystem.

Additional information

Prompted by https://github.com/mawww/kakoune/pull/4431#pullrequestreview-802890974

[Screwtapello]

At least on Linux, file paths can be arbitrarily large. PATH_MAX is the limit for a path passed to the kernel in a syscall, but it can be relative to the current directory so the total length of the path in question can be much longer.

Consider the following Python 3 script:

from os import mkdir, chdir, getcwd

for _ in range(1,10000):
    mkdir("a")
    chdir("a")

print(getcwd())

(I previously had a shell-script here, but because shells typically track the current directory for UI purposes, the "obvious" implementation was O(n²) or worse and didn't properly demonstrate the behaviour I'm talking about)

At each step of the loop, the path passed to mkdir(2) or chdir(2) is only a single byte long, well below PATH_MAX, but the total length of the path printed at the end is much, much longer.

It should be possible to make Kakoune work with megabyte-long path names, but it would probably also be quite an effort.

See here for more details: https://eklitzke.org/path-max-is-tricky