Re: struct dirent question
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 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 case that value ever changes), and it does not just happen to be 255+1 bytes for some reason that is completely unrelated to MAXNAMLEN. So if some programmer is working with the d_name variable, and *if* they actually look at this include file, then they'll immediately realize that any checks that they make should use MAXNAMLEN, and not hard-code in the 255 value. That's my 2-cents worth, at least... Then shouldn't both be set to MAXNAMLEN? Of course, it isn't a big deal, I'm just curious what I'm missing in the reasoning for doing such a thing. It's a hack because MAXNAMLEN isn't POSIX, so for the pure-POSIX case, _BSD_VISIBLE isn't defined, so we hardcode the length. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: struct dirent question
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 only one location. And if I defined MAXNAMLEN before I included this file? You can't do it that way :-( Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: struct dirent question
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 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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: struct dirent question
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, see below */
__uint8_t d_namlen;/* length of string in d_name */
#define MAXNAMLEN 255
chard_name[MAXNAMLEN + 1]; /* name must be no longer than
this */
#if !__BSD_VISIBLE
#undef MAXNAMLEN
#endif
};
Macro definitions don't nest so this isn't safe. Consider some code that
does:
#define MAXNAMLEN 1024
...
#include sys/dirent.h
...
charmybuffer[MAXNAMLEN];
--
Peter Jeremy
pgp9G71sqx9ME.pgp
Description: PGP signature
Re: struct dirent question
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
chard_name[MAXNAMLEN + 1]; /* name must be no longer than
this */
#else
chard_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
chard_name[255 + 1];/* name must be no longer than
this */
};
--
Eric AndersonSr. Systems AdministratorCentaur Technology
Anything that works is better than anything that doesn't.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: struct dirent question
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 case that value ever changes), and it does not just happen to be 255+1 bytes for some reason that is completely unrelated to MAXNAMLEN. So if some programmer is working with the d_name variable, and *if* they actually look at this include file, then they'll immediately realize that any checks that they make should use MAXNAMLEN, and not hard-code in the 255 value. That's my 2-cents worth, at least... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: struct dirent question
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 tied to the exact value of MAXNAMLEN (just in case that value ever changes), and it does not just happen to be 255+1 bytes for some reason that is completely unrelated to MAXNAMLEN. So if some programmer is working with the d_name variable, and *if* they actually look at this include file, then they'll immediately realize that any checks that they make should use MAXNAMLEN, and not hard-code in the 255 value. That's my 2-cents worth, at least... Then shouldn't both be set to MAXNAMLEN? Of course, it isn't a big deal, I'm just curious what I'm missing in the reasoning for doing such a thing. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: struct dirent question
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? To make it clear that d_name is tied to the exact value of MAXNAMLEN (just in case that value ever changes), and it does not just happen to be 255+1 bytes for some reason that is completely unrelated to MAXNAMLEN. It should be noted that the standard doesn't say anything about MAXNAMLEN (which is historically a FS specific limit). It also allows two different defitions of d_name: (1) As char[] of arbitrary length. (2) As char[1]. So portable code should always allocate storage for size(struct dirent) + NAME_MAX of the current FS. In that sense the current definition is misleading. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: struct dirent question
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
chard_name[MAXNAMLEN + 1]; /* name must be no longer
than this */
#else
chard_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
chard_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
chard_name[__MAXNAMLEN + 1]; /* name must be no longer than this */
};
just curious
--
tonym
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: struct dirent question
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
chard_name[MAXNAMLEN + 1]; /* name must be no longer
than this */
#else
chard_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
chard_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
chard_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
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 only one location.
- Micah
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
struct dirent question
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
chard_name[MAXNAMLEN + 1]; /* name must be no longer than
this */
#else
chard_name[255 + 1];/* name must be no longer than
this */
#endif
};
--
Eric AndersonSr. Systems AdministratorCentaur Technology
Anything that works is better than anything that doesn't.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: struct dirent question
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
chard_name[MAXNAMLEN + 1]; /* name must be no longer than
this */
#else
chard_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.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
