From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 21 17:29:25 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1366216A4E5 for ; Mon, 21 Aug 2006 17:29:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5703743D72 for ; Mon, 21 Aug 2006 17:29:24 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k7LHTCGq011401; Mon, 21 Aug 2006 13:29:13 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 21 Aug 2006 12:22:26 -0400 User-Agent: KMail/1.9.1 References: <44E29055.3080205@centtech.com> <44E36877.30707@centtech.com> In-Reply-To: <44E36877.30707@centtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608211222.27612.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 21 Aug 2006 13:29:15 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1702/Mon Aug 21 11:23:21 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Garance A Drosihn , Tobias Roth Subject: Re: struct dirent question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 17:29:25 -0000 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