[notmuch] indexing mail?

[Dirk-Jan C. Binnema]

Hi Olly,

>>>>> "Olly" == Olly Betts <olly at survex.com> writes:

    Olly> On 2010-01-15, Dirk-Jan C  Binnema wrote:
    >>>>>>> "Olly" == Olly Betts <olly at 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:djcb at djcbsoftware.nl           w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C