Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Aug 2006 16:10:03 -0700
From:      Micah <micahjon@ywave.com>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        freebsd-hackers@freebsd.org, anthony.maher@uts.edu.au
Subject:   Re: struct dirent question
Message-ID:  <44E79A4B.8050607@ywave.com>
In-Reply-To: <20060819.145027.-1573946361.imp@bsdimp.com>
References:  <44E3484D.8090905@centtech.com>	<44E39DEC.1050204@uts.edu.au>	<44E3A221.1070905@ywave.com> <20060819.145027.-1573946361.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh wrote:
> In message: <44E3A221.1070905@ywave.com>
>             Micah <micahjon@ywave.com> writes:
> : #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.
> 
> And if I defined MAXNAMLEN before I included this file?  You can't do
> it that way :-(
> 
> Warner

I stand corrected. I assumed that since any defined MAXNAMLEN's get 
clobbered if __BSD_VISIBLE is set there was no desire to have a 
MAXNAMLEN defined when __BSD_VISIBLE was cleared. Seems like the current 
way might lead to unexpected behavior if you're trying to define a 
custom MAXNAMLEN. But I haven't really hacked much kernel code yet, I 
just hang out here to learn.

- Micah



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44E79A4B.8050607>