Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ihlpe!woods
From: woods@ihlpe.ATT.COM (Swan)
Newsgroups: comp.lang.c
Subject: Re: structure comparison
Message-ID: <2472@ihlpe.ATT.COM>
Date: 18 Jan 88 21:22:22 GMT
References: <1322@sugar.UUCP> <1942@ho95e.ATT.COM> <1373@sugar.UUCP> <2456@ihlpe.ATT.COM> <10175@mimsy.UUCP>
Reply-To: woods@ihlpe.UUCP (52462-Swan,W.D.)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 32

In article <10175@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>In article <2456@ihlpe.ATT.COM> woods@ihlpe.ATT.COM (Swan) writes:
>>The problem is that the compiler cannot be sure how many bytes in the
>>structures to compare for [in]equality.
>
>This is easily solved by simply defining it to compare all elements
>of the structure and no holes.  Unions become problematical, but
>this, too, is easily solved, by outlawing comparison of things that
>contain unions.
>
>Yuck.
>-- 
>In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
>Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

Is it possible you missed the meaning of the rest of my article, which
you conveniently didn't include?  I'm sure the rest of us with C
experience see the problem with naively assuming that all bytes should
be compared in a structure comparison.

Yes, I had thought about the union problem.  But a more common problem is
character arrays (strings).  They don't get cleared automatically you know.
There will often be characters after the terminating null byte that were left
around from previous strings that were longer than the current string.

I guess I don't see how telling compiler writers to compare all bytes of
a structure verbatim is "easily solv[ing]" the problem.  Although I can
guess by your "Yuck" that you're agreeing with me in principle.  But
please don't quote me and then glibbly ignore the rest of my article,
which explains why what you are about to say isn't correct.

Warren D. Swan (WooDS)