Re: Thoughts on MAXPATHLEN
- To: firstname.lastname@example.org
- Subject: Re: Thoughts on MAXPATHLEN
- From: Samuel Thibault <email@example.com>
- Date: Fri, 3 Feb 2012 12:39:18 +0100
- Message-id: <20120203113918.GC4192@type.bordeaux.inria.fr>
- Mail-followup-to: firstname.lastname@example.org
- In-reply-to: <CAJbrmLDYCvZX+oQhFRH0ia8wa8_6o2__ZS7=p0WXOT-UOFe2sw@mail.gmail.com>
- References: <email@example.com> <20120131085958.GA9296@mail.sceen.net> <firstname.lastname@example.org> <CA+kCSAa6G4SvzjvFtGG7sgpsxgC+k4RQiAk3MOxjAjLjx1fGjg@mail.gmail.com> <CAJbrmLDYCvZX+oQhFRH0ia8wa8_6o2__ZS7=p0WXOT-UOFe2sw@mail.gmail.com>
Tanguy LE CARROUR, le Fri 03 Feb 2012 11:34:47 +0100, a écrit :
> I do agree. Fixing PATH_MAX code should not be the Hurd developer's job!
> We could decide to define PATH_MAX in Hurd limits.h or create "#define
> PATH_MAX" patches for all the packages for the time being and we would
> have 200+ new packages available on Hurd.
With very high probability of having buffer overflow issues. Hiding a
bug is never a good solution.
> >> Fixing real problems related to Hurd, gnumach, mig, the documentation
> >> and Debian or Arch integration and packaging is much more helpful for
> >> both Hurd users and the project itself.
> Not everyone can fix "complex" bugs or work on Hurd internals.
There are non-complex things to do there too. See the thread about the
keymap support on the mach console. Yes, that *is* a non-complex thing
to do. Just try. And you'll learn a lot alongside.