Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: Help on this typedef
Date: Fri, 19 May 2017 16:42:55 -0700
Organization: None to speak of
Lines: 78
Message-ID: <lnd1b4za4g.fsf@kst-u.example.com>
References: <fc0d8572-2a06-4675-b83a-edb585ea1551@googlegroups.com> <lntw4s6q9v.fsf@kst-u.example.com> <of15n2$2og$1@dont-email.me> <8ad1e08b-bdf9-4baa-a8b4-63bf48fb3e3d@googlegroups.com> <faaaf47a-51ec-4323-aba2-18cabef07fe8@googlegroups.com> <kfnd1bcsb3d.fsf@x-alumni2.alumni.caltech.edu> <7828b0dd-de46-40a2-9636-81117d1f17f6@googlegroups.com> <kfninl2nqqy.fsf@x-alumni2.alumni.caltech.edu> <799899ab-ccf3-49a4-a928-d405dc142fff@googlegroups.com> <lnwp9e15td.fsf@kst-u.example.com> <1c41ec70-5868-4a28-a724-58f4bb70e593@googlegroups.com> <lno9uo24cj.fsf@kst-u.example.com> <8760gwio07.fsf@bsb.me.uk> <lnh90gzggr.fsf@kst-u.example.com> <87tw4gh337.fsf@bsb.me.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx02.eternal-september.org; posting-host="a773bb1c88dd17137d810a1c34d46530"; logging-data="13463"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/xO5/PLrVotWYsXJaXujGm"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:L7yZznaeK2fr6M0E4EbZ2+DqaCs= sha1:8sS72qPbkCPW3ege6GZJ/Cg54Zw=
Xref: csiph.com comp.lang.c:110433

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> [...]
>>> I think something might be missing from the standard in the area.  I
>>> think no one disputes that this is defined behaviour:
>>>
>>>   int *ip = malloc(10);
>>>   if (ip) ip[3] = 42;
>>>
>>> but what is the array in question here?  The storage allocated by malloc
>>> has no effective type (yet) so how can ip and ip+3 point to elements of
>>> the same array?  (I've used and int * because there are special
>>> dispensations for accessing any objects byte as a sequence of chars.)
>>
>> N1570 7.22.3p1:
>>
>>     The pointer returned if the allocation succeeds is suitably
>>     aligned so that it may be assigned to a pointer to any type of
>>     object with a fundamental alignment requirement and then used
>>     to access such an object or an array of such objects in the
>>     space allocated (until the space is explicitly deallocated).
>>
>> The wording does seem to imply that the pointer may be used
>> to access "such an object or an array of such objects" merely
>> *because* it's suitably aligned, which I'm not comfortable with,
>> but the intent seems to be that the allocation functions can and
>> do create accessible objects.
>
> It falls just short of saying that it is an array.  I'm sure we are
> supposed to assume the the space returned by malloc is an array as far
> as the explanation of pointer arithmetic is concerned, but I think it
> could be more explicit.

It seems clear to me that it really is an array.  Otherwise, "then used
to access such an object or an array of such objects in the space
allocated" wouldn't make any sense.

>> So a pointer to malloc()ed memory can be treated as a pointer to an
>> object or array of arbitrary types, but I don't think that implies that
>> an array member within a structure can be treated as if it were a bigger
>> array.
>
> Absolutely.  I just wondered where the array is that ip and ip+3 point
> into in my example.
>
>>> And does that mean we can make the struct hack valid like this:
>>>
>>>   p->text[3] = 'x'; // invalid
>>>   char *cp = (void *)p;
>>>   cp += offsetof(sting_header_t, text);
>>>   cp[3] = 'x'; // this one OK?
>>>
>>> I'd say yes and I think my answer would stay the same if the 'text'
>>> member and the pointer access where to int types rather than char.
>>> (You'd need a char * to do the first offsetof addition, of course.)
>>>
>>> <snip>
>>
>> I'd say that doesn't take advantage of the explicit permission granted
>> for malloc() and friends, so the behavior is undefined.
>
> I'm not entirely sure of your objection.  Is it that p, converted to a
> char *, does not point to the while object that malloc returned but only
                               (whole object)
> to the object that p points too?

Yes.  You can treat the space allocated by malloc() as an object or as
an array of objects.  That doesn't, I think, imply anything about
subsets of that memory.

(I'm not at all confident that I understand this correctly.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"