Date: Mon, 21 Aug 2006 12:22:26 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Garance A Drosihn <drosih@rpi.edu>, Tobias Roth <roth@iam.unibe.ch> Subject: Re: struct dirent question Message-ID: <200608211222.27612.jhb@freebsd.org> In-Reply-To: <44E36877.30707@centtech.com> References: <44E29055.3080205@centtech.com> <p06230909c10914f68909@[128.113.24.47]> <44E36877.30707@centtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 16 August 2006 14:48, Eric Anderson wrote: > On 08/16/06 13:45, Garance A Drosihn wrote: > > At 11:31 AM -0500 8/16/06, Eric Anderson wrote: > >> My point was, that either path you take (if BSD_VISIBLE is > >> defined or not), you end up with d_name having a size of > >> 255 + 1, so what's the point the having it at all? > > > > To make it clear that d_name is tied to the exact value > > of MAXNAMLEN (just in case that value ever changes), and > > it does not just happen to be 255+1 bytes for some reason > > that is completely unrelated to MAXNAMLEN. > > > > So if some programmer is working with the d_name variable, > > and *if* they actually look at this include file, then > > they'll immediately realize that any checks that they make > > should use MAXNAMLEN, and not hard-code in the 255 value. > > > > That's my 2-cents worth, at least... > > > > > Then shouldn't both be set to MAXNAMLEN? > > Of course, it isn't a big deal, I'm just curious what I'm missing in the > reasoning for doing such a thing. It's a hack because MAXNAMLEN isn't POSIX, so for the pure-POSIX case, _BSD_VISIBLE isn't defined, so we hardcode the length. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200608211222.27612.jhb>