On Sun, Jan 27, 2013 at 04:26:00PM +0100, Adam Borowski wrote: > On Sun, Jan 27, 2013 at 02:25:56PM +0100, Guillem Jover wrote: > > > + char real[MAX_PATH]; > > > > I guess you meant PATH_MAX here, in any case POSIX does not guarantee > > MAX variables to be defined, it would be better to use the POSIX.1-2008 > > variant of realpath(3) that allocates when passed a NULL (by checking > > if it's available at configure time). > > Really, I'd say realpath() should call abort() immediately if called with a > non-NULL argument -- it's better to catch buffer overflows immediately > rather than to allow them to linger. > > No modern system implements PATH_MAX. On Linux, it's hardcoded to a random > value of 4096 for compat reasons, so is pathconf(_PC_PATH_MAX), but I really > wish both went the Hurd way and swat away dumb code before we get a DSA.
Given the amount of work already done by the Hurd porters, would it be viable to undef PATH_MAX and do a test build to look at how much this breaks? The other advantage is that it reduces duplicate codepaths in all the places where we have #ifdef PATH_MAX (where the dynamic allocation is done only for Hurd, rather than across the board). This alone would remove a whole bunch of potential bugs and improve the overall code quality and robustness. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130127162025.gf29...@codelibre.net
