On Sat, Jan 28, 2012 at 03:34:49PM -0800, Mark Overmeer via RT wrote: > * Dominic Hargreaves (dom@earth.li) [120128 23:09]: > > On Sat, Jan 28, 2012 at 02:42:17PM -0800, Mark Overmeer via RT wrote: > > > * Dominic Hargreaves (perlbug-followup@perl.org) [120128 14:22]: > > > > No, on GNU/Hurd 'POSIX::pathconf( "/etc", &POSIX::_PC_PATH_MAX )' > > returns undef. > > > > <http://www.gnu.org/software/hurd/community/gsoc/project_ideas/maxpath.html> > > Not only PATH_MAX, but also many other global constants do not really > make sense. Especially the ancient ones. Pathconf() would stand a better > chance, because the length is obviously file-system dependent. If I > read the Hurd idea about it, I would say that it supports > pathconf($fn, _PC_PATH_MAX) > returning "undef" as "unlimited". > > You like to enlarge the default for MAXPATHLEN to an other artificial > value, where also a known PATH_MAX is probably too small. So, why not > remove the attempt to get a realistic value from the OS here? > > #define ALWAYS_LARGE_ENOUGH 32768 > Char *bufnext, *bufend, patbuf[ALWAYS_LARGE_ENOUGH]; > bufend = bufnext + ALWAYS_LARGE_ENOUGH - 1; As I understand it, you're suggesting picking a different arbitrary value as a maximum, and using it even when the underlying system wouldn't support paths that long. I'm not convinced that this is an improvement on my suggestion. Have I missed something? Cheers, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email)Thread Previous | Thread Next