struct comparison

[Guy Harris]

>If ANSI C had permitted even a strongly constrained comparable struct type
>these problems would have been eliminated.  (E.g. add "comparable" struct
>to the language:

OK, what if I want to see if one file offset is larger than, or smaller
than, another?  It may be uncommon, or it may not - until somebody's
scoured a large body of code, I'd assume there is code that does
comparisons on file offsets, since it is permissible on integral
types.... 

>compilers would be permitted to reorder to allow comparison as a
>byte-by-byte comparison;

Reorder structure members?  I think that's a separate issue....

>Even off_t would have been helped, as only the add and subtract operators
>would have to be macros were this possible.  Those are not _too_
>common.

Perhaps add and subtract aren't as common as other operators, but I'd
still be a bit annoyed if I couldn't add and subtract file offsets;
unlike structure comparison, I've used addition of file offsets on a
number of occasions.

>(Something has to give with off_t, and soon; 4Gb disks are coming along
>very soon.   It would be nice to find a way to deal with them without
>having to rewrite every use of off_t and lseek() in the world.

Me, I'd vote for "long long int", which I doubt would be "otherwise
unneeded" - Convex, at least, thought they needed it.  As an integral
type, it should require less rewriting (although there is the problem
that existing systems define "off_t" otherwise - but that problem exists
with other proposed changes to "off_t" as well).