On Fri, 2011-12-16 at 14:31 +0100, Adam Borowski wrote: > 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. [...]
Yeah, you're right. It's NAME_MAX that can generally be specified per-volume but not globally. Ben. -- Ben Hutchings Computers are not intelligent. They only think they are.
signature.asc
Description: This is a digitally signed message part
