Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!apple!sun-barr!decwrl!hplabs!hpfcdc!donn
From: donn@hpfcdc.HP.COM (Donn Terry)
Newsgroups: comp.std.c
Subject: Re: Re: Re^3 (was 2): struct comparison
Message-ID: <12040019@hpfcdc.HP.COM>
Date: 24 Jul 89 01:20:58 GMT
References: <167@ssp1.idca.tds.philips.nl>
Organization: HP Ft. Collins, Co.
Lines: 41

Personal opinion:

Omitting comparison of at least a limited range of structs presents
a class of problems that has not been addressed here so far.

There are certain predefined types in classical UN*X (and probably other
OSs as well) that would "like" to be structs (or at least objects larger
than long).  dev_t is a good example.  For historical reasons, usually
associated with comparisons on such types, they must be constrained to
integral (or at least arithmetic) types.

Because ANSI C prohibits comparisons on such larger types, standardizers
of other things (e.g. POSIX) are constrained:

	1) require integral/arithmetic types, and force unnatural kluges
	   on some OS's (more than 32-bits worth of I/O addressability,
	   allowing for type modifiers: try to cram it into an dev_t or
	   force an otherwise unneeded long long long long... type).
	2) Define new types for the standard, and define operations on
	   those types for all relevant operations.  (Typically at least
	   3: comparison, and some modifier and it's converse.)
	3) Break existing applications by permitting/requiring struct types
	   that will break the applications that use the object.

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: compilers would be permitted to reorder to allow comparison
as a byte-by-byte comparison; possibly prohibit pointers, possibly prohibit
or constrain unions.)  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.

(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.  The
ANSI C solution might work (I forget the names, but there is a solution
for stdio), but it does require a lot of rewrite of existing applications.)

Donn Terry
HP Ft. Collins
Chair 1003.1 (and speaking only for himself)