From owner-freebsd-bugs Wed Oct 7 20:30:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA04530 for freebsd-bugs-outgoing; Wed, 7 Oct 1998 20:30:06 -0700 (PDT) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA04462 for ; Wed, 7 Oct 1998 20:30:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id UAA25074; Wed, 7 Oct 1998 20:30:01 -0700 (PDT) Date: Wed, 7 Oct 1998 20:30:01 -0700 (PDT) Message-Id: <199810080330.UAA25074@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Bruce Evans Subject: Re: kern/8165: minor inconsistency in dirent.h Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/8165; it has been noted by GNATS. From: Bruce Evans To: aledm@routers.co.uk, bde@zeta.org.au Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/8165: minor inconsistency in dirent.h Date: Thu, 8 Oct 1998 13:23:04 +1000 >I understand what you're saying, but do you agree that having the same >constant (i.e. constants with the same meaning) being defined in two >places is bad? It's no worse than the same types being defined in several headers, as they must be to limit namespace pollution. size_t is a good example. The right technique for this is to define them in terms of a commin definition in an implementation-only header like . A closer look shows that MAXNAMLEN is not the same as NAME_MAX. They just happen to have the same value. NAME_MAX (if it is defined) is supposed to give the maximum length of a file name - file names of this length (but no longer) may exist on all (POSIX) file systems. MAXNAMLEN in is just the maximum length of a file name that may be returned by readdir(). It should be defined as the maximum of all the per-file-system maximum name lengths, but that is too hard to put in a single #define. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message