Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #110434

Re: Help on this typedef

From Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups comp.lang.c
Subject Re: Help on this typedef
Date 2017-05-20 01:16 +0100
Organization A noiseless patient Spider
Message-ID <87inkwgz69.fsf@bsb.me.uk> (permalink)
References (11 earlier) <lno9uo24cj.fsf@kst-u.example.com> <8760gwio07.fsf@bsb.me.uk> <lnh90gzggr.fsf@kst-u.example.com> <87tw4gh337.fsf@bsb.me.uk> <lnd1b4za4g.fsf@kst-u.example.com>

Show all headers | View raw


Keith Thompson <kst-u@mib.org> writes:

> 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.

I could argue that I accept that it can become an array -- after all the
effective type rules say the type the type of the object *becomes* that of
the effective type of the expression use to store data into.  That would
give some reason to talk about accessing an array in the space
allocated.  In my example, no type had yet been determined.

But this point seems trivial.  I certainly agree on what is intended.  I
just expected it to be simpler to find words that explain what array ip
and ip+4 point into.

>>> 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.

So after

   int *p = malloc(100);
   char *cp = (void *)p;

cp now only points to one int and cp[sizeof (int) + 1] constructs an
invalid pointer?

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

-- 
Ben.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Help on this typedef fl <rxjwg98@gmail.com> - 2017-05-10 19:12 -0700
  Re: Help on this typedef Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-05-10 21:06 -0600
  Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-10 20:11 -0700
    Re: Help on this typedef David Brown <david.brown@hesbynett.no> - 2017-05-11 10:03 +0200
      Re: Help on this typedef supercat@casperkitty.com - 2017-05-11 08:35 -0700
        Re: Help on this typedef David Brown <david.brown@hesbynett.no> - 2017-05-12 10:34 +0200
          Re: Help on this typedef joel.rees@gmail.com - 2017-05-12 06:01 -0700
          Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-12 09:38 -0700
        Re: Help on this typedef joel.rees@gmail.com - 2017-05-12 05:08 -0700
          Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-13 14:25 -0700
            Re: Help on this typedef joel.rees@gmail.com - 2017-05-14 23:36 -0700
              Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-15 07:23 -0700
                Re: Help on this typedef joel.rees@gmail.com - 2017-05-18 07:40 -0700
                Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-18 09:35 -0700
                Re: Help on this typedef supercat@casperkitty.com - 2017-05-18 10:59 -0700
                Re: Help on this typedef joel.rees@gmail.com - 2017-05-18 23:40 -0700
                Re: Help on this typedef jadill33@gmail.com - 2017-05-19 08:12 -0700
                Re: Help on this typedef supercat@casperkitty.com - 2017-05-19 08:41 -0700
                Re: Help on this typedef jadill33@gmail.com - 2017-05-19 09:41 -0700
                Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-19 09:34 -0700
                Re: Help on this typedef supercat@casperkitty.com - 2017-05-19 10:18 -0700
                Re: Help on this typedef Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-19 21:35 +0100
                Re: Help on this typedef supercat@casperkitty.com - 2017-05-19 14:16 -0700
                Re: Help on this typedef Ike Naar <ike@iceland.freeshell.org> - 2017-05-19 21:15 +0000
                Re: Help on this typedef Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-19 23:54 +0100
                Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-19 14:25 -0700
                Re: Help on this typedef supercat@casperkitty.com - 2017-05-19 15:18 -0700
                Re: Help on this typedef Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-19 23:52 +0100
                Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-19 16:42 -0700
                Re: Help on this typedef Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-20 01:16 +0100
                Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-20 01:58 -0700
                Re: Help on this typedef joel.rees@gmail.com - 2017-05-20 02:25 -0700
                Re: Help on this typedef joel.rees@gmail.com - 2017-05-19 22:09 -0700
                Re: Help on this typedef supercat@casperkitty.com - 2017-05-19 23:23 -0700
                Re: Help on this typedef "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-19 13:33 -0400
                Re: Help on this typedef supercat@casperkitty.com - 2017-05-19 13:44 -0700
                Re: Help on this typedef jameskuyper@verizon.net - 2017-05-19 19:20 -0700
                Re: Help on this typedef supercat@casperkitty.com - 2017-05-19 23:30 -0700
                Re: Help on this typedef jameskuyper@verizon.net - 2017-05-20 07:20 -0700
                Re: Help on this typedef jameskuyper@verizon.net - 2017-05-20 07:46 -0700
                Re: Help on this typedef supercat@casperkitty.com - 2017-05-22 10:50 -0700
                Re: Help on this typedef "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-18 12:37 -0400
                Re: Help on this typedef Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-18 20:02 +0100
                Re: Help on this typedef joel.rees@gmail.com - 2017-05-19 00:20 -0700
                Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-19 09:51 -0700
                Re: Help on this typedef supercat@casperkitty.com - 2017-05-19 10:31 -0700
                Re: Help on this typedef Ike Naar <ike@iceland.freeshell.org> - 2017-05-19 19:48 +0000
                Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-20 08:47 -0700
        Re: Help on this typedef "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-27 18:50 +0200
  Re: Help on this typedef joel.rees@gmail.com - 2017-05-12 06:17 -0700
    Re: Help on this typedef supercat@casperkitty.com - 2017-05-12 08:46 -0700
      Re: Help on this typedef joel.rees@gmail.com - 2017-05-12 18:11 -0700
        Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-12 18:37 -0700
          Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-13 09:44 -0700
            Re: Help on this typedef Keith Thompson <kst-u@mib.org> - 2017-05-13 13:47 -0700
              Re: Help on this typedef Robert Wessel <robertwessel2@yahoo.com> - 2017-05-14 00:28 -0500
              Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 13:39 -0700
                Re: Help on this typedef raltbos@xs4all.nl (Richard Bos) - 2017-05-15 13:02 +0000
                Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-15 07:30 -0700
        Re: Help on this typedef supercat@casperkitty.com - 2017-05-12 20:45 -0700
        Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-13 09:57 -0700
        Re: Help on this typedef Philip Lantz <prl@canterey.us> - 2017-05-13 12:07 -0700
        Re: Help on this typedef David Brown <david.brown@hesbynett.no> - 2017-05-14 15:34 +0200
      Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 12:48 -0700
        Re: Help on this typedef supercat@casperkitty.com - 2017-05-15 07:39 -0700
          Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-24 08:23 -0700
            Re: Help on this typedef supercat@casperkitty.com - 2017-05-24 09:17 -0700
              Re: Help on this typedef Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-27 06:15 -0700

csiph-web