Re: Netsurf build failure: 'PATH_MAX' undeclared
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
> >>> 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?
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 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". It
> often 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 symbol
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
I'd love to hear about your use case where you encountered a need for
a path or component larger than 4K.