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