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 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-05 11:39 -0700 |
| Message-ID | <kfnmvx0ww1g.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #67219 |
luser droog <luser.droog@gmail.com> writes: > On Wednesday, August 12, 2015 at 5:39:24 AM UTC-5, Ben Bacarisse wrote: > >> Unions have two functions. One, to save space by enabling the storage >> [...] >> >> The second use is to re-interpret the representation of one type as if >> it were another. This is a much and specialised usage. > > Indeed this is the /only/ way if you want avoid weird warnings > about "strict aliasing" that pointer-punning can produce. It is a way, but not the only way. There is also character copying (or equivalently memcpy()).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-06 11:24 +0200 |
| Message-ID | <msh0lo$ko7$1@dont-email.me> |
| In reply to | #69514 |
On 05/09/15 20:39, Tim Rentsch wrote: > luser droog <luser.droog@gmail.com> writes: > >> On Wednesday, August 12, 2015 at 5:39:24 AM UTC-5, Ben Bacarisse wrote: >> >>> Unions have two functions. One, to save space by enabling the storage >>> [...] >>> >>> The second use is to re-interpret the representation of one type as if >>> it were another. This is a much and specialised usage. >> >> Indeed this is the /only/ way if you want avoid weird warnings >> about "strict aliasing" that pointer-punning can produce. Avoiding warnings is not the aim - avoiding /mistakes/ is the priority! Warnings indicate that code might not do what you intended, and should be taken seriously. > > It is a way, but not the only way. There is also > character copying (or equivalently memcpy()). > And as long as your compiler has optimisation for memcpy(), that's quite a good way to do it - gcc (the only compiler I have studied in detail for this) will happily turn memcpy() calls into optimal code without even having to pass anything through memory if it can avoid it. On the other hand, poorer compilers, or good compilers with no optimisation flags specified, will generate calls to library memcpy functions leading to very much bigger and slower code. So if code size and speed is relevant, be wary of using memcpy without examining the results for the particular compiler/flags/target that interests you. Of course making code correct is higher priority than code speed, but in some situations speed is also a requirement.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-06 18:09 -0700 |
| Message-ID | <kfnvbbnnigu.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #69591 |
David Brown <david.brown@hesbynett.no> writes: > On 05/09/15 20:39, Tim Rentsch wrote: >> luser droog <luser.droog@gmail.com> writes: >> >>> On Wednesday, August 12, 2015 at 5:39:24 AM UTC-5, Ben Bacarisse wrote: >>> >>>> Unions have two functions. One, to save space by enabling the storage >>>> [...] >>>> >>>> The second use is to re-interpret the representation of one type as if >>>> it were another. This is a much and specialised usage. >>> >>> Indeed this is the /only/ way if you want avoid weird warnings >>> about "strict aliasing" that pointer-punning can produce. > > Avoiding warnings is not the aim - avoiding /mistakes/ is the priority! > Warnings indicate that code might not do what you intended, and should > be taken seriously. > >> It is a way, but not the only way. There is also >> character copying (or equivalently memcpy()). > > And as long as your compiler has optimisation for memcpy(), that's quite > a good way to do it - [snip] That's incidental to my point, which is only about correctness.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-12 10:17 -0700 |
| Message-ID | <280a9a48-4e30-4b8b-a395-9d6031db7d48@googlegroups.com> |
| In reply to | #67158 |
On Tuesday, August 11, 2015 at 10:45:34 PM UTC-4, Ben Bacarisse wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
>
> > On 12.08.2015 03:56, Ben Bacarisse wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >>
> >>> On Tuesday, August 11, 2015 at 4:32:29 PM UTC-4, Rick C. Hodgin wrote:
> >>>> struct SWhatever {
> >>>> union {
> >>>> void* previous;
> >>>> struct xml_element* prev_xml_element;
> >>>> struct xml_whatever* prev_xml_whatever;
> >>>> };
> >>>> };
> >>>
> >>> Before I get pounced on by snipers, it should be as above.
> >>
> >> Sorry, I have to snipe because that's not a safe technique (unless I'm
> >> misunderstanding how you intended to use the union). A cast permits the
> >> pointer to be converted from one type to another, but the union causes
> >> the bits to be re-interpreted and that's not 100% portable. Of course
> >> it may work everywhere that matters to you, but other readers may want
> >> to take care.
> >
> > Well, isn't a pointer a pointer regardless of what it points to? I
> > thought the point of casting was so that the compiler could find the
> > right offsets etc. to work on in a struct.
>
> That's only part of it. On one machine I've used a cast from void * to
> a pointer to any struct type generated code to halve the address: void *
> was a byte pointer and struct pointers were word pointers. Were you to
> do this:
>
> struct xml_element elem;
> struct SWhatever sw = { .previous = &elem; };
>
> you'd find that &elem != sw.prev_xml_element. The initialisation
> converts the word pointer to a byte pointer, but the union access simply
> re-interprets the converted bits as something they are not.
There are no circumstances where I would consider not using a union
to reinterpret bits based on the fact that an architecture like this
exists.
Instead, I would switch the warning you issue around completely and
WARN EVERYONE to NOT use such an architecture because it breaks the
ability to use unions properly. Or, to WARN EVERYONE that if they
do use this architecture, they'll have to handle unions differently.
-----
I really think you've got it backwards here, Ben. This should be the
far-and-away occasional exception you might encounter once in your
career when then forces you, for that project, to alter the way you
normally write code, and not the you-must-daily-cater-to-it rule.
Again, I think it is completely insane to suggest avoiding using
unions in this way because there are architectures like this which
exist. On top of which, I'm frankly amazed there are architectures
like this which exist. It must be for some optimized application,
which in and of itself would warrant special coding requirements.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-12 20:58 +0100 |
| Message-ID | <87d1ys5gmr.fsf@bsb.me.uk> |
| In reply to | #67214 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Tuesday, August 11, 2015 at 10:45:34 PM UTC-4, Ben Bacarisse wrote:
>> "Morten W. Petersen" <morphex@gmail.com> writes:
>>
>> > On 12.08.2015 03:56, Ben Bacarisse wrote:
>> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> >>
>> >>> On Tuesday, August 11, 2015 at 4:32:29 PM UTC-4, Rick C. Hodgin wrote:
>> >>>> struct SWhatever {
>> >>>> union {
>> >>>> void* previous;
>> >>>> struct xml_element* prev_xml_element;
>> >>>> struct xml_whatever* prev_xml_whatever;
>> >>>> };
>> >>>> };
>> >>>
>> >>> Before I get pounced on by snipers, it should be as above.
>> >>
>> >> Sorry, I have to snipe because that's not a safe technique (unless I'm
>> >> misunderstanding how you intended to use the union). A cast permits the
>> >> pointer to be converted from one type to another, but the union causes
>> >> the bits to be re-interpreted and that's not 100% portable. Of course
>> >> it may work everywhere that matters to you, but other readers may want
>> >> to take care.
>> >
>> > Well, isn't a pointer a pointer regardless of what it points to? I
>> > thought the point of casting was so that the compiler could find the
>> > right offsets etc. to work on in a struct.
>>
>> That's only part of it. On one machine I've used a cast from void * to
>> a pointer to any struct type generated code to halve the address: void *
>> was a byte pointer and struct pointers were word pointers. Were you to
>> do this:
>>
>> struct xml_element elem;
>> struct SWhatever sw = { .previous = &elem; };
>>
>> you'd find that &elem != sw.prev_xml_element. The initialisation
>> converts the word pointer to a byte pointer, but the union access simply
>> re-interprets the converted bits as something they are not.
>
> There are no circumstances where I would consider not using a union
> to reinterpret bits based on the fact that an architecture like this
> exists.
Nor I. When I want to reinterpret bits, I use a union (or the more
dodgy *(T *)&object) idiom). The argument is over the fact that you
advocate using a union when you mean a type conversion from one type to
another.
> Instead, I would switch the warning you issue around completely and
> WARN EVERYONE to NOT use such an architecture because it breaks the
> ability to use unions properly.
The union is doing exactly what it should. If you simplified the code
by removing the unnecessary union, and then replaced the member access
with a conversion (which may not even need a cast -- it depends) you'll
have clearer code (because it's explicit about what it does) which just
happens to work on odd machines.
<snip>
> Again, I think it is completely insane to suggest avoiding using
> unions in this way because there are architectures like this which
> exist.
There are other reasons to avoid using a union where a conversion is
intended.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-12 19:59 -0700 |
| Message-ID | <b7ce5af1-f865-451e-913d-4447aa620311@googlegroups.com> |
| In reply to | #67225 |
On Wednesday, August 12, 2015 at 5:41:42 PM UTC-4, Ben Bacarisse wrote: > ... The argument is over the fact that you advocate using a union when > you mean a type conversion from one type to another. Well, Ben... I know you interpret what I mean under the context of the understanding you have about what you think I mean, but you are doing so with values placed in areas where I do not have values, and you are doing so with no values placed in areas where I do have values. As such, we will never see eye-to-eye on this until one or more of us changes... But, that being said... I do not mean type conversion. I mean there is a pointer pointing to a location in memory where data has been arranged a particular way. The data exists. And the pointer can enter in to wherever it's used via any form of carrier, yet in the end, that pointer always points back to the start of that block of data, regardless of whether it's assigned to a void*, struct xyz*, int*, or any other form of pointer. This is the requirement of what I consider to be a proper C standard, and a proper machine architecture. Use of a union in that case allows that data to be viewed through a series of lenses, each with a particular polarization allowing different views from the same form. When a particular structure is applied on that data, it presents a particular way. When another structure is applied, it presents in another way. But when viewed through both structures, the underlying data did not change, nor has the address that data in memory changed, nor has any value used by any of the pointers which access it. The pointer value resolves back to some address which points to that block of data. That's the way it is on x86 and ARM. And that's the way it should be in the standard. That's my position. And that's my argument. ----- I would go so far in my declaration on the necessity of that ability existing, that I would say any architecture which does not support it is, by definition, a /fringe/ architecture, and one that by its very design requires some type of specialized programming beyond the scope of normal things. And as such, the requirements of that fringe architecture have no place whatsoever in the C standard, but should be entirely relegated to footnotes, caveats, and addendums, all of which exist above or outside the standard, in a layer of extensions. ----- As I've said many times, the C standard should be for the standard core set of abilities, with extensions defined allowing all sorts of fringe things to also exist, but only being expressly identified as being exactly that: fringe things, and not standard things. I cannot imagine the mindset where the needs of a few tiny machine architectures, featuring traits so obscure as to be the noted fringe things which exist against the catalog of modern architectures, would then dictate (via the C standard) that all code written for the much larger catalog of machines which do not require nor exhibit those rare traits, cater to those most peculiar of traits, forcing all developers everywhere to support the smallest handful of the obtuse architectures. It's beyond my imagination that anyone would want to support such a standard, save having a personal and specific need of using that architecture for whatever reason -- but even then, the fact that it is of such a peculiar form, it would and should have some special programming needs which are flagged and defined well outside of the standard. I will never live at that place. And I will advise anyone who would approach an architecture with different pointer sizes to reconsider something more modern, more standard, less peculiar, for the sake of developer sanity. And as such, I will advise everyone on using unions for pointers because they greatly simplify code at the expense of some compile-time type checking, but when you realize that pointers are just N-bit quantities, then you also realize that it does not matter how they are carried, and that they can be passed by any N-bit hauler to get from A to B, to then be cast into their role as by the mighty union. In any event, barring answering questions, this is my final post on the matter. And I really am shocked that there are people purporting to write code in such a way when it will only make a difference on the smallest fringe architectures that most developers will never see. RDC will define pointers which are all the same size and can be used in a union without reservation. And on those obtuse architectures RDC might be ported to, it will be advised that the lack of the ability to have union-based shared pointers without casting, that a few compiler warnings be injected to advise the developer on the odd use, but only on that architecture, and those warnings will not be generated for the masses. I really am shocked at the thinking. To me it is completely backwards, and not as it should be. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-13 13:47 +0200 |
| Message-ID | <mqi018$eaf$1@dont-email.me> |
| In reply to | #67252 |
On 13/08/15 04:59, Rick C. Hodgin wrote: > That's the way it is on x86 and ARM. And that's the way it should be > in the standard. That's my position. And that's my argument. > I think at least some of this argument is because you seem to think a /pointer/ is just an /address/. That is not the case in C. A /pointer/ certainly contains an address, but it also has a type - and the type is important. A pointer to an "int" is not the same thing as a pointer to a "struct foo". It does not matter whether the pointers have the same size, or the same implementation in the hardware - that's irrelevant. The two pointers have different types. This is important to the programmer, in order to be able to write clearer code and to get the best possible help from the tools in avoiding or spotting mistakes. If you mix up objects of different types, whether they are pointers or not, it's often a good indication of an error in the code. Writing casts explicitly can be a good way of making it clear that you know what you are doing in this slightly dangerous or difficult code. The type differences are also important to the compiler - as well as obvious uses (such as when type changes mean real code and value changes, for example when changing between an int and a double), 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. None of this has anything to do with how pointers happen to be implemented in different targets or compilers - it applies equally to x86 and ARM.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-13 05:35 -0700 |
| Message-ID | <003ef111-3124-49dc-b5cc-4d1bc0cc258c@googlegroups.com> |
| In reply to | #67270 |
On Thursday, August 13, 2015 at 7:47:32 AM UTC-4, David Brown wrote: > On 13/08/15 04:59, Rick C. Hodgin wrote: > > > That's the way it is on x86 and ARM. And that's the way it should be > > in the standard. That's my position. And that's my argument. > > > > I think at least some of this argument is because you seem to think a > /pointer/ is just an /address/. That is not the case in C. A /pointer/ > certainly contains an address, but it also has a type - and the type is > important. A pointer to an "int" is not the same thing as a pointer to > a "struct foo". It does not matter whether the pointers have the same > size, or the same implementation in the hardware - that's irrelevant. > The two pointers have different types. > > This is important to the programmer, in order to be able to write > clearer code and to get the best possible help from the tools in > avoiding or spotting mistakes. If you mix up objects of different > types, whether they are pointers or not, it's often a good indication of > an error in the code. Writing casts explicitly can be a good way of > making it clear that you know what you are doing in this slightly > dangerous or difficult code. > > The type differences are also important to the compiler - as well as > obvious uses (such as when type changes mean real code and value > changes, for example when changing between an int and a double), 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. > > None of this has anything to do with how pointers happen to be > implemented in different targets or compilers - it applies equally to > x86 and ARM. The C language relates information through translation to the needs of physical hardware, which conducts the work. As such, pointers are addresses fundamentally. The type form is only important to the compiler because it conveys information needed to access members when they are used in processing. However, the memory address for the start of something is always the same regardless of whether it's been cast to a void*, a struct xyz*, or some native form pointer. And where it's not, I dub that to be a /fringe/ architecture that has no place in the standard. Fundamentally, my argument is that the standard is too restrictive in its current form, and mandates that unnecessary and unwieldy coding requirements be applied to all developers everywhere, when they are not necessary except on those system to which they are necessary, and in all of those cases it should be the exception and not the rule, being applied to them only. I don't know how to be more clear about this. If you examine the assembly code generated for a compiled C program, you'll find nothing about types. You'll find machine-based fundamental accesses to memory and other machine resources. That's what's really taking place when you write a C program. The types are just there to make it easy for human beings to wield and relate to. But once it gets past the compiler, never again are any types considered, and from that point forward the instructions/command sequences the compiler generated for the hardware will conduct fundamental machine-based unit workloads to carry out the work, which gives the data the appearance of the original thing, without respect to optimization, for the purposes of doing the work as indicated. And in the case of optimization, it was the compiler which determined what could be removed because it wasn't used, needed that way, or whatever, while still fulfilling the workload portion that is required, is used, is needed, or whatever. I come from a low-level background, and I think in those terms. I do recognize what the translation of the pointer type means to hardware, and I place value on that hardware-side of the equation because within the confines of C alone, it is unnecessarily restrictive (when it doesn't need to be at the hardware level). These "hacks" as Ben calls them work correctly in Windows, Linux, and on Microsoft's compilers and GCC for x86 and ARM, and I bet they work on many other systems, most other systems even, and on many other hardware forms. They don't work on all of them, and therein lies the issue I take with that reality existing in the C /standard/. I believe that C should account for those peculiar hardware forms, but they should be extensions, and not part of the standard, because the standard should relate more closely to physical hardware in its current semiconductor form, which is the form which has existed since at least the 1980s in 32-bit form, and back to the early 70s in 4-bit and larger forms. We have a tool that is well distributed (semiconductor-based processors). We have a toolset designed to program those processors (languages like C). And there's no reason the two of them shouldn't have a more fundamental awareness of each other, or at least that the toolset should not have a more fundamental awareness of the tool itself. And for what it's worth, I honestly don't understand why people I would consider to be experts like Ben, do not understand this fundamental relationship of the toolset knowing the tool in a more directly connected way. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-13 15:59 +0200 |
| Message-ID | <mqi7oj$cn8$1@dont-email.me> |
| In reply to | #67279 |
On 13/08/15 14:35, Rick C. Hodgin wrote: > On Thursday, August 13, 2015 at 7:47:32 AM UTC-4, David Brown wrote: >> On 13/08/15 04:59, Rick C. Hodgin wrote: >> >>> That's the way it is on x86 and ARM. And that's the way it should be >>> in the standard. That's my position. And that's my argument. >>> >> >> I think at least some of this argument is because you seem to think a >> /pointer/ is just an /address/. That is not the case in C. A /pointer/ >> certainly contains an address, but it also has a type - and the type is >> important. A pointer to an "int" is not the same thing as a pointer to >> a "struct foo". It does not matter whether the pointers have the same >> size, or the same implementation in the hardware - that's irrelevant. >> The two pointers have different types. >> >> This is important to the programmer, in order to be able to write >> clearer code and to get the best possible help from the tools in >> avoiding or spotting mistakes. If you mix up objects of different >> types, whether they are pointers or not, it's often a good indication of >> an error in the code. Writing casts explicitly can be a good way of >> making it clear that you know what you are doing in this slightly >> dangerous or difficult code. >> >> The type differences are also important to the compiler - as well as >> obvious uses (such as when type changes mean real code and value >> changes, for example when changing between an int and a double), 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. >> >> None of this has anything to do with how pointers happen to be >> implemented in different targets or compilers - it applies equally to >> x86 and ARM. > > The C language relates information through translation to the needs of > physical hardware, which conducts the work. As such, pointers are > addresses fundamentally. The type form is only important to the > compiler because it conveys information needed to access members when > they are used in processing. The type information is /critical/ - types are a vital part of C. This is why pointers are more than just a simple address. > However, the memory address for the start > of something is always the same regardless of whether it's been cast to > a void*, a struct xyz*, or some native form pointer. And where it's > not, I dub that to be a /fringe/ architecture that has no place in the > standard. I know you like to treat all systems that don't have a single linear address space, and identical pointer representation for all types, as being weird or "fringe" and therefore not relevant to most programmers. I am somewhat in agreement with you, although not necessarily about pointer size (since I fail to see any reason why it is particularly relevant - if simplifying portability assumptions don't lead to easer or clearer code, then there is no point in making them). Having a single address space is much more relevant - and I (and most programmers) typically write code with that assumption. That is even though I /do/ work with processors that have more than one address space - I am happy to accept that code written for these processors may not be portable back and forth between other processors, because writing such fully portable code is ugly. However, for the issues under discussion here, the fact that pointers to different types are the same size on most architectures is irrelevant. Please put it out of your mind for now - everything I wrote applies to x86 and ARM as much as to AVR's or "fringe" systems. > > Fundamentally, my argument is that the standard is too restrictive in > its current form, and mandates that unnecessary and unwieldy coding > requirements be applied to all developers everywhere, when they are > not necessary except on those system to which they are necessary, and > in all of those cases it should be the exception and not the rule, > being applied to them only. > > I don't know how to be more clear about this. Again, I don't disagree with you on this general principle (though we differ in the details). But you are missing the point. You have to understand how types work in C, and what they mean. Just as a 32-bit "int" is a completely different thing than a 32-bit "float" despite being the same size, an int* pointer is a completely different thing than a float* pointer. There are times when types are different, but near enough that you can usefully convert between them - and perhaps usefully do so without any code being generated at all. But logically, in C, it is still a conversion. > > If you examine the assembly code generated for a compiled C program, > you'll find nothing about types. That is because assembly is a typeless language, while C has a type system. When the C code is compiled to assembly, the type information is lost. > You'll find machine-based fundamental > accesses to memory and other machine resources. That's what's really > taking place when you write a C program. The types are just there to > make it easy for human beings to wield and relate to. Types also exist to help you write /correct/ code, and readable and maintainable code - even if that is not easier. They can also help the compiler generate better object code. > But once it > gets past the compiler, never again are any types considered, and from > that point forward the instructions/command sequences the compiler > generated for the hardware will conduct fundamental machine-based unit > workloads to carry out the work, which gives the data the appearance > of the original thing, without respect to optimization, for the purposes > of doing the work as indicated. And in the case of optimization, it was > the compiler which determined what could be removed because it wasn't > used, needed that way, or whatever, while still fulfilling the workload > portion that is required, is used, is needed, or whatever. > > I come from a low-level background, and I think in those terms. I do > recognize what the translation of the pointer type means to hardware, > and I place value on that hardware-side of the equation because within > the confines of C alone, it is unnecessarily restrictive (when it doesn't > need to be at the hardware level). I am not trying to be competitive here, but believe I come from a lower-level background than you do, with a wider experience of many more processor architectures, including how they are designed as well as their ISA and assemblies, and have long experience as an assembler and low-level C programmer. I haven't done much on the x86, unlike you, but I have worked with many more architectures. And I believe that I pay a lot more attention to the generated code than most C programmers, yourself included - because for many of the systems I work with, careless C coding can mean correct but inefficient generated code, which means bigger and more expensive microcontrollers. It is a good thing to understand the compilation process, and be aware of how things work underneath. But it is not a good thing to get obsessive about it, or to make the mistake of thinking that you understand exactly what the compiler will do - compilers have a great deal of flexibility in how they generate code. > > These "hacks" as Ben calls them work correctly in Windows, Linux, and on > Microsoft's compilers and GCC for x86 and ARM, and I bet they work on > many other systems, most other systems even, and on many other hardware > forms. There are two issues with your hacks, one of which Ben is concerned with, and the other of which I have been discussing. Neither is target dependent - and they apply as much to gcc, x86, ARM, Linux, and Windows as any other system. 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. Secondly, I pointed out the strict aliasing issues with your solution. These are, to the best of my knowledge, facts - the C standards have rules about aliasing, and compilers use these rules when generating code. If you break these rules, your code is incorrect and has undefined behaviour, and whether it does or does not work as intended is a matter of circumstance. Thus your code is wrong, /even if it appears to work/. Being bad style is not necessarily a serious "crime", but it is not something to recommend to others. (Or since this is a self-correcting newsgroup, you /can/ recommend it to someone else - and then listen when others say it is bad style. We learn by answering questions as well as posing them.) And while your code may work in the circumstances that you tested it, it will fail in other cases. In particular, it will fail when heavy optimisations in a good compiler lead the compiler to take advantage of the strict aliasing rules. > They don't work on all of them, and therein lies the issue I take > with that reality existing in the C /standard/. I believe that C should > account for those peculiar hardware forms, but they should be extensions, > and not part of the standard, because the standard should relate more > closely to physical hardware in its current semiconductor form, which is > the form which has existed since at least the 1980s in 32-bit form, and > back to the early 70s in 4-bit and larger forms. Again, this is all irrelevant. > > We have a tool that is well distributed (semiconductor-based processors). > We have a toolset designed to program those processors (languages like > C). And there's no reason the two of them shouldn't have a more > fundamental awareness of each other, or at least that the toolset should > not have a more fundamental awareness of the tool itself. > > And for what it's worth, I honestly don't understand why people I would > consider to be experts like Ben, do not understand this fundamental > relationship of the toolset knowing the tool in a more directly connected > way. > You are hung up on the wrong points, that don't really matter here. Ben has tried to make you see that.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-13 07:57 -0700 |
| Message-ID | <96f6264a-4476-4b8d-bf42-8d264cb5a50b@googlegroups.com> |
| In reply to | #67293 |
On Thursday, August 13, 2015 at 9:59:30 AM UTC-4, David Brown wrote: > On 13/08/15 14:35, Rick C. Hodgin wrote: > > On Thursday, August 13, 2015 at 7:47:32 AM UTC-4, David Brown wrote: > >> On 13/08/15 04:59, Rick C. Hodgin wrote: > >> > >>> That's the way it is on x86 and ARM. And that's the way it should be > >>> in the standard. That's my position. And that's my argument. > >>> > >> > >> I think at least some of this argument is because you seem to think a > >> /pointer/ is just an /address/. That is not the case in C. A /pointer/ > >> certainly contains an address, but it also has a type - and the type is > >> important. A pointer to an "int" is not the same thing as a pointer to > >> a "struct foo". It does not matter whether the pointers have the same > >> size, or the same implementation in the hardware - that's irrelevant. > >> The two pointers have different types. > >> > >> This is important to the programmer, in order to be able to write > >> clearer code and to get the best possible help from the tools in > >> avoiding or spotting mistakes. If you mix up objects of different > >> types, whether they are pointers or not, it's often a good indication of > >> an error in the code. Writing casts explicitly can be a good way of > >> making it clear that you know what you are doing in this slightly > >> dangerous or difficult code. > >> > >> The type differences are also important to the compiler - as well as > >> obvious uses (such as when type changes mean real code and value > >> changes, for example when changing between an int and a double), 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. > >> > >> None of this has anything to do with how pointers happen to be > >> implemented in different targets or compilers - it applies equally to > >> x86 and ARM. > > > > The C language relates information through translation to the needs of > > physical hardware, which conducts the work. As such, pointers are > > addresses fundamentally. The type form is only important to the > > compiler because it conveys information needed to access members when > > they are used in processing. > > The type information is /critical/ - types are a vital part of C. This > is why pointers are more than just a simple address. It's only critical in instructing the compiler how to generate code which accesses data relative to the location it's pointing to. It's not critical beyond that, and the underlying address of the pointer will change, only the relative offsets to that address are what's important, and that's where the type comes in ... at compile time. Once we're in runtime, any accesses through that type will have been generated to use that location in memory, plus the offsets to access the members. And as such, it shouldn't matter how the pointer address was populated, which should allow it to be valid in a union. > However, for the issues under discussion here, the fact that pointers to > different types are the same size on most architectures is irrelevant. > Please put it out of your mind for now - everything I wrote applies to > x86 and ARM as much as to AVR's or "fringe" systems. A pointer is a pointer. And I would not use any system that had different pointer sizes for data referenced as an int, or a struct, or as any other form. I would consider that a bad design, a fatal flaw, and something to be avoided. The only cases where I would use a system which did have different pointer sizes was it was part of a heterogeneous design, which employed different cores internally which operated on different things. But, that is a special beast, and I would expect to do some custom programming to properly wield its peculiar data structure ... just as I would any other machine that didn't use the same pointer sizes. I would not make it part of the standard. > You have to understand how types work in C, and what they mean. Just as > a 32-bit "int" is a completely different thing than a 32-bit "float" > despite being the same size, an int* pointer is a completely different > thing than a float* pointer. They are only different to the compiler, and how the compiler would then access the underlying data. As far as the hardware is concerned, it doesn't matter in cache or memory if the data is from a float, an int, a char, a pointer, or a structure containing all kinds of various types arranged throughout. It's just data. The purpose of the union is to allow that address in memory to be viewed differently, as by the peculiarities of each pointer type. This could mean looking at an IEEE-754 floating point representation as a series of bytes, or as an unsigned integer, or as part of a structure which actually then shows invalid data because it was never meant to be applied to it, but through an application of that particular pointer, it is pulled through in that invalid way. > There are times when types are different, but near enough that you can > usefully convert between them - and perhaps usefully do so without any > code being generated at all. But logically, in C, it is still a conversion. If you are wanting to migrate from one form to another form then you use the conversion. If you are simply wanting to look at the underlying data differently, then you do not apply the conversion, but merely reference it through the other pointer. > It is a good thing to understand the compilation process, and be aware > of how things work underneath. But it is not a good thing to get > obsessive about it, or to make the mistake of thinking that you > understand exactly what the compiler will do - compilers have a great > deal of flexibility in how they generate code. #1 I'm not obsessive about it. It just happens to be THE relationship source code has with compiled code, and then compiled code has with the hardware. #2 I don't particularly care what the compiler will do. When I use a new pointer type to access data within, and I access the members of that data, I will be reaching into something the compiler should've known about by the fact that it was referenced in that way. This knowing would've prevented it from making some kind of optimization which then alters what I would see in the structure. > First, Ben dislikes your use of a union for type conversion because it > is unclear, and does not express the programmer's intentions well. I disagree that it is unclear because the fact that the pointer is in a union conveys an implicit cast, and in the case of the extra type member, it makes it clear how it is setup by quick inspection. > 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. > > Secondly, I pointed out the strict aliasing issues with your solution. > These are, to the best of my knowledge, facts - the C standards have > rules about aliasing, and compilers use these rules when generating > code. If you break these rules, your code is incorrect and has > undefined behaviour, and whether it does or does not work as intended is > a matter of circumstance. And my point is the standard should be changed so use of unions in this way is allowed. It provides much cleaner code, and in the case where all pointers are equal, an exceedingly clear transform without the need for the actual transform in code, just the reference. > Thus your code is wrong, /even if it appears to work/. Being bad style > is not necessarily a serious "crime", but it is not something to > recommend to others. (Or since this is a self-correcting newsgroup, you > /can/ recommend it to someone else - and then listen when others say it > is bad style. We learn by answering questions as well as posing them.) It is not wrong on the architectures I compile for. This ability is provided for by the compiler as an extension to the C standard today because the underlying architectures allow for it by design. It is only "wrong" when going back against the C standard, and my argument is the C standard needs changed. > And while your code may work in the circumstances that you tested it, it > will fail in other cases. In particular, it will fail when heavy > optimisations in a good compiler lead the compiler to take advantage of > the strict aliasing rules. If that's the case, I'll either find another compiler which does not have a broken optimization mechanism in this regard, or #pragma that block to disable optimizations. It's much cleaner code using unions, and much easier to follow along with. I would rather have a marginally slower runtime environment and use that coding style, than to be forced to code around it. > > They don't work on all of them, and therein lies the issue I take > > with that reality existing in the C /standard/. I believe that C should > > account for those peculiar hardware forms, but they should be extensions, > > and not part of the standard, because the standard should relate more > > closely to physical hardware in its current semiconductor form, which is > > the form which has existed since at least the 1980s in 32-bit form, and > > back to the early 70s in 4-bit and larger forms. > > Again, this is all irrelevant. And I disagree, of course. > > We have a tool that is well distributed (semiconductor-based processors). > > We have a toolset designed to program those processors (languages like > > C). And there's no reason the two of them shouldn't have a more > > fundamental awareness of each other, or at least that the toolset should > > not have a more fundamental awareness of the tool itself. > > > > And for what it's worth, I honestly don't understand why people I would > > consider to be experts like Ben, do not understand this fundamental > > relationship of the toolset knowing the tool in a more directly connected > > way. > > You are hung up on the wrong points, that don't really matter here. Ben > has tried to make you see that. And I disagree, of course. And, since I'm working on my own compiler, it's not really an issue because I see very clearly that C will never change, not even to include the basic class syntax (something I view as a fundamental and catastrophic mistake for the language because the basic class adds that much to our source code abilities). It's just the way it is. RDC ALL THE WAY, BABY! Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-13 17:46 +0200 |
| Message-ID | <mqie0k$5g2$1@dont-email.me> |
| In reply to | #67300 |
On 13/08/15 16:57, Rick C. Hodgin wrote: > On Thursday, August 13, 2015 at 9:59:30 AM UTC-4, David Brown wrote: >> On 13/08/15 14:35, Rick C. Hodgin wrote: >>> On Thursday, August 13, 2015 at 7:47:32 AM UTC-4, David Brown wrote: >>>> On 13/08/15 04:59, Rick C. Hodgin wrote: >>>> >>>>> That's the way it is on x86 and ARM. And that's the way it should be >>>>> in the standard. That's my position. And that's my argument. >>>>> >>>> >>>> I think at least some of this argument is because you seem to think a >>>> /pointer/ is just an /address/. That is not the case in C. A /pointer/ >>>> certainly contains an address, but it also has a type - and the type is >>>> important. A pointer to an "int" is not the same thing as a pointer to >>>> a "struct foo". It does not matter whether the pointers have the same >>>> size, or the same implementation in the hardware - that's irrelevant. >>>> The two pointers have different types. >>>> >>>> This is important to the programmer, in order to be able to write >>>> clearer code and to get the best possible help from the tools in >>>> avoiding or spotting mistakes. If you mix up objects of different >>>> types, whether they are pointers or not, it's often a good indication of >>>> an error in the code. Writing casts explicitly can be a good way of >>>> making it clear that you know what you are doing in this slightly >>>> dangerous or difficult code. >>>> >>>> The type differences are also important to the compiler - as well as >>>> obvious uses (such as when type changes mean real code and value >>>> changes, for example when changing between an int and a double), 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. >>>> >>>> None of this has anything to do with how pointers happen to be >>>> implemented in different targets or compilers - it applies equally to >>>> x86 and ARM. >>> >>> The C language relates information through translation to the needs of >>> physical hardware, which conducts the work. As such, pointers are >>> addresses fundamentally. The type form is only important to the >>> compiler because it conveys information needed to access members when >>> they are used in processing. >> >> The type information is /critical/ - types are a vital part of C. This >> is why pointers are more than just a simple address. > > It's only critical in instructing the compiler how to generate code > which accesses data relative to the location it's pointing to. It's > not critical beyond that, and the underlying address of the pointer > will change, only the relative offsets to that address are what's > important, and that's where the type comes in ... at compile time. You are not accessing hardware - you are writing code in C. If something is important to the compiler, then it is important. It's as simple as that. C is not a target-independent assembler, as some people seem to think. It is a programming language, and like most programming languages it has a type system. The type system is important, though it is weak in C compared to many other languages. It exists for good reasons - work with it, not against it. And C provides an abstraction from many of the details of the hardware. It rarely matters how arithmetic is performed. You can write "x = y * 5;" in your code, and know what it will do, with a total disregard for how it is implemented on the target. On some targets, this will be handled with a shift and an add. Others will "misuse" odd addressing modes. Others with use a multiply instruction, while some will use a library function call. It does not matter to the C programmer. Similarly, it does not matter how pointers are implemented. What matters is what you write in the C language, and how that works - and types are important there. > > Once we're in runtime, any accesses through that type will have been > generated to use that location in memory, plus the offsets to access > the members. And as such, it shouldn't matter how the pointer address > was populated, which should allow it to be valid in a union. To the extent that this is true, it does not matter. But since types matter to the compiler, you don't have any assurance that the code is the same. For example, if the compiler can tell under the strict aliasing rules that a pointer operation cannot legally affect the outcome of an operation, then it can skip it - but if the pointer types are such that the code is properly defined, then it will do the operation. (If you don't understand what I mean by "strict aliasing", please say so.) > >> However, for the issues under discussion here, the fact that pointers to >> different types are the same size on most architectures is irrelevant. >> Please put it out of your mind for now - everything I wrote applies to >> x86 and ARM as much as to AVR's or "fringe" systems. > > A pointer is a pointer. And I would not use any system that had different > pointer sizes for data referenced as an int, or a struct, or as any other > form. I would consider that a bad design, a fatal flaw, and something to > be avoided. First, you are in no position to make such judgements. You are welcome to /dislike/ such architectures, but not do label them as "bad designs" with "fatal flaws". There are architectures with more complex pointers than you like - they are not made that way because of poor design, or to annoy people, but because the balance of requirements made that a good design decision. And secondly, /again/, it is irrelevant to the points here. > > The only cases where I would use a system which did have different pointer > sizes was it was part of a heterogeneous design, which employed different > cores internally which operated on different things. But, that is a > special beast, and I would expect to do some custom programming to > properly wield its peculiar data structure ... just as I would any other > machine that didn't use the same pointer sizes. > > I would not make it part of the standard. > >> You have to understand how types work in C, and what they mean. Just as >> a 32-bit "int" is a completely different thing than a 32-bit "float" >> despite being the same size, an int* pointer is a completely different >> thing than a float* pointer. > > They are only different to the compiler, and how the compiler would > then access the underlying data. As far as the hardware is concerned, > it doesn't matter in cache or memory if the data is from a float, an > int, a char, a pointer, or a structure containing all kinds of various > types arranged throughout. It's just data. Again, you are programming C, not hardware. > > The purpose of the union is to allow that address in memory to be > viewed differently, as by the peculiarities of each pointer type. Unions are orthogonal to pointers as features. The union lets you access data in the same storage as different types. That is not its main purpose - the main point of a union is to provide a storage unit where different types of data can be stored in the same physical space. In the earlier versions of the C specs, type punning by writing to one union member and then reading from another was specifically disallowed as undefined behaviour. > This could mean looking at an IEEE-754 floating point representation > as a series of bytes, or as an unsigned integer, or as part of a > structure which actually then shows invalid data because it was > never meant to be applied to it, but through an application of that > particular pointer, it is pulled through in that invalid way. > >> There are times when types are different, but near enough that you can >> usefully convert between them - and perhaps usefully do so without any >> code being generated at all. But logically, in C, it is still a conversion. > > If you are wanting to migrate from one form to another form then you use > the conversion. If you are simply wanting to look at the underlying data > differently, then you do not apply the conversion, but merely reference > it through the other pointer. No, you should use a conversion if you want to make an object of one type appear as another type. Conversions happen all the time in C, most of them being implicit conversions. If you want to examine the underlying bit representation, specifically avoiding a conversion, then a union is the way to go. > >> It is a good thing to understand the compilation process, and be aware >> of how things work underneath. But it is not a good thing to get >> obsessive about it, or to make the mistake of thinking that you >> understand exactly what the compiler will do - compilers have a great >> deal of flexibility in how they generate code. > > #1 I'm not obsessive about it. It just happens to be THE relationship > source code has with compiled code, and then compiled code has with the > hardware. > > #2 I don't particularly care what the compiler will do. When I use a > new pointer type to access data within, and I access the members of > that data, I will be reaching into something the compiler should've > known about by the fact that it was referenced in that way. This > knowing would've prevented it from making some kind of optimization > which then alters what I would see in the structure. > >> First, Ben dislikes your use of a union for type conversion because it >> is unclear, and does not express the programmer's intentions well. > > I disagree that it is unclear because the fact that the pointer is in > a union conveys an implicit cast, and in the case of the extra type > member, it makes it clear how it is setup by quick inspection. As I noted, this is somewhat a matter of opinion. > >> 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. >> >> Secondly, I pointed out the strict aliasing issues with your solution. >> These are, to the best of my knowledge, facts - the C standards have >> rules about aliasing, and compilers use these rules when generating >> code. If you break these rules, your code is incorrect and has >> undefined behaviour, and whether it does or does not work as intended is >> a matter of circumstance. > > And my point is the standard should be changed so use of unions in this > way is allowed. It provides much cleaner code, and in the case where > all pointers are equal, an exceedingly clear transform without the need > for the actual transform in code, just the reference. The issues with strict aliasing are not restricted to unions. I don't believe you understand what the phrase means. Even using Ben's suggestion of casts, it is easy to make mistakes with strict aliasing. > >> Thus your code is wrong, /even if it appears to work/. Being bad style >> is not necessarily a serious "crime", but it is not something to >> recommend to others. (Or since this is a self-correcting newsgroup, you >> /can/ recommend it to someone else - and then listen when others say it >> is bad style. We learn by answering questions as well as posing them.) > > It is not wrong on the architectures I compile for. This ability is > provided for by the compiler as an extension to the C standard today > because the underlying architectures allow for it by design. It is > only "wrong" when going back against the C standard, and my argument > is the C standard needs changed. Please learn about (or ask about) strict aliasing. This has nothing to do with the architectures you use or any other ideas about what the C standards /should/ say. Unless, of course, you want to say that the standard should not have such strict aliasing rules (and then I will explain why it does have them). > >> And while your code may work in the circumstances that you tested it, it >> will fail in other cases. In particular, it will fail when heavy >> optimisations in a good compiler lead the compiler to take advantage of >> the strict aliasing rules. > > If that's the case, I'll either find another compiler which does not > have a broken optimization mechanism in this regard, or #pragma that > block to disable optimizations. It is merely your understanding that is broken, not the compiler. But don't take it badly - a large number of people have trouble fully understanding aliasing. > > It's much cleaner code using unions, and much easier to follow along > with. I would rather have a marginally slower runtime environment and > use that coding style, than to be forced to code around it. Note that I have nothing against unions, and I fully agree they can lead to cleaner code in some cases - also smaller and faster code, and, most importantly, /correct/ code. But in general, what you want is a pointer to a union - /not/ a union of pointers. > >>> They don't work on all of them, and therein lies the issue I take >>> with that reality existing in the C /standard/. I believe that C should >>> account for those peculiar hardware forms, but they should be extensions, >>> and not part of the standard, because the standard should relate more >>> closely to physical hardware in its current semiconductor form, which is >>> the form which has existed since at least the 1980s in 32-bit form, and >>> back to the early 70s in 4-bit and larger forms. >> >> Again, this is all irrelevant. > > And I disagree, of course. > >>> We have a tool that is well distributed (semiconductor-based processors). >>> We have a toolset designed to program those processors (languages like >>> C). And there's no reason the two of them shouldn't have a more >>> fundamental awareness of each other, or at least that the toolset should >>> not have a more fundamental awareness of the tool itself. >>> >>> And for what it's worth, I honestly don't understand why people I would >>> consider to be experts like Ben, do not understand this fundamental >>> relationship of the toolset knowing the tool in a more directly connected >>> way. >> >> You are hung up on the wrong points, that don't really matter here. Ben >> has tried to make you see that. > > And I disagree, of course. > > And, since I'm working on my own compiler, it's not really an issue > because I see very clearly that C will never change, not even to include > the basic class syntax (something I view as a fundamental and catastrophic > mistake for the language because the basic class adds that much to our > source code abilities). If you don't understand the aliasing issues in C, you are bound to get them wrong in your own language. Learn C properly first, before trying to improve on it. > > It's just the way it is. RDC ALL THE WAY, BABY! > > Best regards, > Rick C. Hodgin >
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-13 09:15 -0700 |
| Message-ID | <8500ce05-e55e-447d-8ec8-d7b973e5e269@googlegroups.com> |
| In reply to | #67302 |
On Thursday, August 13, 2015 at 11:46:12 AM UTC-4, David Brown wrote: > You are not accessing hardware - you are writing code in C. This sums up the disagreement I have with both the C standard, and with the position you and Ben (and many others) hold. You look to the standard as some abstract thing away from hardware. I look at it as a translator which conveys my English-in-C-syntax into the binary language the machine needs to conduct the workload I've instructed. I recognize the machine at the far end of my communication through C. Bottom line: Were the sun to start emitting a form of radiation which made all CPUs on Earth unable to work, I would never write another line of C code. It's not an efficient mechanism to convey complex ideas. It's just a procedural one. With people, I can use language, music, song, poetry, and pictures, much more easily. I might write C code as some form of nostalgia recounting about what I did before we all became laborers again, or in an academic teaching venue about what it was like before the sun changed... but apart from that ... it would be farming for me. Raise a few animals, plant a few crops. I'd settle somewhere near the Amish. ----- We write C code because there ARE machines on the other side of that code. It's as simple as that. I place both recognition and value on that reality. I don't look only to one side of the equation and say, well the other side ... it's of no concern to me. Balanced equations are important, my friend! 10 PRINT "RDC... TO THE FUTURE!" 20 GOTO 10 Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-08-13 17:21 +0100 |
| Message-ID | <mqig3k$dle$1@dont-email.me> |
| In reply to | #67306 |
On 13/08/15 17:15, Rick C. Hodgin wrote: > On Thursday, August 13, 2015 at 11:46:12 AM UTC-4, David Brown wrote: >> You are not accessing hardware - you are writing code in C. > > This sums up the disagreement I have with both the C standard, and > with the position you and Ben (and many others) hold. You look to > the standard as some abstract thing away from hardware. I look at > it as a translator which conveys my English-in-C-syntax into the > binary language the machine needs to conduct the workload I've > instructed. I recognize the machine at the far end of my > communication through C. That's a perfectly valid attitude. And, as long as you never have to move your code to another platform, it is one that will serve you well. Those of us who can't always know in advance which platform(s) our code will be running on are less free to take that stance. Instead, we (try to) rely only on the guarantees that the Standard gives us. And /that's/ a perfectly valid attitude too. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-13 09:26 -0700 |
| Message-ID | <2e37a05e-8cd6-4cd2-85a0-8e1141776e75@googlegroups.com> |
| In reply to | #67307 |
On Thursday, August 13, 2015 at 12:21:54 PM UTC-4, Richard Heathfield wrote: > On 13/08/15 17:15, Rick C. Hodgin wrote: > > On Thursday, August 13, 2015 at 11:46:12 AM UTC-4, David Brown wrote: > >> You are not accessing hardware - you are writing code in C. > > > > This sums up the disagreement I have with both the C standard, and > > with the position you and Ben (and many others) hold. You look to > > the standard as some abstract thing away from hardware. I look at > > it as a translator which conveys my English-in-C-syntax into the > > binary language the machine needs to conduct the workload I've > > instructed. I recognize the machine at the far end of my > > communication through C. > > That's a perfectly valid attitude. And, as long as you never have to > move your code to another platform, it is one that will serve you well. > Those of us who can't always know in advance which platform(s) our code > will be running on are less free to take that stance. Instead, we (try > to) rely only on the guarantees that the Standard gives us. And /that's/ > a perfectly valid attitude too. Hi, Richard! Well there's nothing to prevent a C compiler from recognizing the use of unions for pointers on a machine that doesn't have the same size pointers for different types, and automatically injecting the fixup code for you either. It could inject an implicit cast on each use to compensate for the machine's shortcomings. The fact that the C standard forces it the other way today is that which I take issue with. But there's no reason why it couldn't be switched, apart from legacy code, in which case you use the --legacy-enabled compile switch and voila! (of course, you could also use the --legacy-disabled switch under the same type of consideration I advocate above.) Oh well. 10 PRINT "RDC... ENGAGE!" 20 GOTO 10 Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-13 19:40 +0100 |
| Message-ID | <87y4hf2fsa.fsf@bsb.me.uk> |
| In reply to | #67308 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: <snip> > Well there's nothing to prevent a C compiler from recognizing the use > of unions for pointers on a machine that doesn't have the same size > pointers for different types, and automatically injecting the fixup > code for you either. Yes there is -- the definition of language prevents that. You could have a C-like language whose unions did not behave like C unions, but it would not be C. C's unions have a long and satisfactory history of being used to re-interpret object representations, and it would be very much more than tweak to the language to break that. (And it's not just about size. You do get that don't you?) <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-13 11:43 -0700 |
| Message-ID | <93f98bd1-4022-4c28-9830-83e4cd7b6fb4@googlegroups.com> |
| In reply to | #67320 |
On Thursday, August 13, 2015 at 2:40:29 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> <snip>
> > Well there's nothing to prevent a C compiler from recognizing the use
> > of unions for pointers on a machine that doesn't have the same size
> > pointers for different types, and automatically injecting the fixup
> > code for you either.
>
> Yes there is -- the definition of language prevents that.
Did you read the start of the next sentence there?
"The fact that the C standard forces it the other way today is
that which I take issue with..."
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-13 21:30 +0100 |
| Message-ID | <87y4hf0w41.fsf@bsb.me.uk> |
| In reply to | #67323 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Thursday, August 13, 2015 at 2:40:29 PM UTC-4, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> <snip> >> > Well there's nothing to prevent a C compiler from recognizing the use >> > of unions for pointers on a machine that doesn't have the same size >> > pointers for different types, and automatically injecting the fixup >> > code for you either. >> >> Yes there is -- the definition of [the] language prevents that. (typo edited) > Did you read the start of the next sentence there? > > "The fact that the C standard forces it the other way today is > that which I take issue with..." Of course, but I don't really know what you'd have preferred. Help me out. How should I have correct the apparently erroneous impression given by your first paragraph above? Should I just have left it, hoping that readers will see (because of what follows) that you must mean that a C-like compiler can do what you claim? But then I'd still want to point out the problems with such a C-like compiler. What is the best reply I could have made to clear this detail up? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-13 14:56 -0700 |
| Message-ID | <87fa52c5-31c0-4341-bc69-f054ca063c60@googlegroups.com> |
| In reply to | #67334 |
On Thursday, August 13, 2015 at 4:30:49 PM UTC-4, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > > On Thursday, August 13, 2015 at 2:40:29 PM UTC-4, Ben Bacarisse wrote: > >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > >> <snip> > >> > Well there's nothing to prevent a C compiler from recognizing the use > >> > of unions for pointers on a machine that doesn't have the same size > >> > pointers for different types, and automatically injecting the fixup > >> > code for you either. > >> > >> Yes there is -- the definition of [the] language prevents that. > (typo edited) > > > Did you read the start of the next sentence there? > > > > "The fact that the C standard forces it the other way today is > > that which I take issue with..." > > Of course, but I don't really know what you'd have preferred. Help me > out. How should I have correct the apparently erroneous impression > given by your first paragraph above? My first paragraph was conveying the idea that there is nothing inherent in hardware, or the universe, which would prevent it from operating in the manner I suggest (unions for pointers working correctly). My second paragraph conveyed the source of the constraint as it exists today, which is only the C standard itself. > Should I just have left it, hoping > that readers will see (because of what follows) that you must mean that > a C-like compiler can do what you claim? But then I'd still want to > point out the problems with such a C-like compiler. There is no problem with such a C-like compiler. > What is the best > reply I could have made to clear this detail up? I can't help you out there, Ben. I feel a kinship to you on some of your posts, and on others I sit back scratching my head wondering to myself, "Huh?" :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-14 08:51 +0200 |
| Message-ID | <mqk31u$ss5$1@dont-email.me> |
| In reply to | #67307 |
On 13/08/15 18:21, Richard Heathfield wrote: > On 13/08/15 17:15, Rick C. Hodgin wrote: >> On Thursday, August 13, 2015 at 11:46:12 AM UTC-4, David Brown wrote: >>> You are not accessing hardware - you are writing code in C. >> >> This sums up the disagreement I have with both the C standard, and >> with the position you and Ben (and many others) hold. You look to >> the standard as some abstract thing away from hardware. I look at >> it as a translator which conveys my English-in-C-syntax into the >> binary language the machine needs to conduct the workload I've >> instructed. I recognize the machine at the far end of my >> communication through C. > > That's a perfectly valid attitude. And, as long as you never have to > move your code to another platform, it is one that will serve you well. > Those of us who can't always know in advance which platform(s) our code > will be running on are less free to take that stance. Instead, we (try > to) rely only on the guarantees that the Standard gives us. And /that's/ > a perfectly valid attitude too. > As usual, there is a happy medium to be found (or at least, we can search for it!). I think one can never really be a happy and productive programmer if you are fanatically at one end or the other of this line - people who are tied to the idea of a compiler being a direct C-to-assembly translator will always be upset when the compiler generates code that doesn't match their expectations, and people who want to be absolute about coding strictly to the standards will find occasional pieces of code to be particularly unpleasant or inefficient, or even impossible, and will get frustrated with compilers which don't stick to the standards properly. Personally, I prefer to understand how the compiler "thinks" in terms of the standards, /and/ consider how it generates the resulting code. It is not enough for me that a particular run of the compiler generates code that happens to work - I want to be sure that the compiler generates working object code because the source code is /correct/. And I also - for at least some of my code - need to know the object code that is being produced, because my code may rely on the speed or size of the code as well as the functionality. So (to the greatest extent I am able) I write code that matches the standards regarding defined and undefined behaviour, but it is not unusual for me to rely on implementation-defined behaviour in order to get the best code (in terms of neatest and clearest source code, and/or most efficient object code). And the reason I work to C standards is not because they are some sort of holy book, but because they form the contract between the compiler and the programmer - basically, they are part of the user manual for the toolchain.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-14 00:03 -0700 |
| Message-ID | <f2f7ade1-b370-4ca5-9749-860f4890306b@googlegroups.com> |
| In reply to | #67355 |
On Friday, August 14, 2015 at 2:51:23 AM UTC-4, David Brown wrote: > And the reason I work to C standards is not because they are some sort > of holy book... David, has anyone ever shared the gospel message with you? Taught you who Jesus Christ is? And why He is important? Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
Page 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web