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 wh
M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
Micah <[EMAIL PROTECTED]> writes:
: #define MAXNAMLEN 255
: chard_name[MAXNAMLEN + 1]; /* name must be no longer than
: this */
: #if !__BSD_VISIBLE
: #undef MAXNAMLEN
: #endif
: };
: I'm not sure if it's more reada
In message: <[EMAIL PROTECTED]>
Micah <[EMAIL PROTECTED]> writes:
: #define MAXNAMLEN 255
: chard_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 o
On Wed, 2006-Aug-16 15:54:25 -0700, Micah wrote:
>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,
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 l
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 len
On Wed, Aug 16, 2006 at 02:45:05PM -0400, 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?
>
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 tie
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 c
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
str
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 {
> __
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_re
12 matches
Mail list logo
