Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #67120 > unrolled thread
| Started by | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| First post | 2015-08-11 20:48 +0200 |
| Last post | 2015-08-12 11:13 +0200 |
| Articles | 20 on this page of 231 — 23 participants |
Back to article view | Back to comp.lang.c
C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-11 20:48 +0200
Re: C pointer semantics with dynamically allocated struct Melzzzzz <mel@zzzzz.com> - 2015-08-11 20:59 +0200
Re: C pointer semantics with dynamically allocated struct Melzzzzz <mel@zzzzz.com> - 2015-08-11 21:03 +0200
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-08-11 15:32 -0400
Re: C pointer semantics with dynamically allocated struct jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-11 21:03 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-11 21:47 +0200
Re: C pointer semantics with dynamically allocated struct jt@toerring.de (Jens Thoms Toerring) - 2015-08-11 19:14 +0000
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-11 21:50 +0200
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-08-11 16:12 -0400
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-11 22:45 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 03:08 +0100
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-11 20:24 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-11 21:51 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-11 13:32 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-11 13:36 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-11 22:57 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-11 23:23 +0200
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-11 16:47 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-11 23:46 +0000
Re: C pointer semantics with dynamically allocated struct morphex@gmail.com (Morten W. Petersen) - 2015-08-12 02:05 +0200
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-11 17:16 -0700
Re: C pointer semantics with dynamically allocated struct Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 01:11 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-11 17:35 -0700
Re: C pointer semantics with dynamically allocated struct Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 01:51 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 03:02 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-11 19:50 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-11 20:09 -0700
Music and programming (was: Re: C pointer semantics with dynamically allocated struct) "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 11:54 +0200
Re: Music and programming (was: Re: C pointer semantics with dynamically allocated struct) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 03:35 -0700
Re: Music and programming "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 13:00 +0200
Re: Music and programming Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 11:46 +0100
Re: Music and programming "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 13:06 +0200
Re: Music and programming Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 13:08 +0100
Re: Music and programming raltbos@xs4all.nl (Richard Bos) - 2015-08-12 12:18 +0000
Re: Music and programming "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 14:26 +0200
Re: Music and programming Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 13:36 +0100
Re: Music and programming "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 15:13 +0200
Re: Music and programming David Brown <david.brown@hesbynett.no> - 2015-08-12 16:10 +0200
Re: C pointer semantics with dynamically allocated struct crisdunbar@gmail.com - 2015-08-13 15:47 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 04:52 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 05:01 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 05:10 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-12 09:17 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 02:56 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 04:07 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 03:45 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 12:10 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 11:39 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-12 13:41 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 04:59 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 14:16 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 06:37 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 15:34 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 08:17 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 08:38 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 17:19 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 09:52 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 22:40 +0100
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-13 13:31 +0200
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-08-14 20:39 -0400
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 13:03 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 14:16 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-09-06 11:19 +0200
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 18:15 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-09-07 09:13 +0200
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-08-12 08:07 -0400
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 14:08 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 10:24 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 20:45 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-13 04:19 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 13:18 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-16 15:43 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-16 21:32 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 12:00 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-17 15:50 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 22:28 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-18 01:34 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-19 08:40 +0200
Re: C pointer semantics with dynamically allocated struct luser droog <luser.droog@gmail.com> - 2015-08-12 13:35 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 15:01 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 11:39 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-09-06 11:24 +0200
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 18:09 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 10:17 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-12 20:58 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-12 19:59 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-13 13:47 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 05:35 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-13 15:59 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 07:57 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-13 17:46 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 09:15 -0700
Re: C pointer semantics with dynamically allocated struct Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 17:21 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 09:26 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 19:40 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 11:43 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 21:30 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 14:56 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-14 08:51 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 00:03 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 17:22 +0100
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-14 09:09 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 11:19 +0100
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-14 13:07 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 19:19 +0100
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-08-14 14:32 -0400
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-16 16:52 +0200
Re: C pointer semantics with dynamically allocated struct Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-08-16 18:34 +0000
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-17 07:48 +0200
Re: C pointer semantics with dynamically allocated struct Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-08-18 18:08 +0000
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-19 09:36 +0200
Re: C pointer semantics with dynamically allocated struct David Thompson <dave.thompson2@verizon.net> - 2015-08-30 03:03 -0400
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-30 16:59 +0200
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-30 20:12 +0000
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 14:36 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 12:39 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 07:56 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 17:09 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 11:38 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 20:31 +0100
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 15:17 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-09-06 11:44 +0200
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-08-14 20:56 -0400
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 18:09 -0700
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-08-14 22:26 -0400
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 19:44 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-15 04:15 +0000
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-16 19:00 +0200
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-16 19:00 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-16 20:20 +0200
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-16 17:18 -0700
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-16 23:03 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 00:52 +0200
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-17 00:29 +0100
A simpler version of C (was: Re: C pointer semantics with dynamically allocated struct) "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 02:36 +0200
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-17 01:47 +0000
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-17 11:27 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 12:40 +0200
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-17 12:07 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 13:36 +0200
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-17 13:14 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 14:09 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-17 05:23 -0700
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 14:35 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-17 05:45 -0700
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 14:58 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-17 06:23 -0700
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 15:30 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-17 06:46 -0700
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 15:47 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-17 06:56 -0700
Re: C pointer semantics with dynamically allocated struct fir <profesor.fir@gmail.com> - 2015-08-17 08:57 -0700
Re: C pointer semantics with dynamically allocated struct Richard Heathfield <rjh@cpax.org.uk> - 2015-08-17 15:37 +0100
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-17 15:03 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 15:12 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-17 16:15 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 16:45 +0200
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-17 15:58 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 22:11 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-17 22:24 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 22:31 +0200
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-17 15:04 -0700
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 23:41 +0200
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-17 17:58 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-17 14:53 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-17 16:58 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 22:16 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-18 01:31 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-19 08:51 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-19 09:56 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-20 08:52 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-20 10:09 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-20 12:48 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-20 13:00 +0200
Re: C pointer semantics with dynamically allocated struct Ike Naar <ike@iceland.freeshell.org> - 2015-08-20 13:53 +0000
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-20 16:36 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-20 07:39 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-20 09:09 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-20 09:08 -0700
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-21 10:15 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-21 02:17 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-21 14:23 +0100
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-21 15:44 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-21 14:59 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-21 07:03 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-23 21:50 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-21 16:25 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-21 07:34 -0700
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-21 20:44 +0100
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:10 +0000
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-17 20:08 +0000
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-17 09:33 -0700
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-17 22:20 +0200
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-08-17 17:28 -0400
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-17 16:42 -0700
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-08-17 19:39 -0400
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-17 16:15 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-18 00:19 +0100
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-08-17 08:32 -0400
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-17 18:02 +0100
Re: C pointer semantics with dynamically allocated struct Rosario19 <Ros@invalid.invalid> - 2015-08-22 08:25 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-17 14:46 +0200
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-17 09:45 -0700
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-17 18:55 +0100
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-08-17 12:11 -0700
Re: C pointer semantics with dynamically allocated struct Bartc <bc@freeuk.com> - 2015-08-17 23:07 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-17 15:13 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-17 22:56 +0000
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-17 20:04 +0000
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 14:46 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 07:33 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-13 16:39 +0200
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 19:20 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 11:55 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 21:11 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-13 15:15 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-14 09:29 +0200
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-08-14 08:01 -0400
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-14 14:46 +0200
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-16 19:14 +0200
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-17 08:01 +0200
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-08-12 23:30 -0400
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 12:45 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-09-05 16:11 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-05 22:32 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 13:21 -0700
Re: C pointer semantics with dynamically allocated struct David Brown <david.brown@hesbynett.no> - 2015-08-12 09:22 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-11 19:43 -0700
Re: C pointer semantics with dynamically allocated struct "Morten W. Petersen" <morphex@gmail.com> - 2015-08-11 22:52 +0200
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-11 16:01 -0700
Re: C pointer semantics with dynamically allocated struct Rosario19 <Ros@invalid.invalid> - 2015-08-12 11:13 +0200
Page 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-13 17:22 +0100 |
| Message-ID | <87r3n72fqj.fsf@bsb.me.uk> |
| In reply to | #67293 |
David Brown <david.brown@hesbynett.no> writes: <snip> > First, Ben dislikes your use of a union for type conversion because it > is unclear, and does not express the programmer's intentions well. > While I agree with Ben, this is a somewhat subjective opinion - and > obviously when one has used a particular style or habit for a long time, > it becomes clear and obvious to that person. Thus we must rely on the > opinions of others when judging whether a style is common or easily > understood by other programmers. That sounds like I object on rather subjective grounds of style. I've called Rick's union wrong, a lie and a hack. This is not really the same as it being unclear, or not expressing the programmer's intentions well. It's wrong (rather than unclear), and it expresses the wrong intention very well indeed! <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-14 09:09 +0200 |
| Message-ID | <mqk43b$vsi$1@dont-email.me> |
| In reply to | #67321 |
On 13/08/15 18:22, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > <snip> >> First, Ben dislikes your use of a union for type conversion because it >> is unclear, and does not express the programmer's intentions well. >> While I agree with Ben, this is a somewhat subjective opinion - and >> obviously when one has used a particular style or habit for a long time, >> it becomes clear and obvious to that person. Thus we must rely on the >> opinions of others when judging whether a style is common or easily >> understood by other programmers. > > That sounds like I object on rather subjective grounds of style. I've > called Rick's union wrong, a lie and a hack. This is not really the > same as it being unclear, or not expressing the programmer's intentions > well. It's wrong (rather than unclear), and it expresses the wrong > intention very well indeed! > I was trying to be a little diplomatic and understating your objections, in the hope of getting Rick to concentrate on and understand the real issues here. In particular, if you use an idiom yourself in your own code, and only you work with it (or you inform others of its meanings), then it is a matter of style even if makes no sense to everyone else. Clarity, and the meaning of code, is somewhat in the eye of the beholder, and a matter of style. (There are some regulars in this group that post code that appears as line noise to most of us, yet the authors think they have a good and clear style.) Of course it is usually best to have a style that is clear and understandable to as wide an audience as possible. Thus Rick's unions are not a lie to himself in his own code, but could be called a hack, or a lie to other people. But am I right in thinking you label Rick's unions as /wrong/ primarily because it is a bad way to write the code, hiding the intentions and workings behind an odd construct rather than making the clear and correct casts? (If we pretend for the moment that all compilers have the same size and representation for all pointers, and that any pointer casts are equivalent to reinterpretations of the same bits - as they are on the platforms Rick uses.) In other words, the code is wrong even though it works? (I am quite happy with labelling code as "wrong" even when it works, although I know some people view run-time functionality as the only criteria for right or wrong code.) What did you think of my concerns about aliasing, discussed in other posts?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-14 11:19 +0100 |
| Message-ID | <87tws2yxy9.fsf@bsb.me.uk> |
| In reply to | #67358 |
David Brown <david.brown@hesbynett.no> writes: > On 13/08/15 18:22, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> <snip> >>> First, Ben dislikes your use of a union for type conversion because it >>> is unclear, and does not express the programmer's intentions well. >>> While I agree with Ben, this is a somewhat subjective opinion - and >>> obviously when one has used a particular style or habit for a long time, >>> it becomes clear and obvious to that person. Thus we must rely on the >>> opinions of others when judging whether a style is common or easily >>> understood by other programmers. >> >> That sounds like I object on rather subjective grounds of style. I've >> called Rick's union wrong, a lie and a hack. This is not really the >> same as it being unclear, or not expressing the programmer's intentions >> well. It's wrong (rather than unclear), and it expresses the wrong >> intention very well indeed! > > I was trying to be a little diplomatic and understating your objections, > in the hope of getting Rick to concentrate on and understand the real > issues here. Ah, right. I don't think I will be applying for diplomatic posts! > In particular, if you use an idiom yourself in your own code, and only > you work with it (or you inform others of its meanings), then it is a > matter of style even if makes no sense to everyone else. Clarity, and > the meaning of code, is somewhat in the eye of the beholder, and a > matter of style. (There are some regulars in this group that post code > that appears as line noise to most of us, yet the authors think they > have a good and clear style.) Of course it is usually best to have a > style that is clear and understandable to as wide an audience as > possible. Thus Rick's unions are not a lie to himself in his own code, > but could be called a hack, or a lie to other people. That's probably true. It's clear the Rick sees the whole idea of programming in a very different way to me. C, in particular, is a means to a mechanical end -- to get the machine to do what he wants -- and the type system juts gets in the way. (Ironically, given his rants about ancient history, he'd probably prefer B or BCPL.) > But am I right in thinking you label Rick's unions as /wrong/ primarily > because it is a bad way to write the code, hiding the intentions and > workings behind an odd construct rather than making the clear and > correct casts? (If we pretend for the moment that all compilers have > the same size and representation for all pointers, and that any pointer > casts are equivalent to reinterpretations of the same bits - as they are > on the platforms Rick uses.) In other words, the code is wrong even > though it works? Yes, that was my main objection to it's being used where it works -- it says something untrue about the programmer's intent. > (I am quite happy with labelling code as "wrong" even when it works, > although I know some people view run-time functionality as the only > criteria for right or wrong code.) > > What did you think of my concerns about aliasing, discussed in other > posts? To be honest I missed them, though I did see, subsequently, a reference to the fact that you'd brought it up. I went back in the thread and saw this: "... the compiler uses type information to improve code generation because it knows that a pointer to type A cannot alias a pointer to type B except in certain prescribed circumstances." but even so I may still be missing most of what you said about aliasing. In the situation being discussed here, the object will always be accessed via a pointer of the right type, will it not? After all, that's the point of Rick's hack -- to ensure that the type is correct without actually converting a value. On this rather superficial analysis, I'd say that there's no problem specifically relating to aliasing. Maybe you have an example in mind? (I see you've replied to my post about C being rather over-used. Replying just to say "I agree" is not good form on Usenet, so I'll tack it on here: I agree -- and you made the point better than I did.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-14 13:07 +0200 |
| Message-ID | <mqki2c$cd9$1@dont-email.me> |
| In reply to | #67376 |
On 14/08/15 12:19, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 13/08/15 18:22, Ben Bacarisse wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> <snip> >>>> First, Ben dislikes your use of a union for type conversion because it >>>> is unclear, and does not express the programmer's intentions well. >>>> While I agree with Ben, this is a somewhat subjective opinion - and >>>> obviously when one has used a particular style or habit for a long time, >>>> it becomes clear and obvious to that person. Thus we must rely on the >>>> opinions of others when judging whether a style is common or easily >>>> understood by other programmers. >>> >>> That sounds like I object on rather subjective grounds of style. I've >>> called Rick's union wrong, a lie and a hack. This is not really the >>> same as it being unclear, or not expressing the programmer's intentions >>> well. It's wrong (rather than unclear), and it expresses the wrong >>> intention very well indeed! >> >> I was trying to be a little diplomatic and understating your objections, >> in the hope of getting Rick to concentrate on and understand the real >> issues here. > > Ah, right. I don't think I will be applying for diplomatic posts! > >> In particular, if you use an idiom yourself in your own code, and only >> you work with it (or you inform others of its meanings), then it is a >> matter of style even if makes no sense to everyone else. Clarity, and >> the meaning of code, is somewhat in the eye of the beholder, and a >> matter of style. (There are some regulars in this group that post code >> that appears as line noise to most of us, yet the authors think they >> have a good and clear style.) Of course it is usually best to have a >> style that is clear and understandable to as wide an audience as >> possible. Thus Rick's unions are not a lie to himself in his own code, >> but could be called a hack, or a lie to other people. > > That's probably true. It's clear the Rick sees the whole idea of > programming in a very different way to me. C, in particular, is a means > to a mechanical end -- to get the machine to do what he wants -- and the > type system juts gets in the way. (Ironically, given his rants about > ancient history, he'd probably prefer B or BCPL.) > >> But am I right in thinking you label Rick's unions as /wrong/ primarily >> because it is a bad way to write the code, hiding the intentions and >> workings behind an odd construct rather than making the clear and >> correct casts? (If we pretend for the moment that all compilers have >> the same size and representation for all pointers, and that any pointer >> casts are equivalent to reinterpretations of the same bits - as they are >> on the platforms Rick uses.) In other words, the code is wrong even >> though it works? > > Yes, that was my main objection to it's being used where it works -- it > says something untrue about the programmer's intent. > >> (I am quite happy with labelling code as "wrong" even when it works, >> although I know some people view run-time functionality as the only >> criteria for right or wrong code.) >> >> What did you think of my concerns about aliasing, discussed in other >> posts? > > To be honest I missed them, though I did see, subsequently, a reference > to the fact that you'd brought it up. I went back in the thread and saw this: > > "... the compiler uses type information to improve code generation > because it knows that a pointer to type A cannot alias a pointer to > type B except in certain prescribed circumstances." > > but even so I may still be missing most of what you said about aliasing. > > In the situation being discussed here, the object will always be > accessed via a pointer of the right type, will it not? After all, > that's the point of Rick's hack -- to ensure that the type is correct > without actually converting a value. On this rather superficial > analysis, I'd say that there's no problem specifically relating to > aliasing. Maybe you have an example in mind? It is difficult to be sure of the situation with Rick's suggested union, since it is not a complete example. But the general point is that when you change a pointer's type (either by unions or casts), the strict aliasing rules govern when the accesses are defined or not. In the special case of pointers to two structs which share a common start, you are allowed to do some conversions - so Rick's union /might/ be valid here, depending on the exact code. The main post I made about unions and strict aliasing is a bit up and "sideways" from this branch, at 13/08/15 13:31 (at least on my news server), in reply to a post of Rick's which you also replied to. I'd be glad to hear your opinion on it, whether it be confirmation or correction. > > (I see you've replied to my post about C being rather over-used. > Replying just to say "I agree" is not good form on Usenet, so I'll > tack it on here: I agree -- and you made the point better than I did.) > It's fine to make "I agree" and "me too" posts, as long as you use the appropriate <aol> tag :-)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-14 19:19 +0100 |
| Message-ID | <87k2sxybpb.fsf@bsb.me.uk> |
| In reply to | #67384 |
David Brown <david.brown@hesbynett.no> writes: > On 14/08/15 12:19, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: <snip> >>> What did you think of my concerns about aliasing, discussed in other >>> posts? <snip> >> In the situation being discussed here, the object will always be >> accessed via a pointer of the right type, will it not? After all, >> that's the point of Rick's hack -- to ensure that the type is correct >> without actually converting a value. On this rather superficial >> analysis, I'd say that there's no problem specifically relating to >> aliasing. Maybe you have an example in mind? > > It is difficult to be sure of the situation with Rick's suggested union, > since it is not a complete example. But the general point is that when > you change a pointer's type (either by unions or casts), the strict > aliasing rules govern when the accesses are defined or not. Are "strict aliasing rules" different to the effective type rules of 6.5 p7? I've never been clear exactly what people mean by "strict" aliasing. > In the > special case of pointers to two structs which share a common start, you > are allowed to do some conversions - so Rick's union /might/ be valid > here, depending on the exact code. > > The main post I made about unions and strict aliasing is a bit up and > "sideways" from this branch, at 13/08/15 13:31 (at least on my news > server), in reply to a post of Rick's which you also replied to. I'd be > glad to hear your opinion on it, whether it be confirmation or > correction. If I've got the right post, that's an example of UB which remains UB when the cast is replaced by Rick's union hack. If the hack has aliasing issues of its own, they would show in the translation of an example that is well-defined using casts. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-14 14:32 -0400 |
| Message-ID | <55CE3436.7030707@verizon.net> |
| In reply to | #67416 |
On 08/14/2015 02:19 PM, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: ... >> It is difficult to be sure of the situation with Rick's suggested union, >> since it is not a complete example. But the general point is that when >> you change a pointer's type (either by unions or casts), the strict >> aliasing rules govern when the accesses are defined or not. > > Are "strict aliasing rules" different to the effective type rules of 6.5 > p7? I've never been clear exactly what people mean by "strict" > aliasing. The impression I get is that a large fraction of the people who use the phrase "strict aliasing rules" are referring to the corresponding gcc command line options. As I understand it, when used for C code, -fstrict-aliasing enables optimizations that rely upon 6.5p7, while -wstrict-aliasing turns on diagnostic messages for detected violations of 6.5p7.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-16 16:52 +0200 |
| Message-ID | <mqq80j$vms$1@dont-email.me> |
| In reply to | #67417 |
On 14/08/15 20:32, James Kuyper wrote:
> On 08/14/2015 02:19 PM, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
> ...
>>> It is difficult to be sure of the situation with Rick's suggested union,
>>> since it is not a complete example. But the general point is that when
>>> you change a pointer's type (either by unions or casts), the strict
>>> aliasing rules govern when the accesses are defined or not.
>>
>> Are "strict aliasing rules" different to the effective type rules of 6.5
>> p7? I've never been clear exactly what people mean by "strict"
>> aliasing.
>
> The impression I get is that a large fraction of the people who use the
> phrase "strict aliasing rules" are referring to the corresponding gcc
> command line options. As I understand it, when used for C code,
> -fstrict-aliasing enables optimizations that rely upon 6.5p7, while
> -wstrict-aliasing turns on diagnostic messages for detected violations
> of 6.5p7.
>
Certainly the term "strict aliasing" is often used in the context of gcc
(or clang/llvm, which follows gcc here). It would be better to use a
phrase such as "strict application and interpretation of C's aliasing
rules" rather than "strict aliasing rules", since the later implies that
this is some sort of extra strict rules in the C standards.
Basically, if the compiler can use the list of rules in 6.5p7 to see
that a particular access could not legally alias another given access,
then it can optimise with the assumption that the accesses do not alias.
This is generally known as "type based alias analysis", or something
similar, and is common in optimisation. For example (from
<http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>) :
float *P;
void zero_array() {
int i;
for (i = 0; i < 10000; ++i)
P[i] = 0.0f;
}
With type-based alias analysis, the compiler knows that stores to P[i]
cannot affect pointer P itself, and can turn this into memset(P, 0,
10000 * sizeof int). Without such analysis, it has to assume that
someone might set P so that it is within the P array itself - and thus
the value of P might change during the loop.
In cases like this, alias analysis gives the "obvious" behaviour. But
it is quite possible for code to look like it does one thing, but
because of strict application of the aliasing rules, the compiler can
generate code that does not do what the programmer expects.
My experience is that gcc usually generates the obvious code - if it
looks like the programmer really wants to use aliasing (or
type-punning), the compiler makes code that does what is expected. It
may also generate warnings when it thinks there could be a problem. But
it is something you always have to think about when accessing data using
different "views", such as pointers of different types.
(I don't think this is an issue with most code - you don't often find
such problems in "normal" code. The exception is that you might view
data via pointer to a char type, such as for memcpy - and char types are
specifically allowed to alias anything.)
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-08-16 18:34 +0000 |
| Message-ID | <slrnmt1ltk.eij.grahn+nntp@frailea.sa.invalid> |
| In reply to | #67527 |
On Sun, 2015-08-16, David Brown wrote:
> On 14/08/15 20:32, James Kuyper wrote:
>> On 08/14/2015 02:19 PM, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>> ...
>>>> It is difficult to be sure of the situation with Rick's suggested union,
>>>> since it is not a complete example. But the general point is that when
>>>> you change a pointer's type (either by unions or casts), the strict
>>>> aliasing rules govern when the accesses are defined or not.
>>>
>>> Are "strict aliasing rules" different to the effective type rules of 6.5
>>> p7? I've never been clear exactly what people mean by "strict"
>>> aliasing.
>>
>> The impression I get is that a large fraction of the people who use the
>> phrase "strict aliasing rules" are referring to the corresponding gcc
>> command line options. As I understand it, when used for C code,
>> -fstrict-aliasing enables optimizations that rely upon 6.5p7, while
>> -wstrict-aliasing turns on diagnostic messages for detected violations
>> of 6.5p7.
>>
>
> Certainly the term "strict aliasing" is often used in the context of gcc
> (or clang/llvm, which follows gcc here). It would be better to use a
> phrase such as "strict application and interpretation of C's aliasing
> rules" rather than "strict aliasing rules", since the later implies that
> this is some sort of extra strict rules in the C standards.
Yes. I've noticed that "strict aliasing rules" sounds like
"unnecessarily strict" to many people -- like caring about it is
optional and for over-achievers.
> Basically, if the compiler can use the list of rules in 6.5p7 to see
> that a particular access could not legally alias another given access,
> then it can optimise with the assumption that the accesses do not alias.
> This is generally known as "type based alias analysis", or something
> similar, and is common in optimisation. For example (from
> <http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>) :
>
> float *P;
> void zero_array() {
> int i;
> for (i = 0; i < 10000; ++i)
> P[i] = 0.0f;
> }
>
> With type-based alias analysis, the compiler knows that stores to P[i]
> cannot affect pointer P itself, and can turn this into memset(P, 0,
> 10000 * sizeof int). Without such analysis, it has to assume that
> someone might set P so that it is within the P array itself - and thus
> the value of P might change during the loop.
>
> In cases like this, alias analysis gives the "obvious" behaviour. But
> it is quite possible for code to look like it does one thing, but
> because of strict application of the aliasing rules, the compiler can
> generate code that does not do what the programmer expects.
>
> My experience is that gcc usually generates the obvious code - if it
> looks like the programmer really wants to use aliasing (or
> type-punning), the compiler makes code that does what is expected. It
> may also generate warnings when it thinks there could be a problem. But
> it is something you always have to think about when accessing data using
> different "views", such as pointers of different types.
>
> (I don't think this is an issue with most code - you don't often find
> such problems in "normal" code.
Do you mean bugs having to do with aliasing are rare? I'm not so sure.
I've seen one in a project recently[0]. Different people come up with
designs which have fewer or more crazy casts, and those who use a lot
of them are more vulnerable.
(I might be missing your point here.)
> The exception is that you might view
> data via pointer to a char type, such as for memcpy - and char types are
> specifically allowed to alias anything.)
/Jorgen
[0] Solved, unfortunately, by disabling gcc -fstrict-aliasing, thus
compiling the code using a more forgiving language than C.
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-17 07:48 +0200 |
| Message-ID | <mqrsgc$ph2$1@dont-email.me> |
| In reply to | #67538 |
On 16/08/15 20:34, Jorgen Grahn wrote:
> On Sun, 2015-08-16, David Brown wrote:
>> On 14/08/15 20:32, James Kuyper wrote:
>>> On 08/14/2015 02:19 PM, Ben Bacarisse wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>> ...
>>>>> It is difficult to be sure of the situation with Rick's suggested union,
>>>>> since it is not a complete example. But the general point is that when
>>>>> you change a pointer's type (either by unions or casts), the strict
>>>>> aliasing rules govern when the accesses are defined or not.
>>>>
>>>> Are "strict aliasing rules" different to the effective type rules of 6.5
>>>> p7? I've never been clear exactly what people mean by "strict"
>>>> aliasing.
>>>
>>> The impression I get is that a large fraction of the people who use the
>>> phrase "strict aliasing rules" are referring to the corresponding gcc
>>> command line options. As I understand it, when used for C code,
>>> -fstrict-aliasing enables optimizations that rely upon 6.5p7, while
>>> -wstrict-aliasing turns on diagnostic messages for detected violations
>>> of 6.5p7.
>>>
>>
>> Certainly the term "strict aliasing" is often used in the context of gcc
>> (or clang/llvm, which follows gcc here). It would be better to use a
>> phrase such as "strict application and interpretation of C's aliasing
>> rules" rather than "strict aliasing rules", since the later implies that
>> this is some sort of extra strict rules in the C standards.
>
> Yes. I've noticed that "strict aliasing rules" sounds like
> "unnecessarily strict" to many people -- like caring about it is
> optional and for over-achievers.
>
I too have seen that some people think that way.
Earlier versions of gcc are less "strict" in their interpretation of the
rules than later ones, which take greater advantage of them to produce
more efficient object code. So some people did find that code that
worked with one version of gcc, suddenly failed with newer versions -
and thus the natural view is that the compiler is "too strict", until
they understand the problem with their code.
>> Basically, if the compiler can use the list of rules in 6.5p7 to see
>> that a particular access could not legally alias another given access,
>> then it can optimise with the assumption that the accesses do not alias.
>> This is generally known as "type based alias analysis", or something
>> similar, and is common in optimisation. For example (from
>> <http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>) :
>>
>> float *P;
>> void zero_array() {
>> int i;
>> for (i = 0; i < 10000; ++i)
>> P[i] = 0.0f;
>> }
>>
>> With type-based alias analysis, the compiler knows that stores to P[i]
>> cannot affect pointer P itself, and can turn this into memset(P, 0,
>> 10000 * sizeof int). Without such analysis, it has to assume that
>> someone might set P so that it is within the P array itself - and thus
>> the value of P might change during the loop.
>>
>> In cases like this, alias analysis gives the "obvious" behaviour. But
>> it is quite possible for code to look like it does one thing, but
>> because of strict application of the aliasing rules, the compiler can
>> generate code that does not do what the programmer expects.
>>
>> My experience is that gcc usually generates the obvious code - if it
>> looks like the programmer really wants to use aliasing (or
>> type-punning), the compiler makes code that does what is expected. It
>> may also generate warnings when it thinks there could be a problem. But
>> it is something you always have to think about when accessing data using
>> different "views", such as pointers of different types.
>>
>> (I don't think this is an issue with most code - you don't often find
>> such problems in "normal" code.
>
> Do you mean bugs having to do with aliasing are rare? I'm not so sure.
> I've seen one in a project recently[0]. Different people come up with
> designs which have fewer or more crazy casts, and those who use a lot
> of them are more vulnerable.
>
> (I might be missing your point here.)
It is always dangerous to make generalisations like this - I can only
give a rough impression. So if others think such aliasing issues /are/
common in a lot of code, I'm happy to change that impression!
>
>> The exception is that you might view
>> data via pointer to a char type, such as for memcpy - and char types are
>> specifically allowed to alias anything.)
>
> /Jorgen
>
> [0] Solved, unfortunately, by disabling gcc -fstrict-aliasing, thus
> compiling the code using a more forgiving language than C.
>
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-08-18 18:08 +0000 |
| Message-ID | <slrnmt6t47.eij.grahn+nntp@frailea.sa.invalid> |
| In reply to | #67562 |
On Mon, 2015-08-17, David Brown wrote: > On 16/08/15 20:34, Jorgen Grahn wrote: >> On Sun, 2015-08-16, David Brown wrote: ... [aliasing] >>> (I don't think this is an issue with most code - you don't often find >>> such problems in "normal" code. >> >> Do you mean bugs having to do with aliasing are rare? I'm not so sure. >> I've seen one in a project recently[0]. Different people come up with >> designs which have fewer or more crazy casts, and those who use a lot >> of them are more vulnerable. >> >> (I might be missing your point here.) > > It is always dangerous to make generalisations like this - I can only > give a rough impression. So if others think such aliasing issues /are/ > common in a lot of code, I'm happy to change that impression! Ok, so I didn't miss your point, at least. Well, I cannot honestly claim to know those bugs are common. But the implications of such bugs scare me, about as much as random heap corruption bugs: they can pop up at any time, and cause-and-effect can be hard to discover ... so I feel motivated to make people cut down on casts. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-19 09:36 +0200 |
| Message-ID | <mr1bib$8ei$1@dont-email.me> |
| In reply to | #67744 |
On 18/08/15 20:08, Jorgen Grahn wrote: > On Mon, 2015-08-17, David Brown wrote: >> On 16/08/15 20:34, Jorgen Grahn wrote: >>> On Sun, 2015-08-16, David Brown wrote: > ... > > [aliasing] > >>>> (I don't think this is an issue with most code - you don't often find >>>> such problems in "normal" code. >>> >>> Do you mean bugs having to do with aliasing are rare? I'm not so sure. >>> I've seen one in a project recently[0]. Different people come up with >>> designs which have fewer or more crazy casts, and those who use a lot >>> of them are more vulnerable. >>> >>> (I might be missing your point here.) >> >> It is always dangerous to make generalisations like this - I can only >> give a rough impression. So if others think such aliasing issues /are/ >> common in a lot of code, I'm happy to change that impression! > > Ok, so I didn't miss your point, at least. > > Well, I cannot honestly claim to know those bugs are common. But the > implications of such bugs scare me, about as much as random heap > corruption bugs: they can pop up at any time, and cause-and-effect can > be hard to discover ... so I feel motivated to make people cut down on > casts. > There are several good reasons to avoid casts - and I agree that this is one of them. Be particularly sceptical to anything that involves casts and pointers.
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2015-08-30 03:03 -0400 |
| Message-ID | <4b1mtah58sqriul1sg7ok3tgu1vedmb592@4ax.com> |
| In reply to | #67527 |
On Sun, 16 Aug 2015 16:52:40 +0200, David Brown
<david.brown@hesbynett.no> wrote:
<snip: "strict aliasing">
> ... is generally known as "type based alias analysis", or something
> similar, and is common in optimisation. For example (from
> <http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>) :
>
> float *P;
> void zero_array() {
> int i;
> for (i = 0; i < 10000; ++i)
> P[i] = 0.0f;
> }
>
> With type-based alias analysis, the compiler knows that stores to P[i]
> cannot affect pointer P itself, and can turn this into memset(P, 0,
> 10000 * sizeof int). Without such analysis, it has to assume that
> someone might set P so that it is within the P array itself - and thus
> the value of P might change during the loop.
>
In general 10000 * sizeof (float) -- although clang may well require,
as I believe gcc does, that float and int are both 32 bits -- and only
if all-bits-zero is the (or a) representation of 0.0f -- which is true
for IEEE, and S/360 HFP, and possibly all other FP formats someone
needs to care about, but is not required/guaranteed by C.
(Also: sizeof unaryexpr doesn't require parentheses if the unaryexpr
doesn't, like clc-style sizeof *P here, but sizeof (typename) does.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-30 16:59 +0200 |
| Message-ID | <mrv5ka$g9b$2@dont-email.me> |
| In reply to | #68676 |
On 30/08/15 09:03, David Thompson wrote:
> On Sun, 16 Aug 2015 16:52:40 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> <snip: "strict aliasing">
>> ... is generally known as "type based alias analysis", or something
>> similar, and is common in optimisation. For example (from
>> <http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>) :
>>
>> float *P;
>> void zero_array() {
>> int i;
>> for (i = 0; i < 10000; ++i)
>> P[i] = 0.0f;
>> }
>>
>> With type-based alias analysis, the compiler knows that stores to P[i]
>> cannot affect pointer P itself, and can turn this into memset(P, 0,
>> 10000 * sizeof int). Without such analysis, it has to assume that
>> someone might set P so that it is within the P array itself - and thus
>> the value of P might change during the loop.
>>
> In general 10000 * sizeof (float)
It was a typo on my part. You are of course correct here.
> -- although clang may well require,
> as I believe gcc does, that float and int are both 32 bits -- and only
> if all-bits-zero is the (or a) representation of 0.0f -- which is true
> for IEEE, and S/360 HFP, and possibly all other FP formats someone
> needs to care about, but is not required/guaranteed by C.
>
> (Also: sizeof unaryexpr doesn't require parentheses if the unaryexpr
> doesn't, like clc-style sizeof *P here, but sizeof (typename) does.)
>
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-08-30 20:12 +0000 |
| Message-ID | <mrvo3e$oup$1@speranza.aioe.org> |
| In reply to | #68676 |
David Thompson <dave.thompson2@verizon.net> wrote:
> On Sun, 16 Aug 2015 16:52:40 +0200, David Brown
(snip)
>> ... is generally known as "type based alias analysis", or something
>> similar, and is common in optimisation. For example (from
>> <http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>) :
>> float *P;
>> void zero_array() {
>> int i;
>> for (i = 0; i < 10000; ++i)
>> P[i] = 0.0f;
>> }
>> With type-based alias analysis, the compiler knows that stores to P[i]
>> cannot affect pointer P itself, and can turn this into memset(P, 0,
>> 10000 * sizeof int). Without such analysis, it has to assume that
>> someone might set P so that it is within the P array itself - and thus
>> the value of P might change during the loop.
> In general 10000 * sizeof (float) -- although clang may well require,
> as I believe gcc does, that float and int are both 32 bits -- and only
Fortran requires that INTEGER and REAL be the same size, though
not necessarily use all the bits. The IBM 704, where Fortran started,
stores integers as 16 bits in a 36 bit word.
People doing mixed Fortran and C programming will appreciate
sizeof(int) and sizeof(float) being equal.
> if all-bits-zero is the (or a) representation of 0.0f -- which is true
> for IEEE, and S/360 HFP, and possibly all other FP formats someone
> needs to care about, but is not required/guaranteed by C.
Yes, not required, but enough people expect it that hardware
designers would need a good reason not to use all bits zero for 0.0f.
> (Also: sizeof unaryexpr doesn't require parentheses if the unaryexpr
> doesn't, like clc-style sizeof *P here, but sizeof (typename) does.)
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-05 14:36 -0700 |
| Message-ID | <kfnbndgv98n.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #67527 |
David Brown <david.brown@hesbynett.no> writes:
> On 14/08/15 20:32, James Kuyper wrote:
>> On 08/14/2015 02:19 PM, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>
>> ...
>>
>>>> It is difficult to be sure of the situation with Rick's suggested union,
>>>> since it is not a complete example. But the general point is that when
>>>> you change a pointer's type (either by unions or casts), the strict
>>>> aliasing rules govern when the accesses are defined or not.
>>>
>>> Are "strict aliasing rules" different to the effective type rules of 6.5
>>> p7? I've never been clear exactly what people mean by "strict"
>>> aliasing.
>>
>> The impression I get is that a large fraction of the people who use the
>> phrase "strict aliasing rules" are referring to the corresponding gcc
>> command line options. As I understand it, when used for C code,
>> -fstrict-aliasing enables optimizations that rely upon 6.5p7, while
>> -wstrict-aliasing turns on diagnostic messages for detected violations
>> of 6.5p7.
>
> Certainly the term "strict aliasing" is often used in the context of
> gcc (or clang/llvm, which follows gcc here). It would be better to
> use a phrase such as "strict application and interpretation of C's
> aliasing rules" rather than "strict aliasing rules", since the later
> implies that this is some sort of extra strict rules in the C
> standards.
A better term is "takes full advantage of effective type rules"
since "effective type" is a term defined in the C standard for
just the purpose of aliasing questions.
> Basically, if the compiler can use the list of rules in 6.5p7 to see
> that a particular access could not legally alias another given access,
> then it can optimise with the assumption that the accesses do not
> alias. This is generally known as "type based alias analysis", or
> something similar, and is common in optimisation. For example (from
> <http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>)
> :
>
> float *P;
> void zero_array() {
> int i;
> for (i = 0; i < 10000; ++i)
> P[i] = 0.0f;
> }
>
> With type-based alias analysis, the compiler knows that stores to P[i]
> cannot affect pointer P itself, and can turn this into memset(P, 0,
> 10000 * sizeof int). Without such analysis, it has to assume that
> someone might set P so that it is within the P array itself - and thus
> the value of P might change during the loop.
This isn't a good example, because the last statement is
wrong: there are other ways a compiler could deduce that
the pointer P could not point to itself (ie, in a program
with no undefined behavior otherwise). Generally the
easiest way to illustrate the potential for alias analysis
is with a function with two different pointer types, eg,
(int *) and (float *).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-05 12:39 -0700 |
| Message-ID | <kfn1tecwt8j.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #67416 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > David Brown <david.brown@hesbynett.no> writes: > >> On 14/08/15 12:19, Ben Bacarisse wrote: >>> David Brown <david.brown@hesbynett.no> writes: > > <snip> > >>>> What did you think of my concerns about aliasing, discussed in other >>>> posts? > > <snip> > >>> In the situation being discussed here, the object will always be >>> accessed via a pointer of the right type, will it not? After all, >>> that's the point of Rick's hack -- to ensure that the type is correct >>> without actually converting a value. On this rather superficial >>> analysis, I'd say that there's no problem specifically relating to >>> aliasing. Maybe you have an example in mind? >> >> It is difficult to be sure of the situation with Rick's suggested union, >> since it is not a complete example. But the general point is that when >> you change a pointer's type (either by unions or casts), the strict >> aliasing rules govern when the accesses are defined or not. > > Are "strict aliasing rules" different to the effective type rules of 6.5 > p7? I've never been clear exactly what people mean by "strict" > aliasing. The term "strict aliasing" is a gcc-ism (and since adopted by other implementations IIANM). For C it means taking full advantage of C's effective type rules. For C++ it means taking full advantage of the corresponding rules in C++ (which are not quite the same as they are in C). IMO the term "strict aliasing" is bad because it is misleading about what it implies, but everyone uses it so I guess we are stuck with it. When talking about C, the term "effective type rules" is IMO a better term to use. Programs that do not satisfy effective type rules have undefined behavior, regardless of whether a "strict aliasing" option is in effect. Incidentally, I remember reading somewhere at some time in the past that the "strict aliasing" option actually goes beyond what effective type rules allow, ie, that programs could be defined C as far as effective type rules are concerned but translated incorrectly by gcc if a "strict aliasing" option were in effect. However I can find no trace of this proposition now, so I don't know if it was true in the past but is no longer, or was never true and I simply misunderstood, or some other eventuality (eg, bad memory). In any case to all appearances it seems that the description now is consistent with the proposition that "strict aliasing" means taking full advantage of effective type rules in C (or their counterparts if compiling another language).
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-14 07:56 -0700 |
| Message-ID | <8b8b1d44-d729-4826-b622-c913f1701ed6@googlegroups.com> |
| In reply to | #67376 |
On Friday, August 14, 2015 at 6:19:20 AM UTC-4, Ben Bacarisse wrote: > ...It's clear the Rick sees the whole idea of > programming in a very different way to me. C, in particular, is a means > to a mechanical end -- to get the machine to do what he wants -- and the > type system juts gets in the way. (Ironically, given his rants about > ancient history, he'd probably prefer B or BCPL.) I don't think the type system gets in the way. I just recognize on the machine level what it's doing, and I can see that when I want to take an existing block of data pointed at by and address, and view it through struct xyz* and examine xyz's members, and then take that exact same block of memory and examine it through struct abc*'s members, then there's no reason why I shouldn't be able to do that -- at least not from the hardware level on the machines I've used. And I'll say it one more time: I think catering to those obscure machines which exhibit behavior like your example where void* was bytes, but other pointers were words, for every developer everywhere all of the time, is simply wrong. *ONLY* those developers who operate on such a weird machine like that should have to jump through hoops, not the rest of us. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-14 17:09 +0100 |
| Message-ID | <87r3n5ybpc.fsf@bsb.me.uk> |
| In reply to | #67397 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Friday, August 14, 2015 at 6:19:20 AM UTC-4, Ben Bacarisse wrote: >> ...It's clear the Rick sees the whole idea of >> programming in a very different way to me. C, in particular, is a means >> to a mechanical end -- to get the machine to do what he wants -- and the >> type system juts gets in the way. (Ironically, given his rants about >> ancient history, he'd probably prefer B or BCPL.) > > I don't think the type system gets in the way. I just recognize on the > machine level what it's doing, and I can see that when I want to take > an existing block of data pointed at by and address, and view it through > struct xyz* and examine xyz's members, and then take that exact same > block of memory and examine it through struct abc*'s members, then there's > no reason why I shouldn't be able to do that -- at least not from the > hardware level on the machines I've used. Of course, and C lets you do that. What's more, if you do it right, it works on every machine, but for some mysterious reason you are suggesting a union that stops C from doing what you describe here on some machines. OK, so you don't care about those machine. Fine. If it only limited portability to odd machines, and it was in some way simpler to use, then you might have a point, but it's actually more complicated and leads to your code being, let's say, deceptive. > And I'll say it one more time: I think catering to those obscure machines > which exhibit behavior like your example where void* was bytes, but other > pointers were words, for every developer everywhere all of the time, is > simply wrong. Your union hack would still be wrong even if C guaranteed that all pointers have the same representation. And since the correct way to convert between types is with a conversion and not through a union, C can avoid having to make this guarantee, and everyone (except you) wins. > *ONLY* those developers who operate on such a weird machine > like that should have to jump through hoops, not the rest of us. No, the hoops are only in your mind (at least I think they are). I've asked for an example where your hack simplifies things (so that I can see if you have point or not), but none has been forthcoming. Without one, I have to rely on my own examples, and your union *complicates* all of the ones I can think up (but, as you can imagine, I'm not trying very hard). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-14 11:38 -0700 |
| Message-ID | <60067692-9ed5-4144-a99c-afa81a0b0960@googlegroups.com> |
| In reply to | #67415 |
On Friday, August 14, 2015 at 2:19:53 PM UTC-4, Ben Bacarisse wrote: > Your union hack would still be wrong even if C guaranteed that all > pointers have the same representation. And since the correct way to > convert between types is with a conversion and not through a union, C > can avoid having to make this guarantee, and everyone (except you) wins. I don't think you understand what I'm doing with the union. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-14 20:31 +0100 |
| Message-ID | <87egj5y8e9.fsf@bsb.me.uk> |
| In reply to | #67419 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Friday, August 14, 2015 at 2:19:53 PM UTC-4, Ben Bacarisse wrote:
>> Your union hack would still be wrong even if C guaranteed that all
>> pointers have the same representation. And since the correct way to
>> convert between types is with a conversion and not through a union, C
>> can avoid having to make this guarantee, and everyone (except you) wins.
>
> I don't think you understand what I'm doing with the union.
That would be great. Though this long exchange would prove to have been
a fractious waste of time, I can think of no better resolution than it
having been a simple misunderstanding.
Let's re-cap. Morten posted a link to some code that needed a cast:
new->parent = ((struct xml_element *)previous)->parent;
because 'previous' was of type void *.
You suggested an alternative -- a union with a void * member and a
struct xml_element * member (I think I've changed the names). The gist
of your suggestion seemed to be to use
union xml_pointer {
void *void_ptr;
struct xml_node *node_ptr;
};
union xml_pointer previous;
so that a pointer like 'previous' can be used (and set) as if it were a
void *:
previous.void_ptr
or as if it were pointer to an xml_node. The line that needed a cast
could, therefore, be written:
new->parent = previous.xml_node->parent;
Now there were some problems with the details (what you wrote could not
literally be plugged into Morten's code) but I tried to correct for
those at the time and I'm reflecting those slight alterations here.
Is this not what you were proposing? If it's not, I'm surprised that
you and I could have kept up the subsequent exchange because it only
seems to make sense if this is what your union hack consists of.
I write this in an attempt to being the discussion to a close; no one
wants it to go on and on. If I've got the wrong end of the stick there
may have to be some more discussion to sort out what it was you *did*
mean, but if this is roughly correct I think we should just agree to
differ.
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web