Path: utzoo!utgpu!water!watmath!clyde!rutgers!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: structure comparison
Message-ID: <10252@mimsy.UUCP>
Date: 19 Jan 88 15:54:46 GMT
References: <1322@sugar.UUCP> <1942@ho95e.ATT.COM> <1373@sugar.UUCP> <2472@ihlpe.ATT.COM>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 53

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.

In article <10175@mimsy.UUCP> I answered:
>>This is easily solved by simply defining it to compare all elements
>>of the structure and no holes. [but then unions] ... Yuck.

In article <2472@ihlpe.ATT.COM> woods@ihlpe.ATT.COM (Swan) writes:
[reordered]
>... 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. ...
>Is it possible you missed the meaning of the rest of my article ... ?

No.  I thought my intent was obvious.  Just as structure copy copies
all bytes of `strings' (array N of char), structure comparison
would compare all bytes, even if that is unnecessary.  Of course,
copying unused data is not *wrong*, just inefficient; comparing
unused data *is* wrong.  But there is no way for the compiler to
tell what is unused data: just because something is of type array
N of char and contains a \0 does not mean it is a string.  Indeed,
many of my own strings are of type pointer to char, allocated
dynamically.  Sometimes, as with one program-in-progress now, if
the pointers match, so do the strings; more often, it is necessary
to compare the objects to which the pointers point.  Should structure
comparison then follow pointers-to-char and compare the text there?

>I guess I don't see how telling compiler writers to compare all bytes of
>a structure verbatim is "easily solv[ing]" the problem.

Any problem is easily solved if you change it enough :-) .  Defining
structure comparison *not* to compare all bytes of `char' arrays,
assuming that such arrays are NUL-terminated strings, but to compare
all bytes of other arrays, is ugly at best, and more likely wrong.
Hence the only definition with which I could agree is one that compares
all bytes except holes, which of course means that your string problem
comes up.

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

1) Yes.  2) I suppose I could be considered overzealous in editing
down others' articles (but that is what References: lines are for!
there should be only enough context to figure out what the reply
is about, in case the parent article never arrived).  3) What I
said (>> above) still looks correct to me.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris