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 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-05 13:03 -0700 |
| Message-ID | <kfnsi6svdjv.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #67439 |
Richard Damon <Richard@Damon-Family.org> writes: > 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. I would call it indirectly implementation-defined, similar to how | works in implemenations that have negative zeroes. The particular value obtained may depend of the particular bit values in the case of unspecified values, but if there are no unspecified bit values the value is implemenation-defined, because the representations of all types are implemenation-defined. > 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. There are 2**32 distinct values in 32 bits, with each half having 2**16 values in 16 bits. So the mapping between a larger value and pairs of smaller values being 1-to-1 is a pretty safe bet. :) > 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). The Standard surely allows all 32 factorial assignments of bit number to value weight in any integer type that has 32 value bits and no padding bits. For example, it would be allowed to have all the odd bit numbers in the low half, and the even bit numbers in the high half.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-05 14:16 -0700 |
| Message-ID | <kfnfv2sva6l.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #67268 |
David Brown <david.brown@hesbynett.no> writes:
> [snip]
>
> 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).
This code "works" only in the sense that the assignments will
succeed. What the semantics is may not be anything useful.
In particular it might be different from b = a<<16 | a>>16.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-06 11:19 +0200 |
| Message-ID | <msh0b8$jo7$1@dont-email.me> |
| In reply to | #69541 |
On 05/09/15 23:16, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> [snip]
>>
>> 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).
>
> This code "works" only in the sense that the assignments will
> succeed. What the semantics is may not be anything useful.
> In particular it might be different from b = a<<16 | a>>16.
>
Can you give an explanation of that? I may have missed something here,
but my understanding is that if an implementation provides the types
uint16_t and uint32_t, then those types must be exact sizes without
padding. The corresponding int16_t and int32_t types must also exist,
and be two's complement. There is no scope for trap representations,
missing values, or anything of that sort.
The only thing I can think you might mean is endian issues - the
standard does not enforce any particular ordering of the bits in an
integer type. But my code above only claims to swap the high and low
16-bit halves of the 32-bit (unsigned) integer - you snipped that bit in
the quotation. Almost all real-world systems are either pure big-endian
or pure little-endian in byte order (there are a few mixed-endian
systems, but not many), and for such systems then this will compute (a
<< 16) | (a >> 16). But that was not actually the specification for the
function.
But as I said, I may have missed something else, and would be happy to
hear about it.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-06 18:15 -0700 |
| Message-ID | <kfnr3mbni68.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #69589 |
David Brown <david.brown@hesbynett.no> writes:
> On 05/09/15 23:16, Tim Rentsch wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> [snip]
>>>
>>> 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).
>>
>> This code "works" only in the sense that the assignments will
>> succeed. What the semantics is may not be anything useful.
>> In particular it might be different from b = a<<16 | a>>16.
>
> Can you give an explanation of that? [snip]
Please see my followup to Richard Damon's post.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-07 09:13 +0200 |
| Message-ID | <msjdah$iih$1@dont-email.me> |
| In reply to | #69715 |
On 07/09/15 03:15, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 05/09/15 23:16, Tim Rentsch wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> [snip]
>>>>
>>>> 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).
>>>
>>> This code "works" only in the sense that the assignments will
>>> succeed. What the semantics is may not be anything useful.
>>> In particular it might be different from b = a<<16 | a>>16.
>>
>> Can you give an explanation of that? [snip]
>
> Please see my followup to Richard Damon's post.
>
As far as I can see, your objection there is basically that the
standards do not impose any ordering on the bits in an unsigned integer
type - merely that they are binary bits. The function I gave will only
compute (a << 16) | (a >> 16) for some orderings (albeit orderings such
as pure little-endian and pure big-endian, and thus virtually every real
system).
That is pretty much exactly what I wrote (after your post inspired me to
think through the details), and which you snipped.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-08-12 08:07 -0400 |
| Message-ID | <bGGyx.29994$bg4.25630@fx29.iad> |
| In reply to | #67179 |
On 8/12/15 7:41 AM, 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 classic case is a machine where native pointers point to a 'word' (because that is how the machine addresses memory) so to handle a pointer to a specific byte, you need to add another word with that information. Thus pointers to char and void will be large than other pointers. >> 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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-12 14:08 +0100 |
| Message-ID | <87k2t08xin.fsf@bsb.me.uk> |
| In reply to | #67184 |
Richard Damon <Richard@Damon-Family.org> writes: > On 8/12/15 7:41 AM, 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 classic case is a machine where native pointers point to a 'word' > (because that is how the machine addresses memory) so to handle a > pointer to a specific byte, you need to add another word with that > information. Thus pointers to char and void will be large than other > pointers. On the word-addressed machine I was referring to (the Perq), there was a different scheme for C[1]. All data pointers were the same size, but in character pointers the low-order bit indicated which byte to access (it was a long time ago when 16 bits of data per-program seemed like enough). The result was that some casts generated a shift instruction. Code addresses were double size with a 16-bit segment and a 16-bit offset, but every function was compiled to it's own segment with the entry point being offset zero. Thus, as far as C was concerned, function pointers were just 16-bit numbers. This was great because you'd get to know the numbers! Early on, when there was no symbolic debugger, you could tell that you'd crashed in function 28 (printf) or 178 (qsort) and so on. Very handy. <snip> [1] And the "for C" matters. The machine had a micro-coded instruction set that was part of the process state. A C program would have the instruction set designed for C whereas, for example, a Lisp program had a lisp machine's instruction set. Sometimes I miss those days -- we no longer live in interesting times as far as machine architecture goes. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-12 10:24 -0700 |
| Message-ID | <d4b0ddce-6e47-4d9c-ae01-dc65ddb2f4ef@googlegroups.com> |
| In reply to | #67170 |
On Wednesday, August 12, 2015 at 6:39:24 AM UTC-4, Ben Bacarisse wrote:
> "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.
This is one valid reason I can see for not writing unions the way I
do, which is if you place a high emphasis on writing to the standard.
I can see that being important to some people. It's just not important
to me, at least not important enough to make it a requirement that all
developers on all architectures everywhere do it.
> 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.
I agree with the idea of casting it into the union member the first
time. I do not agree with casting it on use.
> 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.
The second was the form Morten was interested in using. A pointer was
passed to him, and it pointed to some location in memory which had its
data arranged as the indicated structure. And rather than casting every
reference, by populating it into the void* location, and then using the
appropriately named structure member, each member of that structure
could be accessed without a cast.
I see this as a 500:1 preferable solution over casting on every use.
If there was only one reference, I could see casting it on use. If
there were two or more, nope.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-12 20:45 +0100 |
| Message-ID | <87k2t05gms.fsf@bsb.me.uk> |
| In reply to | #67215 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Wednesday, August 12, 2015 at 6:39:24 AM UTC-4, Ben Bacarisse wrote: <snip> >> 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. ["This is a much more rare and specialised usage"] > The second was the form Morten was interested in using. No. Its the form you are suggesting he use. He wants (logically) a type conversion, and you are suggesting a hack that happens to work. > A pointer was > passed to him, and it pointed to some location in memory which had its > data arranged as the indicated structure. And rather than casting every > reference, by populating it into the void* location, and then using the > appropriately named structure member, each member of that structure > could be accessed without a cast. You've not worked out the details, presumably because you've never written the code using the correct types, but the "correct type" alternative for Morten is much simpler than your hack. The irony is that doing it correctly will, in his specific use-case, involve no casts at all because he should not be using void * in the first place! I've written exactly the sort of code Morten is writing numerous times. The result is not a mess of casts. There are one or two in very specific cases which have not yet even been illustrated, and the fact that the casts stand out in those cases is important: they flag a potentially risky type conversion. You don't need them at all for setting the parent pointer of one type of node from the parent pointer of another. > I see this as a 500:1 preferable solution over casting on every use. > If there was only one reference, I could see casting it on use. If > there were two or more, nope. Can we agree to leave it at that? You continue to use the reinterpretation of representations in those cases where it happens to work, and I'll continue to tell people learning C to use type conversion when they want to convert between types? Nether of us will change our minds and I'm happy to let others simply decide for themselves whose advice to take. If they are unsure, maybe a search for previous post by you and by me might help them decide, but there's clearly no point in continuing this exchange. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-13 04:19 +0200 |
| Message-ID | <mqh5s1$6hd$1@speranza.aioe.org> |
| In reply to | #67224 |
On 12.08.2015 21:45, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: [...] >> A pointer was >> passed to him, and it pointed to some location in memory which had its >> data arranged as the indicated structure. And rather than casting every >> reference, by populating it into the void* location, and then using the >> appropriately named structure member, each member of that structure >> could be accessed without a cast. > > You've not worked out the details, presumably because you've never > written the code using the correct types, but the "correct type" > alternative for Morten is much simpler than your hack. The irony is > that doing it correctly will, in his specific use-case, involve no casts > at all because he should not be using void * in the first place! > > I've written exactly the sort of code Morten is writing numerous times. > The result is not a mess of casts. There are one or two in very > specific cases which have not yet even been illustrated, and the fact > that the casts stand out in those cases is important: they flag a > potentially risky type conversion. You don't need them at all for > setting the parent pointer of one type of node from the parent pointer > of another. > >> I see this as a 500:1 preferable solution over casting on every use. >> If there was only one reference, I could see casting it on use. If >> there were two or more, nope. > > Can we agree to leave it at that? You continue to use the > reinterpretation of representations in those cases where it happens to > work, and I'll continue to tell people learning C to use type conversion > when they want to convert between types? > > Nether of us will change our minds and I'm happy to let others simply > decide for themselves whose advice to take. If they are unsure, maybe a > search for previous post by you and by me might help them decide, but > there's clearly no point in continuing this exchange. Well, I think it is an important point that once the parser has run through the file, accessing the data for example for rendering the document as an XML file again, will entail going through each struct in memory and casting it to the right type, based on the first entry in the struct, the type. Rick talks about the union solution while you Ben talk about the casting. Would a good and correct compromise here be to use a union to restrict what is being pointed to, and at the same time use casting to work with the data? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-13 13:18 +0100 |
| Message-ID | <87tws34c1z.fsf@bsb.me.uk> |
| In reply to | #67254 |
"Morten W. Petersen" <morphex@gmail.com> writes: <snip> > Well, I think it is an important point that once the parser has run > through the file, accessing the data for example for rendering the > document as an XML file again, will entail going through each struct > in memory and casting it to the right type, based on the first entry > in the struct, the type. > > Rick talks about the union solution while you Ben talk about the > casting. Would a good and correct compromise here be to use a union to > restrict what is being pointed to, and at the same time use casting to > work with the data? That's not detailed enough to be sure what you mean. Here's my take on it: don't use a union to convert between types -- any types. That's not what it does. Using a union in the way Rick has been suggesting is simply a hack to get round the type system, and it works for pointers because, on most systems, all pointers to the same object use the same bit pattern. I hope you will simply reject this hack out of hand. If you need to convert a value of one type to a value of another type, C provides a way to do that with a cast (though for void * you don't even need a cast if the context makes the desired pointer type explicit). As for your final design, I don't see any need to convert pointers at all. This all started because you happened to have a void * and you simply put a cast in the wrong place. But you don't either the void * or the cast at all. Maybe there will be, one day, be a need to convert pointers, and I hope you will do that correctly with a cast, but in the meantime I would imagine you can do most of what you want with a discriminated union: place the common elements at the start of a struct and include in those some type indicator. After that, place a union that describes the various different data that are specific to each of your node types. For your purposes, this whole discussion has been a distraction. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-16 15:43 +0200 |
| Message-ID | <mqq41h$m70$1@speranza.aioe.org> |
| In reply to | #67276 |
On 13.08.2015 14:18, Ben Bacarisse wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
[...]
>> Rick talks about the union solution while you Ben talk about the
>> casting. Would a good and correct compromise here be to use a union to
>> restrict what is being pointed to, and at the same time use casting to
>> work with the data?
>
> That's not detailed enough to be sure what you mean.
>
> Here's my take on it: don't use a union to convert between types -- any
> types. That's not what it does. Using a union in the way Rick has been
> suggesting is simply a hack to get round the type system, and it works
> for pointers because, on most systems, all pointers to the same object
> use the same bit pattern. I hope you will simply reject this hack out
> of hand. If you need to convert a value of one type to a value of
> another type, C provides a way to do that with a cast (though for void *
> you don't even need a cast if the context makes the desired pointer type
> explicit).
>
> As for your final design, I don't see any need to convert pointers at
> all. This all started because you happened to have a void * and you
> simply put a cast in the wrong place. But you don't either the void *
> or the cast at all. Maybe there will be, one day, be a need to convert
> pointers, and I hope you will do that correctly with a cast, but in the
> meantime I would imagine you can do most of what you want with a
> discriminated union: place the common elements at the start of a struct
> and include in those some type indicator. After that, place a union
> that describes the various different data that are specific to each of
> your node types.
That's something like the design as it has been. I need to discuss this
further to be sure I understand what you are saying.
There are a couple of different struct definitions in the project,
and they all follow the same basic setup with type, next and parent.
When this data is accessed internally for example for writing an
XML file, they will be iterated over. The code that iterates
over these struct instances in memory, will know what to do with
the data, based on the first entry in the struct, the type.
So, say I am at element 1, the root XML element. The next element
is a child element and the element after that is a text element
(valid XML characters).
When the parser iterator goes over the internal representation,
it will for example do something like this:
if (((struct xml_header*)element).type == 3) {
pseudo code: write stream, "<" + ((struct xml_element*)element).name
}
In addition to type==3, type can also be 4 and 5, XML attribute
and XML text. So it looks like casting is necessary; and having
a union in the struct defines will restrict what's being pointed
to the chance of pointing to the wrong type of data is lower.
> For your purposes, this whole discussion has been a distraction.
Well on the one hand it is nice to see some enthusiasm, on the other
hand, it was all a bit hard to follow.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-16 21:32 +0100 |
| Message-ID | <87fv3jezzf.fsf@bsb.me.uk> |
| In reply to | #67525 |
"Morten W. Petersen" <morphex@gmail.com> writes:
> On 13.08.2015 14:18, Ben Bacarisse wrote:
<snip>
>> As for your final design, I don't see any need to convert pointers at
>> all. This all started because you happened to have a void * and you
>> simply put a cast in the wrong place. But you don't either the void *
>> or the cast at all. Maybe there will be, one day, be a need to convert
>> pointers, and I hope you will do that correctly with a cast, but in the
>> meantime I would imagine you can do most of what you want with a
>> discriminated union: place the common elements at the start of a struct
>> and include in those some type indicator. After that, place a union
>> that describes the various different data that are specific to each of
>> your node types.
>
> That's something like the design as it has been. I need to discuss this
> further to be sure I understand what you are saying.
>
> There are a couple of different struct definitions in the project,
> and they all follow the same basic setup with type, next and parent.
>
> When this data is accessed internally for example for writing an
> XML file, they will be iterated over. The code that iterates
> over these struct instances in memory, will know what to do with
> the data, based on the first entry in the struct, the type.
>
> So, say I am at element 1, the root XML element. The next element
> is a child element and the element after that is a text element
> (valid XML characters).
>
> When the parser iterator goes over the internal representation,
> it will for example do something like this:
>
> if (((struct xml_header*)element).type == 3) {
> pseudo code: write stream, "<" + ((struct xml_element*)element).name
> }
(You need -> not . here.)
> In addition to type==3, type can also be 4 and 5, XML attribute
> and XML text.
Hmmm... why it "attribute" a type at the same level as "text" and
comment?
(I can see that in some designs you may want to make attribute lists
look a lot like element lists, but that getting rather fancy in my
opinion. Anyway, it's not really the concern here.)
> So it looks like casting is necessary; and having
> a union in the struct defines will restrict what's being pointed
> to the chance of pointing to the wrong type of data is lower.
I don't see why casting is necessary. You have casts there because the
types are wrong, but that does not mean casts are necessary to the
solution -- it just means you've got the wrong types at the moment.
I'm reluctant to give exact code because the details involve so many
decisions that I've not yet considered that I fear it would simply be
hostage to fortune. What are the structures you've decided on? What
are the common elements, and what are the ones that vary from type to
type? Have you read up on discriminated (AKA tagged) unions?
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-17 12:00 +0200 |
| Message-ID | <mqsbca$a2u$1@speranza.aioe.org> |
| In reply to | #67543 |
On 16.08.2015 22:32, Ben Bacarisse wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
[...]
>> if (((struct xml_header*)element).type == 3) {
>> pseudo code: write stream, "<" + ((struct xml_element*)element).name
>> }
>
> (You need -> not . here.)
OK.
>> In addition to type==3, type can also be 4 and 5, XML attribute
>> and XML text.
>
> Hmmm... why it "attribute" a type at the same level as "text" and
> comment?
Well I thought about the model of the internal representation and how
XML is structured, and that's the best I came up with. I think it
covers everything that could be in an XML file.
>> So it looks like casting is necessary; and having
>> a union in the struct defines will restrict what's being pointed
>> to the chance of pointing to the wrong type of data is lower.
>
> I don't see why casting is necessary. You have casts there because the
> types are wrong, but that does not mean casts are necessary to the
> solution -- it just means you've got the wrong types at the moment.
>
> I'm reluctant to give exact code because the details involve so many
> decisions that I've not yet considered that I fear it would simply be
> hostage to fortune. What are the structures you've decided on? What
> are the common elements, and what are the ones that vary from type to
> type? Have you read up on discriminated (AKA tagged) unions?
I just read up on discriminated structs yes, couldn't google anything
useful about discriminated unions..
Do you know any good documents that explain tagged unions?
What I'm thinking is that things get stored in memory, and its all
bits and bytes. When for example an XML writer function is called
with the root node as an argument, it can follow the pointers from
the root element and find everything.
But unless the root element and its child nodes specify what kind
of struct it is, the code won't know what it is dealing with.
The example of a discriminated struct I saw has the same setup as
I have, a type at the start to tell what kind of struct it is.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-17 15:50 +0100 |
| Message-ID | <87egj2dl4k.fsf@bsb.me.uk> |
| In reply to | #67572 |
"Morten W. Petersen" <morphex@gmail.com> writes:
> On 16.08.2015 22:32, Ben Bacarisse wrote:
>> "Morten W. Petersen" <morphex@gmail.com> writes:
> [...]
>>> if (((struct xml_header*)element).type == 3) {
>>> pseudo code: write stream, "<" + ((struct xml_element*)element).name
>>> }
>>
>> (You need -> not . here.)
>
> OK.
>
>>> In addition to type==3, type can also be 4 and 5, XML attribute
>>> and XML text.
>>
>> Hmmm... why it "attribute" a type at the same level as "text" and
>> comment?
>
> Well I thought about the model of the internal representation and how
> XML is structured, and that's the best I came up with. I think it
> covers everything that could be in an XML file.
All I can say is hmmm... again. I've thought about it too, and attributes
don't feature at the same level as the others.
>>> So it looks like casting is necessary; and having
>>> a union in the struct defines will restrict what's being pointed
>>> to the chance of pointing to the wrong type of data is lower.
>>
>> I don't see why casting is necessary. You have casts there because the
>> types are wrong, but that does not mean casts are necessary to the
>> solution -- it just means you've got the wrong types at the moment.
>>
>> I'm reluctant to give exact code because the details involve so many
>> decisions that I've not yet considered that I fear it would simply be
>> hostage to fortune. What are the structures you've decided on? What
>> are the common elements, and what are the ones that vary from type to
>> type?
I was hoping you'd answer these questions. Ultimately it's code that
matters and I'd have a much better handle on how you want to organise
things if you showed the structures you are currently planning on using.
>> Have you read up on discriminated (AKA tagged) unions?
> I just read up on discriminated structs yes, couldn't google anything
> useful about discriminated unions..
>
> Do you know any good documents that explain tagged unions?
https://en.wikipedia.org/wiki/Tagged_union might help, but it sounds
from what you write below that you've got the basic idea (and in fact
that you are using it already).
> What I'm thinking is that things get stored in memory, and its all
> bits and bytes. When for example an XML writer function is called
> with the root node as an argument, it can follow the pointers from
> the root element and find everything.
>
> But unless the root element and its child nodes specify what kind
> of struct it is, the code won't know what it is dealing with.
>
> The example of a discriminated struct I saw has the same setup as
> I have, a type at the start to tell what kind of struct it is.
It sounds like you are doing it already so I'm a little perplexed by the
cast.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-17 22:28 +0200 |
| Message-ID | <mqtg5n$17e$1@speranza.aioe.org> |
| In reply to | #67600 |
On 17.08.2015 16:50, Ben Bacarisse wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: > >> On 16.08.2015 22:32, Ben Bacarisse wrote: [...] >>> I don't see why casting is necessary. You have casts there because the >>> types are wrong, but that does not mean casts are necessary to the >>> solution -- it just means you've got the wrong types at the moment. >>> >>> I'm reluctant to give exact code because the details involve so many >>> decisions that I've not yet considered that I fear it would simply be >>> hostage to fortune. What are the structures you've decided on? What >>> are the common elements, and what are the ones that vary from type to >>> type? > > I was hoping you'd answer these questions. Ultimately it's code that > matters and I'd have a much better handle on how you want to organise > things if you showed the structures you are currently planning on using. The struct statements are here: https://github.com/morphex/smash_xml/blob/master/decode_xml.c I haven't written anything that makes use of the internal representation yet, but casting & storage is towards the bottom of that file. [...] >> What I'm thinking is that things get stored in memory, and its all >> bits and bytes. When for example an XML writer function is called >> with the root node as an argument, it can follow the pointers from >> the root element and find everything. >> >> But unless the root element and its child nodes specify what kind >> of struct it is, the code won't know what it is dealing with. >> >> The example of a discriminated struct I saw has the same setup as >> I have, a type at the start to tell what kind of struct it is. > > It sounds like you are doing it already so I'm a little perplexed by the > cast. I think there was some talking past each other here so I'll just try out what I've got and get back on this if it doesn't work. And show you the code once it is done so that some feedback can be given for those who want to do that. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-18 01:34 +0100 |
| Message-ID | <87r3n1cu36.fsf@bsb.me.uk> |
| In reply to | #67629 |
"Morten W. Petersen" <morphex@gmail.com> writes: > On 17.08.2015 16:50, Ben Bacarisse wrote: >> "Morten W. Petersen" <morphex@gmail.com> writes: >> >>> On 16.08.2015 22:32, Ben Bacarisse wrote: > [...] >>>> I don't see why casting is necessary. You have casts there because the >>>> types are wrong, but that does not mean casts are necessary to the >>>> solution -- it just means you've got the wrong types at the moment. >>>> >>>> I'm reluctant to give exact code because the details involve so many >>>> decisions that I've not yet considered that I fear it would simply be >>>> hostage to fortune. What are the structures you've decided on? What >>>> are the common elements, and what are the ones that vary from type to >>>> type? >> >> I was hoping you'd answer these questions. Ultimately it's code that >> matters and I'd have a much better handle on how you want to organise >> things if you showed the structures you are currently planning on using. > > The struct statements are here: > > https://github.com/morphex/smash_xml/blob/master/decode_xml.c Yes, I'd seen that before, but there are no unions there and since it sounded as if you were using a tagged union, I had assumed things had changed due to this discussion. > I haven't written anything that makes use of the internal > representation yet, but casting & storage is towards > the bottom of that file. > > [...] >>> What I'm thinking is that things get stored in memory, and its all >>> bits and bytes. When for example an XML writer function is called >>> with the root node as an argument, it can follow the pointers from >>> the root element and find everything. >>> >>> But unless the root element and its child nodes specify what kind >>> of struct it is, the code won't know what it is dealing with. >>> >>> The example of a discriminated struct I saw has the same setup as >>> I have, a type at the start to tell what kind of struct it is. >> >> It sounds like you are doing it already so I'm a little perplexed by the >> cast. > > I think there was some talking past each other here so I'll just > try out what I've got and get back on this if it doesn't work. Yes, I suspect so. You are not using a tagged union, so there will likely be casts all over the place. I'm not going to tell you to use a tagged union, but you should be sure you know what that design would be like before deciding not to use it. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-19 08:40 +0200 |
| Message-ID | <mr18ck$1pt$1@speranza.aioe.org> |
| In reply to | #67664 |
On 18.08.2015 02:34, Ben Bacarisse wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: [...] >> I think there was some talking past each other here so I'll just >> try out what I've got and get back on this if it doesn't work. > > Yes, I suspect so. You are not using a tagged union, so there will > likely be casts all over the place. I'm not going to tell you to use a > tagged union, but you should be sure you know what that design would be > like before deciding not to use it. OK. I think I have a proper understanding of tagged unions now, so I'll give those a go. -Morten
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2015-08-12 13:35 -0700 |
| Message-ID | <6d3d7b54-8cd1-448d-abfa-5acd58cb5fa7@googlegroups.com> |
| In reply to | #67170 |
On Wednesday, August 12, 2015 at 5:39:24 AM UTC-5, Ben Bacarisse wrote: > Unions have two functions. One, to save space by enabling the storage >[...] > > The second use is to re-interpret the representation of one type as if > it were another. This is a much and specialised usage. Indeed this is the /only/ way if you want avoid weird warnings about "strict aliasing" that pointer-punning can produce. -- alias what? just alias
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-12 15:01 -0700 |
| Message-ID | <5223e2d7-1a03-42b9-8dfe-a07460d71ff4@googlegroups.com> |
| In reply to | #67219 |
In the land of the vast union brigade, sat *THE* finest coding tool that's ever made, for bridging data cross the wiley format gaps, it was the envy, oh the envy of the apps. Yet there were those who served only to repress, union's ability to awe and impress, they'd sooner pin e'ry union to the ground, to cater to some old fogies on the outskirts of town. But mighty union was completely undaunted, for it knew all along just what it wanted, and that was to give every developer a hand, in leading them to the coding promised land! Where the rigors of past coding style's dying, being replaced with modern tools that are less trying, those which help keep new developers from crying, whilst also keeping all the new apps safely flying. [doomp doomp dooo] Lo the moral of the story is courageous, you can toil using yer tools for bygone ages, or you can step up and get with the modern program, where the tools have all moved on as code has called them. But you better make your choice soon I'd advise ya, lest ye wind up like the "mighty dinosau-r," for while they once were mighty fearsome towering creatures, today you only find them round about museums. So as you ponder yer ways in coding forward, don't regard past coding styles less than stallward, for while they served might-i-ly during their tenure, but at some point all things get put out to pasture. And as the new architectures roll along, and they sing their sweet victory song, we must remember that their data needs are blooming, enter in the steadfast homeplace of the union. Undaunted all along and filled with patience, for the day it would rise up and take command, displacing former ways with those of el-e-gance, and simplifying code in the devie's hand. ALL HAIL THE MIGHTY UNION! The end. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
Page 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web