From owner-svn-src-head@freebsd.org Wed Apr 5 06:39:16 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68736D2FE10; Wed, 5 Apr 2017 06:39:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 339402E3; Wed, 5 Apr 2017 06:39:15 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id E86E7104148A; Wed, 5 Apr 2017 16:39:05 +1000 (AEST) Date: Wed, 5 Apr 2017 16:39:05 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Conrad Meyer 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 In-Reply-To: <201704050144.v351i3N4092979@repo.freebsd.org> Message-ID: <20170405161430.G2189@besplex.bde.org> References: <201704050144.v351i3N4092979@repo.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=KeqiiUQD c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=bymHFdxc78X44CV4hO4A:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 06:39:16 -0000 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