chris@mimsy.UUCP (Chris Torek) (01/14/88)
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
blm@cxsea.UUCP (01/15/88)
Chris Torek (chris@mimsy.UUCP) 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. What do you do about things like char x[10]? How does the compiler know that (and if) you want to compare a null-terminated string, as opposed to every character? Also, what about the fairly common practice of having the last item be of indeterminate size (at compile time)? In my opinion, there are too many special cases to make structure comparison useful (and usable). -- Brian L. Matthews "A power tool is not a toy. ...{mnetor,uw-beaver!ssc-vax}!cxsea!blm Unix is a power tool." +1 206 251 6811 Computer X Inc. - a division of Motorola New Enterprises
woods@ihlpe.ATT.COM (Swan) (01/19/88)
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)
chris@mimsy.UUCP (Chris Torek) (01/19/88)
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