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