Re: Netsurf build failure: 'PATH_MAX' undeclared
On 2021-04-28 09:36, Jeffrey Walton wrote:
On Tue, Apr 27, 2021 at 5:12 PM <email@example.com> 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
>>> 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?
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
PATH_MAX is a false value even on systems where it is "supported". It
often really means the max length of the *filename* section of path
people use it for full-path or other bad assumptions based on the
4096 is large enough for every system I've worked on since the late
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
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