🚀 go-pugleaf

In article <9209080014.AA03467@enet-gw.pa.dec.com> diamond@jit081.enet.dec.com (08-Sep-1992 0914) writes:
>In article <1992Sep07.104932.20060@x.co.uk> clive@x.co.uk (Clive Feather) writes:
>>In article <9209040741.AA16120@enet-gw.pa.dec.com> diamond@jit081.enet.dec.com(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,
clive@x.co.uk          | 62-74 Burleigh St.  | it will get its revenge.
Phone: +44 223 462 131 | Cambridge   CB1 1OJ |   - Henry Spencer
Fax:   +44 223 462 132 | United Kingdom      |