NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/c/17045

Text File | 1992-11-23 | 2.7 KB | 58 lines

Newsgroups: comp.lang.c
Path: sparky!uunet!gatech!concert!sas!mozart.unx.sas.com!sasghm
From: [e-mail] (Gary Merrill)
Subject: Re: Is this ANSI?
Originator: [e-mail]
Sender: [e-mail] (Noter of Newsworthy Events)
Message-ID: <[e-mail]>
Date: Mon, 23 Nov 1992 17:50:25 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: theseus.unx.sas.com
Organization: SAS Institute Inc.
Lines: 44


Well, I think I've switched sides on this one -- however goofy I
think the result is in practice.

In article <[e-mail]>, [e-mail] (Mark Brader) writes:
|> > Now, look back at the assertion I asked you to remember.  I expect
|> > that Mark Brader is going to say `But p->data isn't an array of
|> > one element, it's an array of 101 elements.  After all, when you
|> > said malloc(sizeof(struct FM + 100), you allocated enough memory
|> > for 101 elements!'
|>
|> No, I'm not.  That would be wrong for the reasons you said.  What I
|> did say was that while the character pointed to by the decayed
|> pointer p->data is indeed part of the one-character array p->data,
|> it is *also* part of a larger array, namely the object returned by
|> malloc(), whose size might be, say, 104 elements when considered
|> as an array of char.  Therefore the Unless clause is applicable
|> and the reference valid.

But there is no larger array.  There is a contiguous block of memory
returned by malloc(), but this is *not* an array in the technical sense
that 'array' is used in the standard.  The pointer p->data indeed
points to a position in this block of memory, and p->data is an array,
but (unforutnately?) it does *not* follow that p->data[5] is legitimate
since the only *array* in question is only 1 byte in length.

I think this exposes some sloppiness in the use of "array" at places
in the standard.  Since in fact malloc() returns a 'void *', it is
hard to construe the block allocated as an array (of what?).  You
can proceed to *look at* this block as an array.  But you *can't*
(strictly speaking) look at it as "the array p->data" because, I
would argue, 'p->data' is not a modifiable lvalue.  The p->data array
(of one element) may *overlap* a larger array, but it still doesn't
follow that you can index off the end of p->data into that larger
array *by using 'p->data'*.

This consequence may be counterintuitive initially, but it doesn't
appear to be inconsistent.


--
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / [phone]
[e-mail] ... !mcnc!sas!sasghm