NFD_MAX_STRLEN is 256, but MAX_PATH on Linux often is 4096, as well as unsafe strdup() use

[ell1e]

I've checked the source code and found that NFD_MAX_STRLEN is 256 and maybe used for paths. However, on Linux MAX_PATH is often 4096. But with a 4096 buffer, it is probably risky to just put it multiple times onto the stack as done here since that might exceed the stack space on some systems with less stack by default (Alpine with musl-libc comes to mind). So that might need some more fundamental refactoring.

While checking this file, I have also found strdup() is used without null pointer checking, meaning the code would crash on allocation failure rather than allowing the calling application to recover in some way which would be preferable. I've seen a similar potential issue with NFDi_Malloc use. (I know this recovery isn't safely possible with glib/GTK+, but it should be with most/all(?) other targets.)

[ell1e]

Side note: maybe strdup should also be replaced with an NFDi_strdup() that uses NFDi_Malloc and memcpy? Since that would otherwise not go through the custom allocator as probably intended. Just another thought that came to mind.

[ssokolow]

Beyond that, Windows apps are drifting more and more toward opting out of the DOS path length limitation (either by using the \\?\ prefix to speak in NT kernel-internal paths like the Rust standard library did last I checked, or by setting longPathAware in their manifests (an option as of Windows 10, version 1607), which makes the next limit NTFS's 32,767 characters.

On Linux filesystems like ext4, there is actually no limit at all on total path length... which makes sense when you can make something of PATH_MAX length and then mount it at any arbitrarily deep point within another filesystem. PATH_MAX is just a limit for libc functions like realpath(3). It's just a chain of inodes referencing other inodes with parent/child pointers, and the only length limit is 255 characters per file/directory name.