>>> I think the change is fine.  However I'm wondering if it wouldn't
>>> be better to somehow version the _ftsent structure.  I doubt that
>>> du will be the only directory-walking application that will need to
>>> deal with 64-bit values.
>> That sounds plausible.

On reflection, I'm not sure this is that good an argument.  fts won't
be able to cater to everyone's desires; that's what fts_pointer is for,
so applications can attach whatever data they feel appropriate.  If you
add fts_quad, then what about an application that needs two quads?  At
some point you have to draw the line and say "beyond this it's up to
you to deal with it", and I'm inclined to draw that line at
fts_pointer.  We can't get rid of fts_number for backward compatability
reasons, but that's no reason to compound it.

>> But I see no need to version FTSENT.  As long as the existing fields
>> remain valid and at the same offsets, [...]
> The problem I see is that the last field of _ftsent is the name,
> which is variable length.  So we can't readily add new fields w/o
> moving any other fields.

Eww.  Yeah, you're right.  I hadn't realized fts_name was a final
variable-length element.  Maybe that should be fixed as part of the
next versioning?  (This does not make it impossible to malloc the
string and the FTSENT together; it just means that applications have to
follow the pointer.  t=malloc(sizeof(FTSENT)+namelen+1);
t->fts_name=(char *)(t+1);)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B