Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.std.c
Subject: Re: struct comparison
Message-ID: <2288@auspex.auspex.com>
Date: 26 Jul 89 00:07:01 GMT
References: <167@ssp1.idca.tds.philips.nl> <12040019@hpfcdc.HP.COM>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 33

>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).