Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #110434
| 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> |
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
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