Funny bugs in some C compilers

[Dave Martindale]

	From: decot at cwruecmp.UUCP (Dave Decot) Newsgroups: net.lang.c

	Seems to me that another solution to the "holes" problem of
	structure comparison is somewhat clear:

		Permit comparison of two structures of the same tag or
		typedef for [in]equality only.  If the structure
		template involved contains no holes, compare the
		structures using a block-compare instruction (if
		available).  If there ARE holes, the result is the &&
		conjunction [|| disjunction] of comparisons for
		[in]equality of constituent blocks that have no holes.

	Thus, those areas of the structures that should be equal are
	compared, and those that are "holes" are ignored, and the code
	thus generated can be no worse than that generated by the poor
	programmer who has to code this comparison by "hand".

This would prevent you from storing C-style strings in these structures.
Arrays which are used as arrays must, of course, have all elements
compared.  But the semantics of comparing a conventional C string call
for comparing bytes only until a null byte is reached; the contents
of the bytes in the char array following the null byte are often
garbage from a longer string which previously occupied that memory.

If someone were hand-coding the comparison of two structures, they
would use either strcmp (or strncmp) or a block compare of some sort
depending on their knowledge of whether each char array really contained
a string or not.  The compiler cannot know.

To have byte-by-byte comparison work properly, you must switch to
string-copying routines which always ensure that the destination is
padded with some well-defined pattern (probably nulls) to its end.