On Fri, Dec 16, 2011 at 12:41:39AM +0000, Ben Hutchings wrote: > On Fri, 2011-12-16 at 00:15 +0000, brian m. carlson wrote: > > Hurd doesn't support PATH_MAX. So trying to allocate memory based on > > PATH_MAX isn't going to work on Hurd. However, with glibc (and with > > POSIX 1003.1-2008) we can simply mark the destination buffer to realpath > > as NULL and the appropriate amount of memory will be automatically > > allocated. Not all systems support this, though. > > > > I cannot comment on the remainder of the patch, but the PATH_MAX issue > > is a pretty common one for Hurd, and assuming PATH_MAX is a compile-time > > constant is a bad idea anyway, since it's not allowed by POSIX. > > Indeed, for any system with an extensible VFS it makes a lot more sense > to implement only pathconf() than to specify a constant value that > covers all possible filesystems. Except there is no reasonable value pathconf() can return as well. It can either say the truth which is typically (size_t)(-1), or return some made up value. The former would break buggy software that relies on a static buffer, thus on Linux it seems pathconf(_PC_PATH_MAX) always returns 4096. I only tested it on tmpfs, ext3, btrfs, jfs, ufs, vfat and msdos; RTFSing may tell us more, but I suspect this is always the case (since msdos should say 66). In other words, moving to pathconf() gives us exactly nothing. -- 1KB // Yo momma uses IPv4!
Attachment:
signature.asc
Description: Digital signature