From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 16 22:54:32 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 9786E16A4DA for ; Wed, 16 Aug 2006 22:54:32 +0000 (UTC) (envelope-from micahjon@ywave.com) Received: from relay2.av-mx.com (relay2.av-mx.com [137.118.16.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id C160543D6D for ; Wed, 16 Aug 2006 22:54:29 +0000 (GMT) (envelope-from micahjon@ywave.com) X-Virus-Scan-Time: 0 Received: from [137.118.16.60] (HELO mx2.av-mx.com) by relay2.av-mx.com (CommuniGate Pro SMTP 4.2.10) with SMTP id 360392693 for freebsd-hackers@freebsd.org; Wed, 16 Aug 2006 18:54:29 -0400 Received: (qmail 27384 invoked from network); 16 Aug 2006 22:54:27 -0000 Received: from dsl25232.ywave.com (HELO ?192.168.1.65?) (micahjon@ywave.com@216.227.113.232) by 0 with SMTP; 16 Aug 2006 22:54:27 -0000 X-CLIENT-IP: 216.227.113.232 X-CLIENT-HOST: dsl25232.ywave.com Message-ID: <44E3A221.1070905@ywave.com> Date: Wed, 16 Aug 2006 15:54:25 -0700 From: Micah User-Agent: Thunderbird 1.5.0.5 (X11/20060730) MIME-Version: 1.0 To: Tony Maher References: <44E29055.3080205@centtech.com> <20060816054925.GA11651@droopy.unibe.ch> <44E3484D.8090905@centtech.com> <44E39DEC.1050204@uts.edu.au> In-Reply-To: <44E39DEC.1050204@uts.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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:54:32 -0000 Tony Maher wrote: > 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 > I think you could fake it as follows: 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 */ #define MAXNAMLEN 255 char d_name[MAXNAMLEN + 1]; /* name must be no longer than this */ #if !__BSD_VISIBLE #undef MAXNAMLEN #endif }; I'm not sure if it's more readable, but it puts 255 in only one location. - Micah