Date: Wed, 16 Aug 2006 15:54:25 -0700 From: Micah <micahjon@ywave.com> To: Tony Maher <anthony.maher@uts.edu.au> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: struct dirent question Message-ID: <44E3A221.1070905@ywave.com> In-Reply-To: <44E39DEC.1050204@uts.edu.au> References: <44E29055.3080205@centtech.com> <20060816054925.GA11651@droopy.unibe.ch> <44E3484D.8090905@centtech.com> <44E39DEC.1050204@uts.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44E3A221.1070905>