svn commit: r316509 - in head/sys/ufs: ffs ufs

[Bruce Evans]

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