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

Text File | 1992-09-10 | 2.8 KB | 60 lines

Newsgroups: comp.std.c
Path: sparky!uunet!spool.mu.edu!darwin.sura.net!wupost!cs.utexas.edu!torn!watserv2.uwaterloo.ca!watmath!thinkage!dat
From: [e-mail] (David Adrien Tanguay)
Subject: Re: struct hack, and other out-of-array references
Message-ID: <[e-mail]>
Organization: Thinkage, Ltd.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 10 Sep 1992 21:32:40 GMT
Lines: 49

[e-mail] (Mark Brader) writes:
>The pointer f->s does point to an object with type char[1], but it is
>also a pointer into the space returned by malloc(), which may be treated
>as an array of chars.  That is, when strcpy computes the equivalent of
>(f->s)[1], and therefore (f->s)+1, both the pointer operand of +, i.e.
>f->s, and the computed result *are* within the same array, namely the one
>returned by malloc(), and all is well.

How is this any different from the array example?

    struct { int i; char s[1]; } *f = malloc(sizeof(*f)+10);
    int a[6][6];
    int *p = a[1];
    p += 7;   /* is this well-defined? */

If it is not defined, then it is the same as the struct hack. p may now point
outside a[1], but it is still within the a object. Similarly,
    char *q = fs->s;
    q += 2;
is outside the f->s object but within the malloc object.

Also, I don't see how a[1][7] is any different from f->s[2]. The f->s object,
determined by the "type and value", ends at f->s+1. Note that this case is
different from the q case, above, since the type of q is different from the
type of f->s.

(The interpretation, however, does deal only with arrays. We're extending the
same reasoning to apply to structure elements, hoping for consistency.)

>I would also argue that the Interpretation Ruling cited above would not
>apply if the type of the example array "a" had been char instead of int.
>The definitions of "object" and "byte" (in ANSI section 1.6, ISO 3.14 and
>3.4) in effect require that it be possible to treat any object as an
>array of any character type.  This guarantee is assumed, of course, by
>any number of library functions.  Once again, this should render legal any
>references that are out of bounds in a subarray but which address locations
>known to be in the containing array.

I don't see how this necessarily follows. "char *cp = a" would be allowed
to range throughout a, satisfying 3.4, but "char *cp = a[1]" may be limited
to ranging over the a[1] object.

I think this really is a matter of "interpretation": what is the "object"
to which a pointer points? The object determined by the type of the
originating pointer expression, or the largest C object containing the value
originating pointer expression?
--
David Tanguay       [e-mail]  [e-mail]  uunet!thinkage!dat
Thinkage, Ltd.           Kitchener, Ontario, Canada          [43.40N 80.47W]