NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/std/c/2594

Text File | 1992-09-09 | 3.0 KB | 70 lines

Path: sparky!uunet!mcsun!uknet!acorn!ixi!clive
From: [e-mail] (Clive Feather)
Newsgroups: comp.std.c
Subject: Re: struct hack
Message-ID: <[e-mail]>
Date: 9 Sep 92 11:21:01 GMT
References: <[e-mail]>
Organization: IXI Limited, Cambridge, UK
Lines: 59

In article <[e-mail]> [e-mail] (08-Sep-1992 0914) writes:
>In article <[e-mail]> [e-mail] (Clive Feather) writes:
>>In article <[e-mail]> [e-mail](04-Sep-1992 1639) writes:
>>> You can't go past the end of an array object.  But if malloc() or some other
>>> variable has defined the end of the actual array object, then the + operator
>>> can get you that far, regardless of the declared type that some other array
>>> variable had before getting flattened to a pointer.
>> But there is an intepretation that says that, given
>>    int a [5][5];
>> the access "a [1][6]" is illegal, because it goes past the bounds of the
>> array "a [1]". In other words, the declared type of the array does
>> restrict what can happen to a pointer derived from it.
> Is that an actual interpretation ruling or was that only someone's posted
> opinion on Usenet?

RFI 17, item 16.

| For an array of arrays, the permitted pointer arithmetic in Standard
| ##3.3.6 Semantics (page 48, lines 12-40) is to be understood by
| interpreting the use of the word "object" as denoting the specific
| object determined directly by the pointer's type and value, *not* other
| objects related to that one by contiguity. For example, the following
| code has undefined behaviour:
|     int a [4][5];
|     a [1][7] = 0;  /* undefined */
| Some conforming implementations may choose to diagnose an "array bounds
| violation", while others may choose to interpret such attempted accesses
| successfully with the "obvious" extended semantics.

This RFT applies to slices of arrays, but, in *my* opinion, it is
extendable to this case:

    struct fred { int i; char s [1]; } *f;
    char *s;

    /* ... */
    f = malloc (sizeof f + strlen (ss));
    if (f != NULL)
        strcpy (f->s, ss);

The pointer f->s points to an object with type "char [1]", and so, if
strlen (ss) > 0, the access to (f->s)[1] required by strlen is undefined
according to this RFI, even though the array has already decayed to a
pointer.

> I am also curious as to the "officially" correct thing to do when an
> interpretation ruling contradicts the standard (whether correcting an
> error that everyone agrees was an error, or otherwise).

You submit a new RFI asking the same question but with additional
supporting material which contradicts the original ruling.

Do you have an example ?

--
Clive D.W. Feather     | IXI Limited         | If you lie to the compiler,
[e-mail]          | 62-74 Burleigh St.  | it will get its revenge.
Phone: [phone] | Cambridge   CB1 1OJ |   - Henry Spencer
Fax:   [phone] | United Kingdom      |