Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: struct comparison
Message-ID: <10574@smoke.BRL.MIL>
Date: 20 Jul 89 23:45:46 GMT
References: <2874@solo3.cs.vu.nl> <1989Jul14.155312.2063@utzoo.uucp> <2878@kappl.cs.vu.nl> <1989Jul15.210821.7950@utzoo.uucp> <167@ssp1.idca.tds.philips.nl> <1989Jul18.020424.2392@utzoo.uucp> <2335@trantor.harris-atd.com> <2261@auspex.auspex.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 17

In article <2261@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>Simple "compare all bytes" is certainly simple; how useful it is is
>another question, given that comparing padding bytes is simply wrong,
>unless you *guarantee* that they're always going to have some "standard"
>value that gets in the way.

Comparing padding is wrong anyway.  Even if you could arrange for it to
"contain" some standard value (and I'm not sure how you could do that in
standards language), there is no constraint so far that says that value
must still be there later.  

The obvious definition of struct comparison would be:
	structs compare equal if and only if all their corresponding
	members compare equal.
I assure you that it was considered as one of the zillion proposed C
language extensions received by X3, but its benefits were not shown to
outweigh its drawbacks.