Date: Wed, 5 Apr 2017 16:39:05 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Conrad Meyer <cem@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r316509 - in head/sys/ufs: ffs ufs Message-ID: <20170405161430.G2189@besplex.bde.org> In-Reply-To: <201704050144.v351i3N4092979@repo.freebsd.org> References: <201704050144.v351i3N4092979@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 5 Apr 2017, Conrad Meyer wrote: > Log: > ufs: Export UFS_MAXNAMLEN to pathconf, statfs > > Rather than the global NAME_MAX constant. This change is required to > support systems with a NAME_MAX/MAXNAMLEN that differs from UFS_MAXNAMLEN. > > This was missed in r313475 due to the alternative spelling ("NAME_MAX") of > MAXNAMLEN. This change is also similar in spirit to r313780. It is a bug for NAME_MAX to exist if it is not constant. I fixed the corresponding bug for CHILD_MAX and OPEN_MAX in my tree ~20 years ago, but never got around to committing this after committing fixes for some misuses of OPEN_MAX (not many, since getdtablesize() was used fairly correctly). There are emore misuses now. NAME_MAX and PATH_MAX/MAXPATHLEN are much harder to fix due to more misuses. Honestly unportable code uses MAXPATHLEN. PATH_MAX and NAME_MAX are unusable in portable code since they might not exist. Portable code must use sysconf() and complicated allocation for paths, and once it does that it gets few benefits from using PATH_MAX when it exists. I think even PATH_MAX can be so large that malloc() and static allocation of PATH_MAX bytes always fails. This large would mean that it is unlimited. Some other POSIX limits really are infinite and this is expressed by sysconf() a special value or errno for them. Allocation for potentially- unbounded limits is difficult. > ... > Modified: head/sys/ufs/ufs/ufs_vnops.c > ============================================================================== > --- head/sys/ufs/ufs/ufs_vnops.c Tue Apr 4 23:30:05 2017 (r316508) > +++ head/sys/ufs/ufs/ufs_vnops.c Wed Apr 5 01:44:03 2017 (r316509) > @@ -2446,7 +2446,7 @@ ufs_pathconf(ap) > *ap->a_retval = LINK_MAX; > break; > case _PC_NAME_MAX: > - *ap->a_retval = NAME_MAX; > + *ap->a_retval = UFS_MAXNAMLEN; > break; > case _PC_PATH_MAX: > *ap->a_retval = PATH_MAX; ffs was being chummy with the implementation and knowing that NAME_MAX is constant so that it may exist, and that it does exist. Since it exists, its value must be the same for all file systems including ffs. ffs still has the same bug for LINK_MAX and PATH_MAX. NAME_MAX hasn't been constant since 1993 or earler it is 8.3 for some versions of msdosfs. LINK_MAX hasn't been constant since 1997 or earler it is 32000 in ext2fs. PATH_MAX can actually be constant (and doesn't need to be set in this layer) since it is a vfs limit. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170405161430.G2189>