Re: Netsurf build failure: 'PATH_MAX' undeclared
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?
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
> name.
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.
Jeff
Reply to: