From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 16 22:36:38 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 DBFCF16A4DA for ; Wed, 16 Aug 2006 22:36:37 +0000 (UTC) (envelope-from anthony.maher@uts.edu.au) Received: from gaz.itd.uts.edu.au (gaz.itd.uts.edu.au [138.25.22.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DBEC43D6E for ; Wed, 16 Aug 2006 22:36:32 +0000 (GMT) (envelope-from anthony.maher@uts.edu.au) Received: by gaz.itd.uts.edu.au (Postfix, from userid 1011) id 5458590DDA; Thu, 17 Aug 2006 08:32:47 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by gaz.itd.uts.edu.au (Postfix/Intermediary) with ESMTP id 4412890DDC; Thu, 17 Aug 2006 08:32:47 +1000 (EST) Received: from vimes (vimes.itd.uts.edu.au [138.25.243.34]) by gaz.itd.uts.edu.au (Postfix/Ingress) with ESMTP id 31CF290DDA; Thu, 17 Aug 2006 08:32:47 +1000 (EST) Received: from [138.25.81.47] by postoffice.uts.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTPS id <0J4400HFA44UBS50@postoffice.uts.edu.au>; Thu, 17 Aug 2006 08:36:31 +1000 (EST) Date: Thu, 17 Aug 2006 08:36:28 +1000 From: Tony Maher In-reply-to: <44E3484D.8090905@centtech.com> To: Eric Anderson Message-id: <44E39DEC.1050204@uts.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-Enigmail-Version: 0.93.0.0 References: <44E29055.3080205@centtech.com> <20060816054925.GA11651@droopy.unibe.ch> <44E3484D.8090905@centtech.com> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20060511 Cc: FreeBSD Hackers 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: Wed, 16 Aug 2006 22:36:38 -0000 Eric Anderson wrote: > On 08/16/06 00:49, Tobias Roth wrote: > >> On Tue, Aug 15, 2006 at 10:26:13PM -0500, Eric Anderson wrote: >> >>> Does the ifdef in the struct dirent (pasted in below) make any sense? >>> Seems like regardless of whether the __BSD_VISIBLE is defined or not, >>> the d_name length will always be 255 + 1. >>> >>> Eric >>> >>> >>> struct dirent { >>> __uint32_t d_fileno; /* file number of entry */ >>> __uint16_t d_reclen; /* length of this record */ >>> __uint8_t d_type; /* file type, see below */ >>> __uint8_t d_namlen; /* length of string in d_name */ >>> #if __BSD_VISIBLE >>> #define MAXNAMLEN 255 >>> char d_name[MAXNAMLEN + 1]; /* name must be no longer >>> than this */ >>> #else >>> char d_name[255 + 1]; /* name must be no longer >>> than this */ >>> #endif >>> }; >> >> >> The difference is whether MAXNAMLEN is defined or not, the value of >> d_name >> is irrelevant. How far not defining MAXNAMLEN (in the case __BSD_VISIBLE= >> false) makes sense, I cannot tell. >> >> cheers, t. > > > > 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? Isn't this the same thing (but easier to > read): > > #if __BSD_VISIBLE > #define MAXNAMLEN 255 > #endif > > struct dirent { > __uint32_t d_fileno; /* file number of entry */ > __uint16_t d_reclen; /* length of this record */ > __uint8_t d_type; /* file type, see below */ > __uint8_t d_namlen; /* length of string in d_name > char d_name[255 + 1]; /* name must be no longer than > this */ > }; Easier to read and the same provided value of MAXNAMLEN is not changed. If it is changed then you have to change 255 in two places otherwise definition MAXNAMLEN and actual array size will be wrong (where __BSD_VISIBLE defined). In the original code it forces them to be the same. Though the need to change "255" in two places happens in the original code. If you do not change both occurences of "255" you get different aray sizes depending on whether __BSD_VISIBLE is defined. But at least in the __BSD_VISBIBLE case you do keep definition and size correct. Is there no convention to have/allow "private" definitions? e.g. #define __MAXNAMLEN 255 #if __BSD_VISIBLE #define MAXNAMLEN __MAXNAMLEN #endif struct dirent { __uint32_t d_fileno; /* file number of entry */ __uint16_t d_reclen; /* length of this record * __uint8_t d_type; /* file type, see below */ __uint8_t d_namlen; /* length of string in d_name char d_name[__MAXNAMLEN + 1]; /* name must be no longer than this */ }; just curious -- tonym