Hi Olly,
>>>>> "Olly" == Olly Betts <o...@survex.com> writes:
Olly> On 2010-01-15, Dirk-Jan C Binnema wrote:
>>>>>>> "Olly" == Olly Betts <o...@survex.com> writes:
Olly> Not a full patch, but I already posted what this code should look like
Olly> to handle both systems without d_type, and those which return
DT_UNKNOWN:
>>
Olly> http://article.gmane.org/gmane.mail.notmuch.general/1044
>> static gboolean
>> _set_dtype (const char* path, struct dirent *entry)
Olly> Underscore prefixed identifiers are reserved by ISO C at file-scope;
Olly> using them yourself is undefined behaviour...
Ah, thanks for reminding, I thought it was __ and _C (capital), but you are
right:
,---- (7.1.3 Reserved identifiers)
| All identifiers that begin with an underscore and either an uppercase letter
| or another underscore are always reserved for any use.
|
| — All identifiers that begin with an underscore are always reserved for use as
| identifiers with file scope in both the ordinary and tag name spaces.
`----
>> /* we only care about dirs, regular files and links */
>> if (S_ISREG (statbuf.st_mode))
entry-> d_type = DT_REG;
>> else if (S_ISDIR (statbuf.st_mode))
entry-> d_type = DT_DIR;
>> else if (S_ISLNK (statbuf.st_mode))
entry-> d_type = DT_LNK;
Olly> This addresses the case where the FS returns DT_UNKNOWN for d_type,
Olly> but doesn't deal with the case of platforms where struct dirent has
Olly> no d_type member - from the Linux readdir man page:
Olly> The only fields in the dirent structure that are mandated by
Olly> POSIX.1 are: d_name[], of unspecified size, with at most NAME_MAX
Olly> characters preceding the terminating null byte; and (as an XSI
Olly> extension) d_ino. The other fields are unstandardized, and not
Olly> present on all systems; see NOTES below for some further details.
Olly> And in NOTES:
Olly> Other than Linux, the d_type field is available mainly only on BSD
Olly> systems.
Yes, my patch could me generalized a bit more, just like your patch could not
hardcode the '/'-separator :)
In practice though, what Unices in use today do not support d_type?
Best wishes,
Dirk,
--
Dirk-Jan C. Binnema Helsinki, Finland
e:d...@djcbsoftware.nl w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C
_______________________________________________
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
