Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site opus.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!harpo!seismo!hao!cires!nbires!opus!rcd
From: rcd@opus.UUCP
Newsgroups: net.lang.c
Subject: Re: structure and array and string comparisons
Message-ID: <254@opus.UUCP>
Date: Tue, 20-Mar-84 23:52:45 EST
Article-I.D.: opus.254
Posted: Tue Mar 20 23:52:45 1984
Date-Received: Thu, 22-Mar-84 01:25:18 EST
References: <637@sun.uucp> <6941@unc.UUCP>
Organization: NBI, Boulder
Lines: 20

<>
> In either case, there are two possible ways that you could determine where
> the end of an array is.  If the identifier is a fixed-size array, then you
> know how many elements there are at compile time, and you can just SOB or
> AOBLSS or whatever to do a fixed number of comparisons.  If it is an array
> that was declared with a null constant expression, it can be assumed that
> the array is null-terminated...

Two problems with this.  First, what does "null terminated" mean?  Fine for
arrays of char, maybe even arrays of pointers if you stretch it. (AAACCK!  I
hear the ol' null-pointer portability discussion starting up again.  Forget
I said anything about pointers!)  But what about arrays of int - what's a
"null" for that type?  Is this comparison going to be a special kluge for
chars only?  Second problem - you introduce a very funny nonuniformity of
behavior:  if the dimension is known, you get a comparison of a fixed
number of elements; if unknown, a delimiter-controlled comparison.  I can
think of situations where changing a declaration or two could really make
things go haywire.
-- 
{hao,ucbvax,allegra}!nbires!rcd