Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 SMI; site sun.uucp
Path: utzoo!watmath!clyde!floyd!harpo!decvax!decwrl!sun!gnu
From: gnu@sun.uucp (John Gilmore)
Newsgroups: net.lang.c
Subject: Re: structure and array and string comparisons
Message-ID: <637@sun.uucp>
Date: Mon, 19-Mar-84 13:56:24 EST
Article-I.D.: sun.637
Posted: Mon Mar 19 13:56:24 1984
Date-Received: Tue, 20-Mar-84 01:41:31 EST
References: <6900@unc.UUCP> <178@harvard.UUCP> <237@opus.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 20

If we do ANYTHING about this, we should do it right.  This means that
we can't embed "zero byte means end" into the language -- a character "string"
is simply an array of chars, and don't you forget it.  In any case,
we can't do array comparison, since an array is by definition converted
to a pointer to its first element every time it's used -- there's no way to
refer to the whole array except in sizeof.  When I want to pass an array
as an argument, I typically enclose it in a struct.  The flexibility of 
pointer==array==pointer is a big win but it has some minor losses like this.

Personally I think that avoiding structure comparison "because it's hard"
is a copout.  It's already "hard" for the C programmer who has to compare
each member of the structure individually.  For the compiler, 99% of the
cases are without holes and it's easy and efficient.

I don't propose comparing unions, or following pointers.  The comparison
s1 == s2 should be equivalent, except for storage reference pattern, to:

	( (s1.memb1 == s2.memb1) && (s1.memb2 == s2.memb2) && ...)