On Tue, Apr 27, 2021 at 5:12 PM <squ...@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