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 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-12 05:01 -0700 |
| Message-ID | <e2fb24f5-4eaa-4089-96a7-55c89d8fe2a6@googlegroups.com> |
| In reply to | #67180 |
On Wednesday, August 12, 2015 at 7:52:48 AM UTC-4, Rick C. Hodgin wrote:
> On Tuesday, August 11, 2015 at 8:35:25 PM UTC-4, Rick C. Hodgin wrote:
> > There's a place for the language of C,
> > where if ever you find you to be,
> > take ye heed of the locals,
> > for their "compilers" are vocal,
> > in matters of triviality.
>
> Version 2.0:
>
> Title: "The Jagged comp.lang.c Shoreline"
>
> There's a place for the language of C,
> I advise there you listen to me,
> take wise heed of thy locals,
> their "compilers" are vocal,
> and do clamor on excessively.
Version 2.1:
Title: "The Jagged comp.lang.c Shoreline"
There's a place for the language of C,
I advise there you listen to me,
take wise heed of thy locals,
their "compilers" are vocal,
and oft clamor on excessively.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-12 05:10 -0700 |
| Message-ID | <fbe691d9-28fc-477c-a0e1-9dc0e352c69c@googlegroups.com> |
| In reply to | #67182 |
On Wednesday, August 12, 2015 at 8:02:07 AM UTC-4, Rick C. Hodgin wrote:
> On Wednesday, August 12, 2015 at 7:52:48 AM UTC-4, Rick C. Hodgin wrote:
> > On Tuesday, August 11, 2015 at 8:35:25 PM UTC-4, Rick C. Hodgin wrote:
> > > There's a place for the language of C,
> > > where if ever you find you to be,
> > > take ye heed of the locals,
> > > for their "compilers" are vocal,
> > > in matters of triviality.
> >
> > Version 2.0:
> >
> > Title: "The Jagged comp.lang.c Shoreline"
> >
> > There's a place for the language of C,
> > I advise there you listen to me,
> > take wise heed of thy locals,
> > their "compilers" are vocal,
> > and do clamor on excessively.
>
> Version 2.1:
>
> Title: "The Jagged comp.lang.c Shoreline"
>
> There's a place for the language of C,
> I advise there you listen to me,
> take wise heed of thy locals,
> their "compilers" are vocal,
> and oft clamor on excessively.
Version 2.2:
Title: "The Jagged comp.lang.c Shoreline"
There's a place for the language of C,
I advise there you listen to me,
take wise heed of thy locals,
their "compilers" are vocal,
and -pedantic's their friend you will see.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-12 09:17 +0200 |
| Message-ID | <mqerrj$m4v$1@dont-email.me> |
| In reply to | #67145 |
On 12/08/15 02:11, Richard Heathfield wrote: > On 12/08/15 00:46, glen herrmannsfeldt wrote: >> Keith Thompson <kst-u@mib.org> wrote: >> >> (snip on quoting rules for usenet) >> >>> I sometimes reformat quoted text (not code), particularly if >>> the original text has very long lines, changing *only* spacing >>> and line breaks. I've done so with the quoted paragraph above. >>> I usually don't bother to mention it. >> >> My news host requires posts to mostly fit in 80 columns. >> (Usually it will allow a small number of long lines, >> especially URLs.) So I often have to reformat line breaks. >> >>> I don't do this for code samples. >> >> I sometimes remove blank lines from code samples, and maybe reformat >> if lines are longer than 80 columns. >> >> I might only quote part of a code sample, that is, remove lines >> before and after the part of interest, especially if it is long. >> >> I didn't know that there was an actual rule before, though. > > I don't think it's an "actual rule". It's really only common sense. A > quotation is a playing-back of something someone said (or, to be more > precise, wrote). If you change the text (other than in trivial ways, > such as whitespace), it is no longer a quotation. > Yes, that's the point. Although there are a few /real/ rules for Usenet, most are "unwritten rules". As noted by others, trivial formatting, spacing or line breaking changes are not an issue (except in comp.lang.python...). But changing the content of a quotation can be confusing, and if it is someone else's text (not the case here) it may be rude.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-12 02:56 +0100 |
| Message-ID | <87oaid9sm8.fsf@bsb.me.uk> |
| In reply to | #67133 |
"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.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-12 04:07 +0200 |
| Message-ID | <mqe9pg$h63$1@speranza.aioe.org> |
| In reply to | #67154 |
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.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-12 03:45 +0100 |
| Message-ID | <877fp19qd5.fsf@bsb.me.uk> |
| In reply to | #67155 |
"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.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-12 12:10 +0200 |
| Message-ID | <mqf61n$gop$2@speranza.aioe.org> |
| In reply to | #67158 |
On 12.08.2015 04:45, Ben Bacarisse wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
[...]
>> 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.
OK.. I kind of get it, but can you elaborate a bit?
-Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-12 11:39 +0100 |
| Message-ID | <87pp2s94fh.fsf@bsb.me.uk> |
| In reply to | #67168 |
"Morten W. Petersen" <morphex@gmail.com> writes:
> On 12.08.2015 04:45, Ben Bacarisse wrote:
>> "Morten W. Petersen" <morphex@gmail.com> writes:
> [...]
>>> 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.
>
> OK.. I kind of get it, but can you elaborate a bit?
I'm sure you are not surprised by this:
union arith { long long i; double d; };
union arith u = { .d = 42 };
printf("%lld\n", u.i); // output on this machine 4631107791820423168
That's because, whilst the initialisation correctly converts an int (42)
to a double for storage in u.d, the access of u.i simply reinterprets
the bits, and the bit pattern for (long long){42} is very different to
that for (double){42.0}.
So it is for pointers in a union, but we have got used to the idea that
all pointer types have the same representation -- that a void * and a
char * and struct S * pointing at the same object all use exactly the
same pattern of bits. This is has not been true historically, and the C
standard does not require that it be true. C does guarantee *some*
things about pointer representations, but the details are not important
here.
The key thing is to try, wherever possible, to use the right pointer
type and to use a cast to convert one pointer type to another where
this is not possible.
Unions have two functions. One, to save space by enabling the storage
of more than one kind of object in the same location at different times.
In this usage you always access the union member that was last stored.
Sometimes you do this by having a run-time "type" member somewhere --
this is a so-called discriminated union -- and sometimes the logic of
the program can ensure that the right member is always being accessed
without needing to store any record of it.
The second use is to re-interpret the representation of one type as if
it were another. This is a much and specialised usage.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-12 13:41 +0200 |
| Message-ID | <mqfbdg$ur6$1@speranza.aioe.org> |
| In reply to | #67170 |
On 12.08.2015 12:39, Ben Bacarisse wrote: [...] > So it is for pointers in a union, but we have got used to the idea that > all pointer types have the same representation -- that a void * and a > char * and struct S * pointing at the same object all use exactly the > same pattern of bits. This is has not been true historically, and the C > standard does not require that it be true. C does guarantee *some* > things about pointer representations, but the details are not important > here. Out of curiosity, what were some of the cases where pointers differed in size, why were some smaller etc.? > The key thing is to try, wherever possible, to use the right pointer > type and to use a cast to convert one pointer type to another where > this is not possible. Yes, having some strictness seems like the way to go. -Morten
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-12 04:59 -0700 |
| Message-ID | <ccc561dd-6029-471f-ad7e-9758bd1df180@googlegroups.com> |
| In reply to | #67179 |
On Wednesday, August 12, 2015 at 7:41:53 AM UTC-4, Morten W. Petersen wrote: > On 12.08.2015 12:39, Ben Bacarisse wrote: > [...] > > So it is for pointers in a union, but we have got used to the idea that > > all pointer types have the same representation -- that a void * and a > > char * and struct S * pointing at the same object all use exactly the > > same pattern of bits. This is has not been true historically, and the C > > standard does not require that it be true. C does guarantee *some* > > things about pointer representations, but the details are not important > > here. > > Out of curiosity, what were some of the cases where pointers differed > in size, why were some smaller etc.? > > > The key thing is to try, wherever possible, to use the right pointer > > type and to use a cast to convert one pointer type to another where > > this is not possible. > > Yes, having some strictness seems like the way to go. > > -Morten In my humble opinion... I would not worry about this issue. First of all it will only affect the most obtuse or special-equipment compilers. Second, you can use some compile-time checks to ensure things you do rely upon are the same size, such as comparing sizeof(void*) to sizeof(other*), etc., and if they are different reporting it during compilation with #if blocks. Every modern standard machine people use and write applications for, all of them should have all pointers being the same size. And even if they don't, it's still not worth all of the extra code added to cast everything when the code you have was specifically designed for the purposes of using the various and disparate values the union exposes. That's what unions are for -- to share a data space based on runtime context of reuse. If you must cast, cast to one of your union types at one place only, and then always use the union type thereafter. And I do pray that's what the advice givers meant by using casting, though I am suspect of that hopeful conclusion. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-12 14:16 +0100 |
| Message-ID | <87egj88x5n.fsf@bsb.me.uk> |
| In reply to | #67181 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Wednesday, August 12, 2015 at 7:41:53 AM UTC-4, Morten W. Petersen wrote: >> On 12.08.2015 12:39, Ben Bacarisse wrote: >> [...] >> > So it is for pointers in a union, but we have got used to the idea that >> > all pointer types have the same representation -- that a void * and a >> > char * and struct S * pointing at the same object all use exactly the >> > same pattern of bits. This is has not been true historically, and the C >> > standard does not require that it be true. C does guarantee *some* >> > things about pointer representations, but the details are not important >> > here. >> >> Out of curiosity, what were some of the cases where pointers differed >> in size, why were some smaller etc.? >> >> > The key thing is to try, wherever possible, to use the right pointer >> > type and to use a cast to convert one pointer type to another where >> > this is not possible. >> >> Yes, having some strictness seems like the way to go. >> >> -Morten > > In my humble opinion... > > I would not worry about this issue. In my opinion you should worry about it. Not because you'll write code that breaks on machine X (though who knows what your code will be running on the 40 years time) but because the cast tells the reader what you mean and the union does not. It's about being clear by writing what you mean. > First of all it will only affect > the most obtuse or special-equipment compilers. Second, you can use > some compile-time checks to ensure things you do rely upon are the > same size, such as comparing sizeof(void*) to sizeof(other*), etc., > and if they are different reporting it during compilation with #if > blocks. It's not just about size. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-12 06:37 -0700 |
| Message-ID | <6cd37536-cf9d-422a-aa05-b801ced9fb42@googlegroups.com> |
| In reply to | #67194 |
On Wednesday, August 12, 2015 at 9:16:30 AM UTC-4, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > In my humble opinion... > > I would not worry about this issue. > > In my opinion you should worry about it. Not because you'll write code > that breaks on machine X (though who knows what your code will be > running on the 40 years time) but because the cast tells the reader what > you mean and the union does not. It's about being clear by writing what > you mean. The cast provides explicit information line-by-line, but the union also tells you this information by the type of that union member, and without the mechanical requirement of typing out casts line-by-line. In addition, upon seeing that the pointer in use is part of a union (something a self- respecting editor should provide in some way when hovering over the variable), then it will be clear to the adequately versed C developer that the reason a union is being used is because it's a shared data type. > > First of all it will only affect > > the most obtuse or special-equipment compilers. Second, you can use > > some compile-time checks to ensure things you do rely upon are the > > same size, such as comparing sizeof(void*) to sizeof(other*), etc., > > and if they are different reporting it during compilation with #if > > blocks. > > It's not just about size. Then it would be possible to also use a runtime test which, if it fails, reports that condition and exits out explaining in comments how it can be fixed. ----- I've only used a few C compilers in my life, and they've all been on x86, ARM, 68K, and a few mainframe systems in school whose processors I don't even know what they were. I cannot recall any occasion where pointer sizes were different (except back in the DOS days with near and far pointers). I realize this doesn't mean it can't happen, and won't someday happen, but my point is that I think it's exceedingly rare where it would be an issue. And as I see it, the person using some architecture where something doesn't work (with shared union pointers apart from assignment as by explicit casts), that person would know this, and has probably designed their compilers to issue warnings about such shared pointer use, or that values are assigned to union members without explicit casts. I just don't believe the burden should be on every C developer to write code for every possible architecture all the time, especially when they're targeting a handful of architectures where it's not at issue. I think it should be a burden upon the shoulders of those developers who choose to operate on those architectures where such limits exist, and it should be their job to fixup any code they receive from me should they choose to use that resource for their benefit. After all, THEY are the experts on that architecture, and the ones who should know all about its quirks. This is my position this matter, and it's also one I believe over time would draw future hardware makers in toward standards. And in the case where such a hardware exception warrants the atypical behavior, as by providing some grand increase in performance or throughput, then it's just the cost of doing developer business on that particular and unique machine. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-12 15:34 +0100 |
| Message-ID | <8737zo8tjt.fsf@bsb.me.uk> |
| In reply to | #67195 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Wednesday, August 12, 2015 at 9:16:30 AM UTC-4, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> > In my humble opinion... >> > I would not worry about this issue. >> >> In my opinion you should worry about it. Not because you'll write code >> that breaks on machine X (though who knows what your code will be >> running on the 40 years time) but because the cast tells the reader what >> you mean and the union does not. It's about being clear by writing what >> you mean. > > The cast provides explicit information line-by-line, but the union also > tells you this information by the type of that union member, and without > the mechanical requirement of typing out casts line-by-line. In addition, > upon seeing that the pointer in use is part of a union (something a self- > respecting editor should provide in some way when hovering over the > variable), then it will be clear to the adequately versed C developer > that the reason a union is being used is because it's a shared data > type. I would hope a C programmer would come to a very different conclusion. What's more, I am sure you would agree that they would (and should) come to a different conclusion if we were not talking about pointers. Anyway, I don't expect to change your mind, but I hope any learners who might come across this thread will see the danger in writing code that does not say what the programmer means, even if if it almost always works. >> > First of all it will only affect the most obtuse or >> > special-equipment compilers. Second, you can use some compile-time >> > checks to ensure things you do rely upon are the same size, such as >> > comparing sizeof(void*) to sizeof(other*), etc., and if they are >> > different reporting it during compilation with #if blocks. >> >> It's not just about size. > > Then it would be possible to also use a runtime test which, if it fails, > reports that condition and exits out explaining in comments how it can > be fixed. Two points: First, can you really do that (and I mean "you" not "one")? Can you really write a compile-time test that checks the actual assumptions that your suggested use of unions relies on, or are you just speculating that it must, surely, be possible? Second, it's usually possible to test for unwarranted assumption being made by come bit of code, but it's much better simply not to make those unwarranted assumptions in the first place. <snip> > I just don't believe the burden should be on every C developer to write > code for every possible architecture all the time, especially when they're > targeting a handful of architectures where it's not at issue. But here we are simply talking about doing it right. There is no burden in writing the code the correct and portable way. There is no possible justification (that I can see) for doing it the wrong way. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-12 08:17 -0700 |
| Message-ID | <95573ef8-9cfc-427b-9ca3-e8cf87484b75@googlegroups.com> |
| In reply to | #67200 |
On Wednesday, August 12, 2015 at 10:34:26 AM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>
> > On Wednesday, August 12, 2015 at 9:16:30 AM UTC-4, Ben Bacarisse wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> > In my humble opinion...
> >> > I would not worry about this issue.
> >>
> >> In my opinion you should worry about it. Not because you'll write code
> >> that breaks on machine X (though who knows what your code will be
> >> running on the 40 years time) but because the cast tells the reader what
> >> you mean and the union does not. It's about being clear by writing what
> >> you mean.
> >
> > The cast provides explicit information line-by-line, but the union also
> > tells you this information by the type of that union member, and without
> > the mechanical requirement of typing out casts line-by-line. In addition,
> > upon seeing that the pointer in use is part of a union (something a self-
> > respecting editor should provide in some way when hovering over the
> > variable), then it will be clear to the adequately versed C developer
> > that the reason a union is being used is because it's a shared data
> > type.
>
> I would hope a C programmer would come to a very different conclusion.
Still don't see it, Ben. I have a feature in my editor called "Code
Definition Window" which, as I navigate through my code, is constantly
loading up the location where the variable I'm on was defined. I can
see, for example, when I'm on a structure or some member, where it was
defined, what's around it. It pops up automatically, so I have that
information without having to have it flaunted in my face in source
code form. It's one of the many benefits of using a GUI-based editor,
which I realize many remote developers and those working on embedded
systems can't use. I can. And even in the cases where I've had to
do some programming on something, I've been able to write some tests
in that editor, then transfer it over, and do the last bit of final
debugging on the target, rather than doing it all in that limited
toolset.
> What's more, I am sure you would agree that they would (and should) come
> to a different conclusion if we were not talking about pointers.
I would agree...
In all cases where they're not pointers, UNLESS it's from something
that's known to be the same size. Pointers in 32-bit code on Windows
and ARM- and x86-based Linux are 32-bits. So, you can use this
example safely because the compiler constraints are enforced by the
architecture itself:
union {
uint32_t _ptr;
void* ptr;
};
I also extend this more generally to 32-bit and 64-bit compilations
using an #if test at the start, and defining custom names based on
the bit size:
// Simplified for illustration, actual test is more complex
#if 32-bits
#define uptr uint32_t
#elif 64-bits
#define uptr uint64_t
#else
#error
#endif
union {
uptr _ptr;
void* ptr;
};
My targets are primarily x86 32-bit and 64-bit, and ARM 32-bit and
64-bit, and I'm content with that because it's a huge percentage of
the market share. And if I ever need to change anything, I can
rename my union members and find out in every instance where they're
used in code by attempting to compile.
> Anyway, I don't expect to change your mind, but I hope any learners who
> might come across this thread will see the danger in writing code that
> does not say what the programmer means, even if if it almost always
> works.
In the case of pointers, using unions does say what the programmer means.
It just does it in a way which doesn't slap you on the face on every line
of source code which references it. And to me, that's a good thing. In
fact, it's a requirement.
> >> > First of all it will only affect the most obtuse or
> >> > special-equipment compilers. Second, you can use some compile-time
> >> > checks to ensure things you do rely upon are the same size, such as
> >> > comparing sizeof(void*) to sizeof(other*), etc., and if they are
> >> > different reporting it during compilation with #if blocks.
> >>
> >> It's not just about size.
> >
> > Then it would be possible to also use a runtime test which, if it fails,
> > reports that condition and exits out explaining in comments how it can
> > be fixed.
>
> Two points: First, can you really do that (and I mean "you" not "one")?
Sure.
> Can you really write a compile-time test that checks the actual
> assumptions that your suggested use of unions relies on, or are you just
> speculating that it must, surely, be possible?
Sure. If there's a test case, such as your example, where the address
of A won't equal B, when A and B should be equal, then it can be tested.
You can use pointer math if your compiler supports it, and if not, then
use a union which encompasses a pointer and a sufficiently large integer,
and simply do a compare. They have to be exactly equal to pass the test.
If they don't, report the failure observed at runtime.
> Second, it's usually possible to test for unwarranted assumption being
> made by come bit of code, but it's much better simply not to make those
> unwarranted assumptions in the first place.
It might be for the well-versed C developer, the one who has spent time
learning and thinking about those things regularly, and has come to form
a pattern of though which exhibits those traits naturally from within
its creation mechanisms.
However, for anyone who doesn't know that information, the mountainous
workload it places upon someone, someone who could otherwise do the task
quickly, yet is now of bogged down to such an extent that it's actually
off-putting, making what should've been a 5 minute fix into a 90 minute
exercise in R&D for something that, in 100% of all cases I know about on
the code I've written, has never been an issue (and I'm sure other people
have similar experiences unless they are something like contract-for-hire
C developers who work on whatever platform the customer wants, and
therefore must be in the pattern of writing code like that because it's
important to their clients).
To put it simply: it's just too much work for most code because most
targets don't need it.
> <snip>
> > I just don't believe the burden should be on every C developer to write
> > code for every possible architecture all the time, especially when they're
> > targeting a handful of architectures where it's not at issue.
>
> But here we are simply talking about doing it right. There is no
> burden in writing the code the correct and portable way. There is no
> possible justification (that I can see) for doing it the wrong way.
This is always our same argument. You place EXTREME value on things I
do not place ANY value upon, except in cases where such value is
warranted, such as were I to decide to write some code which **I INTENDED**
to be released on ever architecture. But, I simply don't do that.
I'm perfectly content to support only those architectures which have the
same sized pointers, and where pointer references in a union will all
point to the same location regardless of whether they were cast or not.
In fact, I would completely avoid an architecture that did not support
those features because knowing what I know about assembly language, and
machine data access at the hardware level, it's ridiculous to not have
the same size pointers for general processing, and I wouldn't trust such
a design decision made by someone for that architecture. I would be
leery of it from the get-go, and would pass for something more standard,
more familiar. I would do this every time, and without hesitation or
reservation. In fact, I would do this making decisions which required
a larger battery, or a different motherboard be created, rather than
cater to some obtuse architecture's design quirks for the gain of some
small amount of something.
You're talking about doing it "right" in the context of supporting all
of those obtuse architectures, those which the code will likely never
be compiled on, under the thinking that a some point, somewhere, in
some distant corner of the globe, some user might haphazardly try to
compile some of that code and (oh my gosh!! much to their horror!!) it
doesn't work on the first try and they have to go in to the source code
and make a few changes to make it work on their known-to-be-obtuse
architecture.
I find that conclusion shocking, and wrong. I think it is so amazingly
wrong that I would never, under any circumstances, purport it, save one
and only one instance: if you had some desire to write code which was
kept to the C standard because you wanted to be able to globally support
all architectures. Which brings up the question, by the way, is there
ANY code ANYWHERE that does that? Is there truly a form of source code
you can write which will ALWAYS compile on ANY architecture without
requiring ANY changes whatsoever?
You place enough value on that "possible contingency" that it may be
used by someone else that you would require all code be written so as
to address it.
No, sir. No how. No way. Not ever. Not on my watch. I have too
many things to do with my time than worry about supporting obtuse
architectures. When it comes to me encountering that need in this
world, I will gladly send the work your way and say, "Ben can do it!
He's fantastic about supporting this architecture." And then I'll
go back to doing something else.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-12 08:38 -0700 |
| Message-ID | <4a3136b6-594d-4af8-8467-f1b05020601d@googlegroups.com> |
| In reply to | #67204 |
On Wednesday, August 12, 2015 at 11:17:55 AM UTC-4, Rick C. Hodgin wrote:
> On Wednesday, August 12, 2015 at 10:34:26 AM UTC-4, Ben Bacarisse wrote:
> > What's more, I am sure you would agree that they would (and should) come
> > to a different conclusion if we were not talking about pointers.
>
> I would agree...
>
> In all cases where they're not pointers, UNLESS it's from something
> that's known to be the same size.
And before the snipers get me again, I'll add the (to me obvious, so
obvious that I didn't include it in the first post) comment regarding
type switching, such as casting float to int. Those obviously require
casting, unless you're simply looking at the underlying data, in which
case you can do something like this on an architecture where float and
int are both known to be 32-bits:
struct SWhatever
{
union {
float f;
int i;
};
};
SWhatever a, b;
a.f = 1.0f;
b.i = a.i;
printf("%f\n", b.f);
I don't recommend doing this generally, but I can see where you may
want to do it at some point. I had occasion recently when writing
my generical "call DLL" function. I was only concerned about putting
data on the stack, and I didn't care what kind it was because it was
all just data that I had to move from A to B. So, everything that
was 32-bit was converted to an unsigned 32-bit integer, and 64-bit to
an unsigned 64-bit integer, and it was loaded that way.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-12 17:19 +0100 |
| Message-ID | <87fv3o7a3i.fsf@bsb.me.uk> |
| In reply to | #67204 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Wednesday, August 12, 2015 at 10:34:26 AM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>
>> > On Wednesday, August 12, 2015 at 9:16:30 AM UTC-4, Ben Bacarisse wrote:
>> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> >> > In my humble opinion...
>> >> > I would not worry about this issue.
>> >>
>> >> In my opinion you should worry about it. Not because you'll write code
>> >> that breaks on machine X (though who knows what your code will be
>> >> running on the 40 years time) but because the cast tells the reader what
>> >> you mean and the union does not. It's about being clear by writing what
>> >> you mean.
>> >
>> > The cast provides explicit information line-by-line, but the union also
>> > tells you this information by the type of that union member, and without
>> > the mechanical requirement of typing out casts line-by-line. In addition,
>> > upon seeing that the pointer in use is part of a union (something a self-
>> > respecting editor should provide in some way when hovering over the
>> > variable), then it will be clear to the adequately versed C developer
>> > that the reason a union is being used is because it's a shared data
>> > type.
>>
>> I would hope a C programmer would come to a very different conclusion.
>
> Still don't see it, Ben. I have a feature in my editor called "Code
> Definition Window" which, as I navigate through my code, is constantly
> loading up the location where the variable I'm on was defined. I can
> see, for example, when I'm on a structure or some member, where it was
> defined, what's around it. It pops up automatically, so I have that
> information without having to have it flaunted in my face in source
> code form. It's one of the many benefits of using a GUI-based editor,
> which I realize many remote developers and those working on embedded
> systems can't use. I can. And even in the cases where I've had to
> do some programming on something, I've been able to write some tests
> in that editor, then transfer it over, and do the last bit of final
> debugging on the target, rather than doing it all in that limited
> toolset.
I'm not talking about what you can see. I mean that I'd hope that a C
programmer who can see how you are using the union will conclude that
it's bad code written by someone who's playing non-portable tricks for
no good reason. I hope they will not think, "I see, he wants to have
several differently typed pointer to the same object so he's naturally
put them in a union". I want him or her to say, "oh, this program needs
very careful checking because the programmer does not know what a union
is for".
>> What's more, I am sure you would agree that they would (and should) come
>> to a different conclusion if we were not talking about pointers.
>
> I would agree...
>
> In all cases where they're not pointers, UNLESS it's from something
> that's known to be the same size.
Let's say float and in are the same size. I think you'd agree that
using a union is not the right way to covert between one and the other.
As I keep saying, it's not about size -- size is only the most obvious
problem.
> Pointers in 32-bit code on Windows
> and ARM- and x86-based Linux are 32-bits. So, you can use this
> example safely because the compiler constraints are enforced by the
> architecture itself:
>
> union {
> uint32_t _ptr;
> void* ptr;
> };
Why would do that? Why write code that will break on os many other
systems? What do you think you are gaining by the incorrect use of a
union?
> I also extend this more generally to 32-bit and 64-bit compilations
> using an #if test at the start, and defining custom names based on
> the bit size:
>
> // Simplified for illustration, actual test is more complex
> #if 32-bits
> #define uptr uint32_t
>
> #elif 64-bits
> #define uptr uint64_t
Have you heard of uintptr_t?
> #else
> #error
> #endif
>
> union {
> uptr _ptr;
> void* ptr;
> };
>
> My targets are primarily x86 32-bit and 64-bit, and ARM 32-bit and
> 64-bit, and I'm content with that because it's a huge percentage of
> the market share. And if I ever need to change anything, I can
> rename my union members and find out in every instance where they're
> used in code by attempting to compile.
>
>> Anyway, I don't expect to change your mind, but I hope any learners who
>> might come across this thread will see the danger in writing code that
>> does not say what the programmer means, even if if it almost always
>> works.
>
> In the case of pointers, using unions does say what the programmer means.
> It just does it in a way which doesn't slap you on the face on every line
> of source code which references it. And to me, that's a good thing. In
> fact, it's a requirement.
>
>> >> > First of all it will only affect the most obtuse or
>> >> > special-equipment compilers. Second, you can use some compile-time
>> >> > checks to ensure things you do rely upon are the same size, such as
>> >> > comparing sizeof(void*) to sizeof(other*), etc., and if they are
>> >> > different reporting it during compilation with #if blocks.
>> >>
>> >> It's not just about size.
>> >
>> > Then it would be possible to also use a runtime test which, if it fails,
>> > reports that condition and exits out explaining in comments how it can
>> > be fixed.
>>
>> Two points: First, can you really do that (and I mean "you" not "one")?
>
> Sure.
>
>> Can you really write a compile-time test that checks the actual
>> assumptions that your suggested use of unions relies on, or are you just
>> speculating that it must, surely, be possible?
>
> Sure. If there's a test case, such as your example, where the address
> of A won't equal B, when A and B should be equal, then it can be tested.
>
> You can use pointer math if your compiler supports it, and if not, then
> use a union which encompasses a pointer and a sufficiently large integer,
> and simply do a compare. They have to be exactly equal to pass the test.
> If they don't, report the failure observed at runtime.
No, that won't do what you claimed. It's not about integers, it's about
void * and a struct xxx *. You said a compile time test could verify
what your union is assuming.
>> Second, it's usually possible to test for unwarranted assumption being
>> made by come bit of code, but it's much better simply not to make those
>> unwarranted assumptions in the first place.
>
> It might be for the well-versed C developer, the one who has spent time
> learning and thinking about those things regularly, and has come to form
> a pattern of though which exhibits those traits naturally from within
> its creation mechanisms.
Let's not fuss about getting it right in every case. At least as far as
converting a pointer is concerned the OP seemed to know about the right
way you introduced the wrong way to him! That's setting learning back.
<snip>
> To put it simply: it's just too much work for most code because most
> targets don't need it.
No, the right way is simple and no work at all. The wrong way involves
a new type and member access. This is not simpler than a cast hear and
there. (And the really, really right way will not be converting
between void * and struct pointers anyway.)
>> <snip>
>> > I just don't believe the burden should be on every C developer to write
>> > code for every possible architecture all the time, especially when they're
>> > targeting a handful of architectures where it's not at issue.
>>
>> But here we are simply talking about doing it right. There is no
>> burden in writing the code the correct and portable way. There is no
>> possible justification (that I can see) for doing it the wrong way.
>
> This is always our same argument. You place EXTREME value on things I
> do not place ANY value upon, except in cases where such value is
> warranted, such as were I to decide to write some code which **I INTENDED**
> to be released on ever architecture. But, I simply don't do that.
I have not been arguing from the point of view of portability. My point
(which I'll just assume you've missed rather than ignored) is that the
union tells the reader the wrong thing. To any well-read C programmer
it raises the question of why the author is re-interpreting bits rather
than converting between values.
What would you think if you saw a number being negated using ~x + 1?
Would you say, ah, OK this is only supposed to work on integer types and
one some machines, or would you start to scour the code for other places
where the author is misusing C features?
> I'm perfectly content to support only those architectures which have
>the same sized pointers, and where pointer references in a union will
>all point to the same location regardless of whether they were cast or
>not.
>
> In fact, I would completely avoid an architecture that did not support
> those features
That's fine. I have no interest in the portability of your code. You
made a suggestion to someone who's learning C and it needed to be
cleared up. I don't want you to start doing it right, I just don't want
more and more people to get the wrong ideas about unions vs. conversions.
> You're talking about doing it "right" in the context of supporting all
> of those obtuse architectures,
No. I'm talking about doing it right to be clear about what the code
means. I would not use a union even for a throw-away program on one
architecture because it's more complicated and does not communicate
correctly what the code is doing.
> those which the code will likely never
> be compiled on, under the thinking that a some point, somewhere, in
> some distant corner of the globe, some user might haphazardly try to
> compile some of that code and (oh my gosh!! much to their horror!!) it
> doesn't work on the first try and they have to go in to the source code
> and make a few changes to make it work on their known-to-be-obtuse
> architecture.
>
> I find that conclusion shocking, and wrong. I think it is so amazingly
> wrong that I would never, under any circumstances, purport it, save one
> and only one instance: if you had some desire to write code which was
> kept to the C standard because you wanted to be able to globally support
> all architectures. Which brings up the question, by the way, is there
> ANY code ANYWHERE that does that? Is there truly a form of source code
> you can write which will ALWAYS compile on ANY architecture without
> requiring ANY changes whatsoever?
>
> You place enough value on that "possible contingency" that it may be
> used by someone else that you would require all code be written so as
> to address it.
>
> No, sir. No how. No way. Not ever.
That's a straw man. I don't advocate that position. You (and anyone
else) can write code as architecture-specific as you like. Just don't
tell people learning C to use a union to (not) convert pointer types.
> Not on my watch.
Eh? You are prepared to lay down you life for the right to tell people
who are learning C to use a complex and confusing way to convert between
pointer types! I'll have to pry that union out of your cold dead hands!
No, there's no nobility here. Just write it the right way. It's
simpler and conveys the code's meaning more clearly. Try not to be
offended by the fact that it also happens to be portable to many odd
architectures. That's just an incidental advantage.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-12 09:52 -0700 |
| Message-ID | <6217ad04-8f37-40f4-a19b-7c2c32ccd3c5@googlegroups.com> |
| In reply to | #67211 |
On Wednesday, August 12, 2015 at 12:20:02 PM UTC-4, Ben Bacarisse wrote:
> I'm not talking about what you can see. I mean that I'd hope that a C
> programmer who can see how you are using the union will conclude that
> it's bad code written by someone who's playing non-portable tricks for
> no good reason. I hope they will not think, "I see, he wants to have
> several differently typed pointer to the same object so he's naturally
> put them in a union". I want him or her to say, "oh, this program needs
> very careful checking because the programmer does not know what a union
> is for".
It's exactly what a union is for, sharing memory when only one type
is needed at a time, or when you want to examine or access its
fundamental form as a series of bytes, for example.
> > Pointers in 32-bit code on Windows
> > and ARM- and x86-based Linux are 32-bits. So, you can use this
> > example safely because the compiler constraints are enforced by the
> > architecture itself:
> >
> > union {
> > uint32_t _ptr;
> > void* ptr;
> > };
>
> Why would do that? Why write code that will break on os many other
> systems? What do you think you are gaining by the incorrect use of a
> union?
Simplicity in populating values without casting when it's just data.
I am able to pass an unsigned integer (32-bit or 64-bit as per the
compile flags), and then populate into the target using a simple
assignment.
Most often it goes like this:
union {
sptr _funcWhatever;
int (*funcWhatever) (SWhatever* w, int i, float f, ...);
};
Rather than trying to pass my function address as a parameter by
casting it appropriately, or to cast my function into that
funcWhatever form, I simply pass it by sptr value, and then
populate into. The address of the function might be in a loaded
DLL, for example, or it might come from some native code.
I use this so often I've added it as a feature of RDC. Every variable
that's defined has the ability to access its fundamental value as an
unsigned integer of appropriate size using the "_name" convention for
a "name" definition. It is not required to be defined anywhere, but
is available everywhere. And it can be disabled with a switch.
> > I also extend this more generally to 32-bit and 64-bit compilations
> > using an #if test at the start, and defining custom names based on
> > the bit size:
> >
> > // Simplified for illustration, actual test is more complex
> > #if 32-bits
> > #define uptr uint32_t
> >
> > #elif 64-bits
> > #define uptr uint64_t
>
> Have you heard of uintptr_t?
Nope. I think the u****_t forms are silly. I typedef them at the
start of my program to s32, u32, f32, etc., and never look back.
> > #else
> > #error
> > #endif
> >
> > union {
> > uptr _ptr;
> > void* ptr;
> > };
> >
> > My targets are primarily x86 32-bit and 64-bit, and ARM 32-bit and
> > 64-bit, and I'm content with that because it's a huge percentage of
> > the market share. And if I ever need to change anything, I can
> > rename my union members and find out in every instance where they're
> > used in code by attempting to compile.
> >
> >> Anyway, I don't expect to change your mind, but I hope any learners who
> >> might come across this thread will see the danger in writing code that
> >> does not say what the programmer means, even if if it almost always
> >> works.
> >
> > In the case of pointers, using unions does say what the programmer means.
> > It just does it in a way which doesn't slap you on the face on every line
> > of source code which references it. And to me, that's a good thing. In
> > fact, it's a requirement.
> >
> >> >> > First of all it will only affect the most obtuse or
> >> >> > special-equipment compilers. Second, you can use some compile-time
> >> >> > checks to ensure things you do rely upon are the same size, such as
> >> >> > comparing sizeof(void*) to sizeof(other*), etc., and if they are
> >> >> > different reporting it during compilation with #if blocks.
> >> >>
> >> >> It's not just about size.
> >> >
> >> > Then it would be possible to also use a runtime test which, if it fails,
> >> > reports that condition and exits out explaining in comments how it can
> >> > be fixed.
> >>
> >> Two points: First, can you really do that (and I mean "you" not "one")?
> >
> > Sure.
> >
> >> Can you really write a compile-time test that checks the actual
> >> assumptions that your suggested use of unions relies on, or are you just
> >> speculating that it must, surely, be possible?
> >
> > Sure. If there's a test case, such as your example, where the address
> > of A won't equal B, when A and B should be equal, then it can be tested.
> >
> > You can use pointer math if your compiler supports it, and if not, then
> > use a union which encompasses a pointer and a sufficiently large integer,
> > and simply do a compare. They have to be exactly equal to pass the test.
> > If they don't, report the failure observed at runtime.
>
> No, that won't do what you claimed. It's not about integers, it's about
> void * and a struct xxx *. You said a compile time test could verify
> what your union is assuming.
It's about the address of a void* and a struct xyz*, which can be done
by comparing integers of the appropriate size. In order for them to be
the same, they must be equal, regardless of what value they are.
> >> Second, it's usually possible to test for unwarranted assumption being
> >> made by come bit of code, but it's much better simply not to make those
> >> unwarranted assumptions in the first place.
> >
> > It might be for the well-versed C developer, the one who has spent time
> > learning and thinking about those things regularly, and has come to form
> > a pattern of though which exhibits those traits naturally from within
> > its creation mechanisms.
>
> Let's not fuss about getting it right in every case. At least as far as
> converting a pointer is concerned the OP seemed to know about the right
> way you introduced the wrong way to him! That's setting learning back.
The way I introduced him to is not wrong. It is the purpose of the
union. The only places where it wouldn't work is in the case where
you identify on one architecture where the addresses of the void* may
be different than another pointer. And, the startup runtime test
would've already concluded that it's not an issue by the time it gets
to this location in the running program, thereby highlighting the issue
at startup, or completely removing the concern by the time it gets here.
> <snip>
> > To put it simply: it's just too much work for most code because most
> > targets don't need it.
>
> No, the right way is simple and no work at all. The wrong way involves
> a new type and member access. This is not simpler than a cast hear and
> there. (And the really, really right way will not be converting
> between void * and struct pointers anyway.)
I'm sorry, Ben, but in my view your solution is insane. The cast would
be required on every use instance, and that is insane.
If that's something the C standard purports by its definition, then the
C standard is wrong and needs to be changed. It is insane to impose
that burden upon every developer when the compiler is perfectly capable
of doing all that busywork for you.
It might be worth forcing a cast on the first assignment into the union
member, which is why I use C++ compilers for my "C code," because I want
that extra type checking. But, not to the extent you're talking about.
I appreciate your knowledge of C and its standard, and I would rely upon
you (and others here) were I asking questions about that end, but for
practical code, your comment is to me like the conversations between
Leah Brahms and Geordi regarding the several things he does differently
on board the Enterprise when out in deep space, compared to what she had
defined to be the requirements in the workshops at Utopia Planetia. The
two just don't mate up in the real world, and are of no value in the
vast majority of cases I've seen (at least in this area).
> >> <snip>
> >> > I just don't believe the burden should be on every C developer to write
> >> > code for every possible architecture all the time, especially when they're
> >> > targeting a handful of architectures where it's not at issue.
> >>
> >> But here we are simply talking about doing it right. There is no
> >> burden in writing the code the correct and portable way. There is no
> >> possible justification (that I can see) for doing it the wrong way.
> >
> > This is always our same argument. You place EXTREME value on things I
> > do not place ANY value upon, except in cases where such value is
> > warranted, such as were I to decide to write some code which **I INTENDED**
> > to be released on ever architecture. But, I simply don't do that.
>
> I have not been arguing from the point of view of portability. My point
> (which I'll just assume you've missed rather than ignored) is that the
> union tells the reader the wrong thing. To any well-read C programmer
> it raises the question of why the author is re-interpreting bits rather
> than converting between values.
Any well-read C programmer spent some of that well-reading time outside
of textbooks, I hope, and into practical code out there in the wild.
Using unions for shared memory that takes on a form based on some cue
IS COMPLETELY STANDARD. It's done every day. It's the purpose of a
union, especially when one recognizes that char and int types are not
some mystical things, but are locations in memory of a certain size,
sporting a particular value range. It's just data. They are not
physical constructions.
> What would you think if you saw a number being negated using ~x + 1?
I would think: "Craziness. Lunacy."
> Would you say, ah, OK this is only supposed to work on integer types and
> one some machines, or would you start to scour the code for other places
> where the author is misusing C features?
I would stop looking at the code and find some other library which does
the same thing, or rewrite it myself if it were small enough.
> > I'm perfectly content to support only those architectures which have
> >the same sized pointers, and where pointer references in a union will
> >all point to the same location regardless of whether they were cast or
> >not.
> >
> > In fact, I would completely avoid an architecture that did not support
> > those features
>
> That's fine. I have no interest in the portability of your code. You
> made a suggestion to someone who's learning C and it needed to be
> cleared up. I don't want you to start doing it right, I just don't want
> more and more people to get the wrong ideas about unions vs. conversions.
I don't see how it's wrong, Ben. You have yet to explain it apart from
those cases where pointers to a block of bytes in memory will physically
change location when casting that block to a void*, or casting it to a
struct xyz*. You'll have to give me a concrete example, a real-world
example you've seen, one I can download, test, and compile, and examine
so I can arrive at the, "Oh yeah! Ben was right!" moment.
> > You're talking about doing it "right" in the context of supporting all
> > of those obtuse architectures,
>
> No. I'm talking about doing it right to be clear about what the code
> means. I would not use a union even for a throw-away program on one
> architecture because it's more complicated and does not communicate
> correctly what the code is doing.
Using unions is completely clear in this context. They are all pointers.
The reality is you are passed some block of data which, based on a cue
of some kind, indicates what type it is.
How is that not clear? It couldn't be more clear.
> > those which the code will likely never
> > be compiled on, under the thinking that a some point, somewhere, in
> > some distant corner of the globe, some user might haphazardly try to
> > compile some of that code and (oh my gosh!! much to their horror!!) it
> > doesn't work on the first try and they have to go in to the source code
> > and make a few changes to make it work on their known-to-be-obtuse
> > architecture.
> >
> > I find that conclusion shocking, and wrong. I think it is so amazingly
> > wrong that I would never, under any circumstances, purport it, save one
> > and only one instance: if you had some desire to write code which was
> > kept to the C standard because you wanted to be able to globally support
> > all architectures. Which brings up the question, by the way, is there
> > ANY code ANYWHERE that does that? Is there truly a form of source code
> > you can write which will ALWAYS compile on ANY architecture without
> > requiring ANY changes whatsoever?
> >
> > You place enough value on that "possible contingency" that it may be
> > used by someone else that you would require all code be written so as
> > to address it.
> >
> > No, sir. No how. No way. Not ever.
>
> That's a straw man. I don't advocate that position. You (and anyone
> else) can write code as architecture-specific as you like. Just don't
> tell people learning C to use a union to (not) convert pointer types.
I will tell all of them to use unions. You're going to have to show
me an example which will fail doing it that way, and won't fail when
using a dizzying array of casts.
> > Not on my watch.
>
> Eh? You are prepared to lay down you life for the right to tell people
> who are learning C to use a complex and confusing way to convert between
> pointer types! I'll have to pry that union out of your cold dead hands!
There's nothing complex about it. In fact, it greatly simplifies source
code, and the understanding therein.
> No, there's no nobility here. Just write it the right way. It's
> simpler and conveys the code's meaning more clearly. Try not to be
> offended by the fact that it also happens to be portable to many odd
> architectures. That's just an incidental advantage.
I do write it the right way. It's the only way it should be done
because any other way requires a mass of casts, and that's just eye
clutter, especially for someone with dyslexia.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-12 22:40 +0100 |
| Message-ID | <87614k5gmp.fsf@bsb.me.uk> |
| In reply to | #67213 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Wednesday, August 12, 2015 at 12:20:02 PM UTC-4, Ben Bacarisse wrote:
>> I'm not talking about what you can see. I mean that I'd hope that a C
>> programmer who can see how you are using the union will conclude that
>> it's bad code written by someone who's playing non-portable tricks for
>> no good reason. I hope they will not think, "I see, he wants to have
>> several differently typed pointer to the same object so he's naturally
>> put them in a union". I want him or her to say, "oh, this program needs
>> very careful checking because the programmer does not know what a union
>> is for".
>
> It's exactly what a union is for, sharing memory when only one type
> is needed at a time, or when you want to examine or access its
> fundamental form as a series of bytes, for example.
That's not what's being done here. Instead, a value of one type needs
to be converted to a value of another. The union does not do that.
When both values have the same representation you can, indeed, get the
desired effect using the otherwise entirely unnecessary new type -- the
union.
>> > Pointers in 32-bit code on Windows
>> > and ARM- and x86-based Linux are 32-bits. So, you can use this
>> > example safely because the compiler constraints are enforced by the
>> > architecture itself:
>> >
>> > union {
>> > uint32_t _ptr;
>> > void* ptr;
>> > };
>>
>> Why would do that? Why write code that will break on os many other
>> systems? What do you think you are gaining by the incorrect use of a
>> union?
>
> Simplicity in populating values without casting when it's just data.
> I am able to pass an unsigned integer (32-bit or 64-bit as per the
> compile flags), and then populate into the target using a simple
> assignment.
You have code where uint32_t is 32 or 64 bits as per compile flags?
> Most often it goes like this:
>
> union {
> sptr _funcWhatever;
> int (*funcWhatever) (SWhatever* w, int i, float f, ...);
> };
>
> Rather than trying to pass my function address as a parameter by
> casting it appropriately, or to cast my function into that
> funcWhatever form, I simply pass it by sptr value, and then
> populate into. The address of the function might be in a loaded
> DLL, for example, or it might come from some native code.
You keep introducing new examples. First a void * and two struct
pointers. Then a uint32_t (that might be 64 bits?) and a void *. Now
two function pointer types. But in all cases all you do is show the
unnecessary union. In no case do you show the code that gets simplified
by it's use. You may have a point here (since I'd never use a union to
fake a type conversion I've no experience in writing in that style) but
if you never show an example I could re-write using the correct types
your claim is hard to verify.
<snip>
>> >> Can you really write a compile-time test that checks the actual
>> >> assumptions that your suggested use of unions relies on, or are you just
>> >> speculating that it must, surely, be possible?
>> >
>> > Sure. If there's a test case, such as your example, where the address
>> > of A won't equal B, when A and B should be equal, then it can be tested.
>> >
>> > You can use pointer math if your compiler supports it, and if not, then
>> > use a union which encompasses a pointer and a sufficiently large integer,
>> > and simply do a compare. They have to be exactly equal to pass the test.
>> > If they don't, report the failure observed at runtime.
>>
>> No, that won't do what you claimed. It's not about integers, it's about
>> void * and a struct xxx *. You said a compile time test could verify
>> what your union is assuming.
>
> It's about the address of a void* and a struct xyz*, which can be done
> by comparing integers of the appropriate size. In order for them to be
> the same, they must be equal, regardless of what value they are.
Unless you write the test I'm going to have to assume you can't. I
really don't know how to do it, so I'm not being coy here, but since I
also can't prove that you can't there is only one way to settle it:
write the test. How do you test, at compile time, that a particular
implementation has the same representation for all void * and struct
pointer pairs that point to the same object?
>> >> Second, it's usually possible to test for unwarranted assumption being
>> >> made by come bit of code, but it's much better simply not to make those
>> >> unwarranted assumptions in the first place.
>> >
>> > It might be for the well-versed C developer, the one who has spent time
>> > learning and thinking about those things regularly, and has come to form
>> > a pattern of though which exhibits those traits naturally from within
>> > its creation mechanisms.
>>
>> Let's not fuss about getting it right in every case. At least as far as
>> converting a pointer is concerned the OP seemed to know about the right
>> way you introduced the wrong way to him! That's setting learning back.
>
> The way I introduced him to is not wrong. It is the purpose of the
> union. The only places where it wouldn't work is in the case where
> you identify on one architecture where the addresses of the void* may
> be different than another pointer.
If a technique is very inefficient it can be wrong even if it works. If
a technique is complex or obscure it can be wrong even it it works. If
a technique interferes with the usual techniques of code review it can
be wrong even if it works. This technique is deceptive since it
circumvents the type system without using the usual signal for that
circumvention (as cast). That makes it wrong even where it works.
<snip>
> I'm sorry, Ben, but in my view your solution is insane. The cast would
> be required on every use instance, and that is insane.
The member access would be required on every instance. You are adding
an unnecessary type, and replacing every type conversion with a union
access (which does no conversion) and you call my advice insane?
I think you've just invested so much into the idea that bit are bits and
types are just the compiler being fussy that you can't see the other
side of the argument.
> If that's something the C standard purports by its definition, then the
> C standard is wrong and needs to be changed. It is insane to impose
> that burden upon every developer when the compiler is perfectly capable
> of doing all that busywork for you.
There is no such burden. You need to write some code that uses your
void * struct * union so that can re-write it using the corect types.
Until you do that I can't show you that your "simplification" is just
obfuscation.
I can't really do the reverse because in the code I tend to write casts
are very rare indeed. I'm struggling to think of an example I could
write using the correct types that you could "improve" with the union.
Maybe you could suggest a micro code project that you think will need
this technique and I'll have a go?
<snip>
>> >> But here we are simply talking about doing it right. There is no
>> >> burden in writing the code the correct and portable way. There is no
>> >> possible justification (that I can see) for doing it the wrong way.
>> >
>> > This is always our same argument. You place EXTREME value on things I
>> > do not place ANY value upon, except in cases where such value is
>> > warranted, such as were I to decide to write some code which **I INTENDED**
>> > to be released on ever architecture. But, I simply don't do that.
>>
>> I have not been arguing from the point of view of portability. My point
>> (which I'll just assume you've missed rather than ignored) is that the
>> union tells the reader the wrong thing. To any well-read C programmer
>> it raises the question of why the author is re-interpreting bits rather
>> than converting between values.
>
> Any well-read C programmer spent some of that well-reading time outside
> of textbooks, I hope, and into practical code out there in the wild.
>
> Using unions for shared memory that takes on a form based on some cue
> IS COMPLETELY STANDARD. It's done every day.
Yes, but using a union where a type conversion is meant is not standard
and should never be thought of as standard. I've never seen it done in
any of the hundreds of thousands of lines of C I've read, contributed to
and written in the last 32 years.
If you think your suggestion is the same as
struct value {
int type;
union {
int i;
double d;
void *p;
} v;
};
then you've completely missed the points I'm making.
<snip>
>> What would you think if you saw a number being negated using ~x + 1?
>
> I would think: "Craziness. Lunacy."
Why? It works, doesn't it? OK, so it works by using the representation
in x rather than the value of x, but you are OK with that provided the
code works.
>> Would you say, ah, OK this is only supposed to work on integer types and
>> one some machines, or would you start to scour the code for other places
>> where the author is misusing C features?
>
> I would stop looking at the code and find some other library which does
> the same thing, or rewrite it myself if it were small enough.
>
>> > I'm perfectly content to support only those architectures which have
>> >the same sized pointers, and where pointer references in a union will
>> >all point to the same location regardless of whether they were cast or
>> >not.
>> >
>> > In fact, I would completely avoid an architecture that did not support
>> > those features
>>
>> That's fine. I have no interest in the portability of your code. You
>> made a suggestion to someone who's learning C and it needed to be
>> cleared up. I don't want you to start doing it right, I just don't want
>> more and more people to get the wrong ideas about unions vs. conversions.
>
> I don't see how it's wrong, Ben. You have yet to explain it apart from
> those cases where pointers to a block of bytes in memory will physically
> change location when casting that block to a void*, or casting it to a
> struct xyz*. You'll have to give me a concrete example, a real-world
> example you've seen, one I can download, test, and compile, and examine
> so I can arrive at the, "Oh yeah! Ben was right!" moment.
Sorry, but that's not my concern here. I'm happy for you to continue to
think I'm wrong. All I really care about is that people who are
undecided (and that will be people learning C) don't end up thinking
you're right. To do that, I just need to make my case to them --
readers who might stumble across this thread in the future as well a a
few who might be reading now.
>> > You're talking about doing it "right" in the context of supporting all
>> > of those obtuse architectures,
>>
>> No. I'm talking about doing it right to be clear about what the code
>> means. I would not use a union even for a throw-away program on one
>> architecture because it's more complicated and does not communicate
>> correctly what the code is doing.
>
> Using unions is completely clear in this context. They are all
> pointers.
Yes, the union is clear but the code that uses it is not because the use
of a union hides the purpose -- to convert one type to another.
Of course, I know that in your mind, the purpose is to take the bits and
use them as you want -- i.e. to get round the pesky type system that C
puts in the way of a programmer working in that odd place called the
real world.
> The reality is you are passed some block of data which, based on a cue
> of some kind, indicates what type it is.
>
> How is that not clear? It couldn't be more clear.
You could make it more clear by converting the value from the type is
currently is to the one you want to consider it to be. That's the right
way because it works for all convertible type pairs -- you can do for
int and float in exactly the same was as for void * and int *. And you
don't need to invent a new type that has no other value than to fail to
do this conversion.
<snip>
>> That's a straw man. I don't advocate that position. You (and anyone
>> else) can write code as architecture-specific as you like. Just don't
>> tell people learning C to use a union to (not) convert pointer types.
>
> I will tell all of them to use unions. You're going to have to show
> me an example which will fail doing it that way, and won't fail when
> using a dizzying array of casts.
>
>> > Not on my watch.
>>
>> Eh? You are prepared to lay down you life for the right to tell people
>> who are learning C to use a complex and confusing way to convert between
>> pointer types! I'll have to pry that union out of your cold dead hands!
>
> There's nothing complex about it. In fact, it greatly simplifies source
> code, and the understanding therein.
You need to show an example of that. Your "solution" appears to need a
new type, not otherwise needed, and it replaces a possible cast with a
definite member access. That's not "greatly simplified" in my book.
Let's see... A beginner asks "I have a void * that points to a node in
a linked list. How do I access the members of the node?". I say:
struct list_node *lnp = vp;
lnp->data ... lnp->next ...
not even one cast in sight. Now, what is your answer to the keen
beginner?
>> No, there's no nobility here. Just write it the right way. It's
>> simpler and conveys the code's meaning more clearly. Try not to be
>> offended by the fact that it also happens to be portable to many odd
>> architectures. That's just an incidental advantage.
>
> I do write it the right way. It's the only way it should be done
> because any other way requires a mass of casts, and that's just eye
> clutter, especially for someone with dyslexia.
No mass of casts, no. Not unless there is a mass of member accesses in
your version, of course. There will be no more casts than there will be
member access (and there can be fewer -- you can't ever omit a member
access). But the casts tell the truth while every member access is a
little lie, and for every one of those a bit dies somewhere in the
world.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-13 13:31 +0200 |
| Message-ID | <mqhv3h$arf$1@dont-email.me> |
| In reply to | #67213 |
On 12/08/15 18:52, Rick C. Hodgin wrote:
> On Wednesday, August 12, 2015 at 12:20:02 PM UTC-4, Ben Bacarisse wrote:
>> I'm not talking about what you can see. I mean that I'd hope that a C
>> programmer who can see how you are using the union will conclude that
>> it's bad code written by someone who's playing non-portable tricks for
>> no good reason. I hope they will not think, "I see, he wants to have
>> several differently typed pointer to the same object so he's naturally
>> put them in a union". I want him or her to say, "oh, this program needs
>> very careful checking because the programmer does not know what a union
>> is for".
>
> It's exactly what a union is for, sharing memory when only one type
> is needed at a time, or when you want to examine or access its
> fundamental form as a series of bytes, for example.
(The following information is correct to the best of my knowledge, but
it's a complicated subject. If I've got something wrong, hopefully one
of the other experts here will correct it. And if it's right, then
hopefully others will confirm it. Until that time, treat it with a
little bit of caution.)
That is one use of unions. Another is for type punning. But type
punning using unions is not about using unions to change pointer types -
it is about using pointers to unions to make the changes safe.
Let's take an example - code that swaps the high and low 16-bit halves
of a 32-bit integer. I am using uint16_t and uint32_t, so assumptions
about CHAR_BIT being 8 or 16 and so on apply.
uint32_t swapWrong1(uint32_t a) {
uint32_t b;
uint16_t* pA = (uint16_t*) &a;
uint16_t* pB = (uint16_t*) &b;
pB[1] = pA[0];
pB[0] = pA[1];
return b;
}
This code is wrong, because of aliasing - the compiler knows that "a"
and "b" are uint32_t, and therefore any accesses (read or write) done
via pointers to uint16_t cannot apply to either a or b, because uint32_t
and uint16_t objects cannot be aliased (i.e., they cannot exist at the
same address). So the code has undefined behaviour.
uint32_t swapWrong2(uint32_t a) {
uint32_t b;
union {
uint32_t* p32;
uint16_t* p16;
} pA, pB;
pA.p32 = &a;
pB.p32 = &b;
pB.p16[1] = pA.p16[0];
pB.p16[0] = pA.p16[1];
return b;
}
This code uses your "union of pointers" in order to do the same thing,
but avoiding the casts. It has /exactly/ the same problems as
swapWrong1 regarding aliasing and undefined behaviour.
(I agree with Ben that the use of a union of pointers to convert between
pointer types, as shown above and in your code, is poor style. But that
is a separate issue from the point I am making here.)
uint32_t swapRight1(uint32_t a) {
uint32_t b;
union {
uint32_t x32;
uint16_t x16[2];
} uA, uB;
uA.x32 = a;
uB.x16[1] = uA.x16[0];
uB.x16[0] = uA.x16[1];
b = uB.x32;
return b;
}
This works, because type-punning using unions is allowed in C (if the
implementation-dependent representations of the union members are
compatible - which the existence of uint16_t and uint32_t types guarantees).
The incorrect versions will /probably/ work, especially as stand-alone
functions - but they are not guaranteed to do so. If they are inlined,
with a good optimising compiler, then they may not do what the
programmer intended.
>
> Simplicity in populating values without casting when it's just data.
> I am able to pass an unsigned integer (32-bit or 64-bit as per the
> compile flags), and then populate into the target using a simple
> assignment.
>
> Most often it goes like this:
>
> union {
> sptr _funcWhatever;
> int (*funcWhatever) (SWhatever* w, int i, float f, ...);
> };
>
> Rather than trying to pass my function address as a parameter by
> casting it appropriately, or to cast my function into that
> funcWhatever form, I simply pass it by sptr value, and then
> populate into. The address of the function might be in a loaded
> DLL, for example, or it might come from some native code.
The way to handle this is to pass the union as a parameter.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-08-14 20:39 -0400 |
| Message-ID | <SSvzx.50716$g72.45792@fx12.iad> |
| In reply to | #67268 |
On 8/13/15 7:31 AM, David Brown wrote: > This works, because type-punning using unions is allowed in C (if the > implementation-dependent representations of the union members are > compatible - which the existence of uint16_t and uint32_t types guarantees). > > > The incorrect versions will /probably/ work, especially as stand-alone > functions - but they are not guaranteed to do so. If they are inlined, > with a good optimising compiler, then they may not do what the > programmer intended. > Type punning is a funny corner of the standard, as its behavior doesn't fall into any of the normal categories. It isn't "Standard Defined", as the Standard doesn't define the value you get out of the union. It isn't "Implementation Defined" as the Standard doesn't require the implementation to document the results. It isn't "Unspecified Behavior", as across all implementations, in general, anything could happen, so we don't have the limitation of behavior implicit in unspecified behavior (in particular, in general we can get trap values). It also isn't "Undefined Behavior", as the Standard does NOT give the implementation free reign over what happens. The implementation, having chosen a representation, needs to follow this. In this case, since we have exact sized types, we do have a lot of promises by the standard (for example we can't get a trap value), and the two smaller values must access all of the larger value. I am fairly sure that we are promised that there is a 1:1 mapping of larger values to pairs of smaller values, which yields the fact that the swap is reversible. We don't have a promise over the mapping of the bits of the larger to the smaller. We naturally have endian questions, and I believe the Standard allows even more esoteric mixing up (like one of the types being stored in a different bit order of the other, presumably because the processor supports this).
[toc] | [prev] | [next] | [standalone]
Page 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web