On 2021-04-28 09:36, Jeffrey Walton wrote:
On Tue, Apr 27, 2021 at 5:12 PM <squid3@treenet.co.nz> wrote:On 2021-04-27 20:40, Jeffrey Walton wrote: > On Tue, Apr 27, 2021 at 4:35 AM William ML Leslie wrote: >> >> On Tue, 27 Apr 2021, 6:13 am Samuel Thibault wrote: >>> >>> It's not because something is economical that one should want to do >>> it. >>> >>> You don't even seem to realize that defining PATH_MAX *does* pose >>> problem, notably with the actual semantic of realpath(), due to the >>> semantic that posix attaches to it. >>> >> >> Economical would be to avoid the rich bug farm that is arbitrary but >> unenforced limits. PATH_MAX is an open invitation for buffer >> overflows on any modern system. > > It is what it is. Folks are going to use PATH_MAX. ... therefore nobody should fix bugs?What bug?
The bug that PATH_MAX is assumed to a) always exist, and b) always be const. As others already mentioned POSIX defines it as *optional* and in Hurd it is not possible to define.
If you get fed a path larger than 4096 you are likely under attack. I don't blame Posix or Linux for putting a sane upper limit on it.
That is context dependent. Sane for one system is too small or too large for others. That is why POSIX etc do not define a specific number *and* complexity like Hurd has (see below) why they make it optional rather than mandatory to define.
That is bad logic. There are plenty of historic code symbols which are known to be buggy, removed from various OS due to that, or never were portable at all. A bad idea existing does not mean it MUST be fully supported everywhere. PATH_MAX is a false value even on systems where it is "supported". Itoften really means the max length of the *filename* section of path and people use it for full-path or other bad assumptions based on the symbolname.4096 is large enough for every system I've worked on since the late 1990s.The only problem I encountered was in the early 2000s on a Windows system. MAX_PATH is 255 on the system, and I needed about 280 characters. I'd love to hear about your use case where you encountered a need for a path or component larger than 4K.
I recognize your email address, you may recognize mine. The use-case I have to point at specifically for 4K being too small is website caching. Archival type caches in particular require file paths longer than the URLs being stored - those have a minimum 8KB with no technical limit (up to 64KB have been found from time to time).
For caching also have the situation where URLs can nest. Think performing a search with a very long URL as the "?q=" value. Popular search engines add a whole bunch of verbose settings and trackers that take up a lot of bytes in addition to the long input parameter.
The Hurd situation as I understand it is similar. The "path" to a file consists of a series command line arguments for the translator binary access needs to go through. These nest, layer upon layer as each translator sub-calls others to get access to things. This can blowout to very long path-length even for what appear to us humans be a short disk path.
Amos