Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #63278 > unrolled thread
| Started by | Bartc <bc@freeuk.com> |
|---|---|
| First post | 2015-06-15 14:08 +0100 |
| Last post | 2015-07-14 13:14 -0700 |
| Articles | 20 on this page of 442 — 31 participants |
Back to article view | Back to comp.lang.c
typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-15 14:08 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 14:23 +0100
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-15 09:30 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 18:01 +0100
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-16 09:44 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 18:06 +0100
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 19:22 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 19:33 +0100
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-16 14:53 -0400
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 09:54 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-17 11:04 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-18 11:11 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-18 12:00 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-19 09:50 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 18:02 +0100
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-19 10:25 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 20:10 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 18:11 +0100
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-19 10:40 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 18:58 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-19 11:35 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-19 12:31 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-18 20:47 +0100
Re: typedef forward declaration mark.bluemel@gmail.com - 2015-06-19 03:35 -0700
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 17:23 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 09:46 -0700
Re: typedef forward declaration Barry Schwarz <schwarzb@dqel.com> - 2015-06-17 10:34 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 10:43 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-18 16:00 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-18 08:52 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-19 10:21 +0200
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-19 11:35 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-19 05:34 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 13:45 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-19 06:23 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 15:55 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-19 08:06 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 16:14 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-19 08:41 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 17:19 +0100
Re: typedef forward declaration Richard Damon <Richard@Damon-Family.org> - 2015-06-19 21:02 -0400
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-19 18:57 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 00:59 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-20 17:25 +0200
Re: typedef forward declaration Nathan Wagner <nw@hydaspes.if.org> - 2015-06-21 12:04 +0000
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-21 13:07 -0700
Re: typedef forward declaration Nathan Wagner <nw@hydaspes.if.org> - 2015-06-23 13:08 +0000
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 17:36 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 01:00 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-19 08:40 -0700
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-20 08:54 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 02:06 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-20 10:46 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 03:16 -0700
Re: typedef forward declaration Richard Damon <Richard@Damon-Family.org> - 2015-06-20 09:01 -0400
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-20 15:44 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-20 12:08 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-21 21:02 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-21 21:24 +0100
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-21 22:41 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 00:08 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 05:43 -0700
Re: typedef forward declaration Morris Dovey <mrdovey@iedu.com> - 2015-06-22 08:14 -0500
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 07:13 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 16:28 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 08:47 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 17:25 +0100
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-22 18:23 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 19:11 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 10:50 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 19:23 +0100
Re: typedef forward declaration Robert Wessel <robertwessel2@yahoo.com> - 2015-06-22 14:38 -0500
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-22 10:35 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 11:31 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-22 12:36 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 12:47 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 21:02 +0100
Re: typedef forward declaration Nathan Wagner <nw@hydaspes.if.org> - 2015-06-23 13:04 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 06:13 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-23 15:26 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 07:31 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 07:39 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 14:38 +0100
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-24 09:19 +0000
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-22 13:14 -0700
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-22 20:29 +0000
Re: typedef forward declaration "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-06-23 12:31 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 12:40 -0700
Re: typedef forward declaration crisdunbar@gmail.com - 2015-06-23 12:48 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 13:04 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 21:08 +0100
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 14:05 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-19 06:26 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-19 08:47 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 17:19 +0100
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-20 08:59 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 02:10 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-20 17:34 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 08:42 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 08:50 -0700
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-20 16:59 +0000
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-20 18:40 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-20 12:21 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-20 21:31 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-20 14:07 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 05:20 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-22 13:38 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 05:45 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-22 08:49 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 08:54 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-22 16:54 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 09:02 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-22 21:33 +0100
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-19 10:00 -0700
Re: typedef forward declaration Robert Wessel <robertwessel2@yahoo.com> - 2015-06-19 22:33 -0500
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-20 07:50 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 08:12 -0700
Re: typedef forward declaration gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-20 15:30 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 08:40 -0700
Re: typedef forward declaration Barry Schwarz <schwarzb@dqel.com> - 2015-06-19 10:10 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-19 12:58 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-19 21:30 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-19 13:34 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-19 14:56 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-19 13:45 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-19 16:26 -0700
Re: typedef forward declaration Ian Collins <ian-news@hotmail.com> - 2015-06-20 12:26 +1200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 00:40 -0700
Re: typedef forward declaration Ian Collins <ian-news@hotmail.com> - 2015-06-20 20:05 +1200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 01:17 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-19 17:52 -0700
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-20 01:12 +0000
Re: typedef forward declaration Robert Wessel <robertwessel2@yahoo.com> - 2015-06-19 22:35 -0500
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 00:55 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-20 10:27 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 02:31 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-20 15:45 +0100
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-22 15:13 -0400
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-20 11:56 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 05:36 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-22 17:12 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 09:25 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 17:54 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 10:58 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 19:39 +0100
Re: typedef forward declaration Martin Shobe <martin.shobe@yahoo.com> - 2015-06-22 13:59 -0500
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-23 10:37 +0200
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 11:01 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-07-12 09:02 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-12 09:44 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 19:42 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-12 11:47 -0700
Re: typedef forward declaration Rosario19 <Ros@invalid.invalid> - 2015-07-12 21:21 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-12 13:32 -0700
Re: typedef forward declaration Rosario19 <Ros@invalid.invalid> - 2015-07-13 09:03 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-13 03:13 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 21:53 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-12 14:05 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-12 14:30 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-13 00:52 +0100
Re: typedef forward declaration Richard Damon <Richard@Damon-Family.org> - 2015-07-12 20:57 -0400
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 22:52 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-12 16:56 -0700
Re: typedef forward declaration Ian Collins <ian-news@hotmail.com> - 2015-07-13 13:22 +1200
Re: typedef forward declaration Ian Collins <ian-news@hotmail.com> - 2015-07-13 10:05 +1200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-12 19:04 -0700
Re: typedef forward declaration Ian Collins <ian-news@hotmail.com> - 2015-07-13 20:28 +1200
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-07-13 09:45 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-13 03:01 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-13 11:01 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-13 03:19 -0700
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-13 19:56 +0000
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-07-13 08:27 -0400
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-07-13 10:01 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-07-13 18:38 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-07-13 12:20 -0700
Re: typedef forward declaration "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-14 11:15 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 08:57 -0700
Re: typedef forward declaration luser droog <luser.droog@gmail.com> - 2015-07-13 23:25 -0700
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-07-15 12:59 -0400
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-07-20 17:32 +0200
Re: typedef forward declaration gwowen <gwowen@gmail.com> - 2015-07-13 07:22 -0700
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-07-13 11:58 -0400
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-07-13 10:06 -0700
Re: typedef forward declaration gwowen <gwowen@gmail.com> - 2015-07-15 05:24 -0700
Re: typedef forward declaration Rosario19 <Ros@invalid.invalid> - 2015-07-13 19:49 +0200
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 08:08 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-15 08:32 -0700
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 09:12 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 20:21 -0700
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 09:15 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-22 12:14 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 12:17 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 20:54 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-22 13:16 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 13:59 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 22:36 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-22 14:38 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 06:00 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 14:37 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-23 16:40 +0200
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 16:14 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-23 22:51 +0200
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 22:06 +0100
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-24 00:14 +0000
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 01:17 +0100
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-24 05:18 +0000
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 09:35 +0100
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-24 10:43 +0100
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-24 11:19 -0400
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-14 07:20 -0700
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-14 17:55 +0000
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 20:06 -0700
Re: typedef forward declaration Robert Wessel <robertwessel2@yahoo.com> - 2015-07-15 23:28 -0500
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 22:06 -0700
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 09:42 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-23 09:16 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 09:27 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-24 07:38 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-24 07:55 -0700
Re: typedef forward declaration Robert Wessel <robertwessel2@yahoo.com> - 2015-06-25 21:22 -0500
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-28 10:41 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 03:52 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-23 22:57 +0200
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-24 07:52 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-24 17:09 +0200
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-24 08:43 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-24 08:47 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-24 23:01 +0200
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-24 17:13 -0400
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-24 23:40 +0100
Re: typedef forward declaration Philip Lantz <prl@canterey.us> - 2015-06-24 21:38 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-25 11:23 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-25 11:36 +0100
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-25 11:55 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-25 00:46 +0200
Re: typedef forward declaration Melzzzzz <mel@zzzzz.com> - 2015-06-25 01:47 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 05:53 -0700
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-24 20:24 -0400
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-25 10:00 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 05:51 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-25 14:15 +0100
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-25 07:54 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 08:08 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-25 16:21 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-25 17:46 +0200
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-25 18:16 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-25 19:55 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 11:02 -0700
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-25 18:30 +0000
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-25 12:54 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-26 11:01 +0200
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-25 18:03 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-25 18:27 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-25 10:30 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 10:35 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-25 19:07 +0100
Re: typedef forward declaration Ian Collins <ian-news@hotmail.com> - 2015-06-26 09:43 +1200
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-26 11:26 +0200
Re: typedef forward declaration Ian Collins <ian-news@hotmail.com> - 2015-06-26 09:45 +1200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 14:51 -0700
Re: typedef forward declaration Ian Collins <ian-news@hotmail.com> - 2015-06-26 09:57 +1200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 15:01 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-25 17:24 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 08:30 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-25 16:35 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-25 20:05 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 11:09 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 11:19 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-25 20:04 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-26 11:42 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 05:01 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-26 14:11 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 05:26 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-27 22:01 +0200
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-27 20:46 +0000
Re: typedef forward declaration Robert Wessel <robertwessel2@yahoo.com> - 2015-06-27 16:37 -0500
[OT] was Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-26 14:25 +0200
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 05:31 -0700
Re: [OT] was Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-26 14:18 +0100
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 06:31 -0700
Re: [OT] was Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-26 08:20 -0700
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 08:24 -0700
Re: [OT] was Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-26 10:24 -0700
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 10:30 -0700
Re: [OT] was Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-26 13:40 -0700
Re: [OT] was Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-26 14:09 -0700
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 14:23 -0700
Re: [OT] was Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-26 22:12 -0700
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 03:03 -0700
Re: [OT] was Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-27 13:08 +0100
Re: [OT] was Re: typedef forward declaration gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-27 11:37 +0000
Re: [OT] was Re: typedef forward declaration "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-06-27 13:06 -0700
Re: [OT] was Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-27 07:51 -0700
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 07:55 -0700
Re: [OT] was Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-26 08:59 -0700
Re: [OT] was Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-27 12:13 +0000
Re: [OT] was Re: typedef forward declaration Geoff <geoff@invalid.invalid> - 2015-06-27 08:25 -0700
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 08:43 -0700
Re: [OT] was Re: typedef forward declaration Geoff <geoff@invalid.invalid> - 2015-06-27 08:55 -0700
Re: [OT] was Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 09:10 -0700
Re: [OT] was Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-27 11:25 -0700
Re: [OT] was Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-26 08:56 -0700
Re: [OT] was Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-27 22:05 +0200
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-25 12:46 -0400
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-25 10:00 -0700
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-28 10:58 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 04:03 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-28 12:43 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 06:05 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 06:33 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-28 18:28 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 10:42 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-28 18:17 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 10:32 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-28 20:53 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 17:53 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-29 12:10 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-29 04:59 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-29 14:21 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-29 06:40 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-29 17:38 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-29 10:44 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-29 22:10 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-29 15:09 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-28 11:43 -0700
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-28 10:43 +0000
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-29 08:50 +0200
Re: typedef forward declaration Richard Damon <Richard@Damon-Family.org> - 2015-06-27 12:32 -0400
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-23 13:17 -0400
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-23 13:20 -0400
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 10:25 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-24 09:51 +0200
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-24 12:05 -0400
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-24 10:43 -0700
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-27 12:18 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 05:26 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-27 14:11 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 06:38 -0700
Re: typedef forward declaration gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-27 13:55 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 07:15 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 07:34 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-27 15:56 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 08:13 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-27 21:35 +0100
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-27 18:58 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-27 12:35 -0700
Re: typedef forward declaration Richard Damon <Richard@Damon-Family.org> - 2015-06-27 13:21 -0400
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-27 11:34 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-27 12:07 -0700
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-28 11:02 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-28 06:12 -0700
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-07-03 17:25 +0000
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-24 11:51 -0700
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-24 15:17 -0400
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-24 12:31 -0400
Re: typedef forward declaration Rosario19 <Ros@invalid.invalid> - 2015-06-23 21:11 +0200
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 20:22 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 12:39 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-23 01:51 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-22 19:55 -0700
Re: typedef forward declaration "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-06-22 22:51 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 02:57 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 11:08 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-23 00:00 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 09:40 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-23 11:03 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 06:06 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 14:45 +0100
Re: typedef forward declaration Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 11:33 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-23 15:15 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 15:23 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-23 07:23 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 15:50 +0100
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-23 16:51 +0200
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-22 10:53 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 19:26 +0100
Re: typedef forward declaration Nathan Wagner <nw@hydaspes.if.org> - 2015-06-23 13:37 +0000
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-23 07:53 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-23 17:04 +0200
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 16:24 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-23 08:44 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-23 09:01 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-23 15:22 -0700
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-24 07:56 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-24 08:00 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-24 08:26 -0700
Re: typedef forward declaration David Brown <david.brown@hesbynett.no> - 2015-06-23 23:06 +0200
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-23 22:20 +0100
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-22 21:18 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-22 14:21 -0700
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-20 10:30 +0100
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-20 09:08 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-20 02:14 -0700
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-20 09:08 +0000
Re: typedef forward declaration David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 10:52 -0700
Re: typedef forward declaration Dr Nick <nospam-4@temporary-address.org.uk> - 2015-06-17 19:52 +0100
Re: typedef forward declaration James Kuyper <jameskuyper@verizon.net> - 2015-06-17 15:32 -0400
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 19:58 +0100
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-15 20:02 +0100
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-15 17:40 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 17:57 +0100
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-15 18:37 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 18:44 +0100
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-15 19:39 +0100
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 19:45 +0100
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-15 20:31 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-15 13:29 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-15 19:09 -0700
Re: typedef forward declaration Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-06-15 18:10 -0600
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-16 00:30 +0000
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-15 17:41 -0700
Re: typedef forward declaration Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-06-15 20:58 -0600
Re: typedef forward declaration Bartc <bc@freeuk.com> - 2015-06-16 09:43 +0100
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 12:27 +0100
Re: typedef forward declaration Philip Lantz <prl@canterey.us> - 2015-06-16 09:20 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 19:18 +0100
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-06-15 10:13 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 18:24 +0100
Re: typedef forward declaration raltbos@xs4all.nl (Richard Bos) - 2015-06-18 21:47 +0000
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-15 06:24 -0700
Re: typedef forward declaration Lőrinczy Zsigmond <nospam@for.me> - 2015-06-15 21:20 +0200
Re: typedef forward declaration luser droog <luser.droog@gmail.com> - 2015-06-15 18:08 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 09:18 -0700
Re: typedef forward declaration Rosario19 <Ros@invalid.invalid> - 2015-06-26 18:46 +0200
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-26 10:28 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-13 05:34 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-13 21:40 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-14 09:27 -0700
Re: typedef forward declaration Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-14 20:11 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-14 12:20 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-14 12:50 -0700
Re: typedef forward declaration Philip Lantz <prl@canterey.us> - 2015-07-14 16:56 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-14 17:16 -0700
Re: typedef forward declaration Richard Heathfield <rjh@cpax.org.uk> - 2015-07-15 01:28 +0100
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-15 04:38 -0700
Re: typedef forward declaration Keith Thompson <kst-u@mib.org> - 2015-07-15 08:54 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-15 08:57 -0700
Re: typedef forward declaration Philip Lantz <prl@canterey.us> - 2015-07-14 17:03 -0700
Re: typedef forward declaration glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-15 05:10 +0000
Re: typedef forward declaration Philip Lantz <prl@canterey.us> - 2015-07-14 22:59 -0700
Re: typedef forward declaration "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-14 13:14 -0700
Page 7 of 23 — ← Prev page 1 … 5 6 [7] 8 9 … 23 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-19 12:58 -0700 |
| Message-ID | <81c5421f-207c-4527-99d5-b27041bd3499@googlegroups.com> |
| In reply to | #63628 |
On Friday, June 19, 2015 at 1:10:38 PM UTC-4, Barry Schwarz wrote: > On Fri, 19 Jun 2015 05:34:47 -0700 (PDT), "Rick C. Hodgin" > <rick.c.hodgin@gmail.com> wrote: > > >I don't understand why a standard would speak to such architectures > >in the year 2015. > > Is your experience so varied that your understanding encompasses > everything anyone would ever want to do with the C language? Negatory. No, sir. No how. No way. No chance. Not even close. > There is > a reason why so many different organizations representing a variety of > viewpoints participate in the efforts of the committee developing the > standard. With the complexity existing in C, it should've split into two groups: (1) the before, and (2) the after camps. The before camp keeps all the legacy baggage in tow which allows the standard to support the widest array of architectures. The after camp simplifies the core standard and removes support for things which are not in various mainstream hardware architectures (Intel and ARM as two mainstream examples). It's just my opinion. I could be wrong. :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-19 21:30 +0100 |
| Message-ID | <mm1u2a$djj$1@dont-email.me> |
| In reply to | #63639 |
On 19/06/2015 20:58, Rick C. Hodgin wrote: > On Friday, June 19, 2015 at 1:10:38 PM UTC-4, Barry Schwarz wrote: >> On Fri, 19 Jun 2015 05:34:47 -0700 (PDT), "Rick C. Hodgin" >> <rick.c.hodgin@gmail.com> wrote: >> >>> I don't understand why a standard would speak to such architectures >>> in the year 2015. >> >> Is your experience so varied that your understanding encompasses >> everything anyone would ever want to do with the C language? > > Negatory. No, sir. No how. No way. No chance. Not even close. > >> There is >> a reason why so many different organizations representing a variety of >> viewpoints participate in the efforts of the committee developing the >> standard. > > With the complexity existing in C, it should've split into two groups: > (1) the before, and (2) the after camps. The before camp keeps all the > legacy baggage in tow which allows the standard to support the widest > array of architectures. The after camp simplifies the core standard and > removes support for things which are not in various mainstream hardware > architectures (Intel and ARM as two mainstream examples). > > It's just my opinion. I could be wrong. :-) I'm sure I've proposed something along the same lines before. Leave the current language as it is, with all its baggage and vagaries regarding data types and widths, but also have a new streamlined one which is designed to work only on common 32- and 64-bit byte-addressed architectures. Finally, you can assume that a CHAR_BIT is 8! In fact you will no longer need CHAR_BIT at all. While int is 32-bits and long is 64-bits - always. This has in fact been done, but they have also completely revised the languages (as C# and Java for example). But what I've learned from this newsgroup is that there is little interest in any such idea; no one wants to make a significant change like that yet leave most of the rest of the language alone. Or maybe they will think the new C will become too easy to program. Or have too few quirks so there will be nothing to discuss! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-19 13:34 -0700 |
| Message-ID | <d2637a4e-2a74-4355-a201-a7aef9bfd47b@googlegroups.com> |
| In reply to | #63640 |
On Friday, June 19, 2015 at 4:30:25 PM UTC-4, Bart wrote: > On 19/06/2015 20:58, Rick C. Hodgin wrote: > > On Friday, June 19, 2015 at 1:10:38 PM UTC-4, Barry Schwarz wrote: > >> On Fri, 19 Jun 2015 05:34:47 -0700 (PDT), "Rick C. Hodgin" > >> <rick.c.hodgin@gmail.com> wrote: > >> > >>> I don't understand why a standard would speak to such architectures > >>> in the year 2015. > >> > >> Is your experience so varied that your understanding encompasses > >> everything anyone would ever want to do with the C language? > > > > Negatory. No, sir. No how. No way. No chance. Not even close. > > > >> There is > >> a reason why so many different organizations representing a variety of > >> viewpoints participate in the efforts of the committee developing the > >> standard. > > > > With the complexity existing in C, it should've split into two groups: > > (1) the before, and (2) the after camps. The before camp keeps all the > > legacy baggage in tow which allows the standard to support the widest > > array of architectures. The after camp simplifies the core standard and > > removes support for things which are not in various mainstream hardware > > architectures (Intel and ARM as two mainstream examples). > > > > It's just my opinion. I could be wrong. :-) > > I'm sure I've proposed something along the same lines before. > > Leave the current language as it is, with all its baggage and vagaries > regarding data types and widths, but also have a new streamlined one > which is designed to work only on common 32- and 64-bit byte-addressed > architectures. > > Finally, you can assume that a CHAR_BIT is 8! In fact you will no longer > need CHAR_BIT at all. While int is 32-bits and long is 64-bits - always. > > This has in fact been done, but they have also completely revised the > languages (as C# and Java for example). > > But what I've learned from this newsgroup is that there is little > interest in any such idea; no one wants to make a significant change > like that yet leave most of the rest of the language alone. Or maybe > they will think the new C will become too easy to program. Or have too > few quirks so there will be nothing to discuss! > > -- > Bartc Agreed. It's why I'm working on RDC. I'm bringing in just enough C++ to make C programming easier, but no more, and I'm relaxing several constraints in C, and tightening up a few others (casting mostly). We'll see. If I ever get it done, it could be a total flop. :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-19 14:56 -0700 |
| Message-ID | <lnmvzvgy51.fsf@nuthaus.mib.org> |
| In reply to | #63640 |
Bartc <bc@freeuk.com> writes:
[...]
> I'm sure I've proposed something along the same lines before.
>
> Leave the current language as it is, with all its baggage and vagaries
> regarding data types and widths, but also have a new streamlined one
> which is designed to work only on common 32- and 64-bit byte-addressed
> architectures.
>
> Finally, you can assume that a CHAR_BIT is 8! In fact you will no longer
> need CHAR_BIT at all. While int is 32-bits and long is 64-bits - always.
POSIX requires CHAR_BIT==8, and int and long to be at least 32 bits
(not *quite* what you're asking for, but close).
But what's stopping you from making those assumptions already?
Today, if you write code that relies on those assumptions, it will
fail on systems that conform to the C standard but do not meet
your assumptions.
With your hypothetical standard, your code will fail on exactly
those same systems. The only differences is that those systems
wouldn't conform to your hypothetical standard.
If you don't want to write code that's portable to all conforming ISO C
implementations, then don't. You might consider adding #error
directives like:
#if CHAR_BIT != 8
#error "Kaboom"
#endif
but that's up to you.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-19 13:45 -0700 |
| Message-ID | <lnr3p7h1g7.fsf@nuthaus.mib.org> |
| In reply to | #63639 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Friday, June 19, 2015 at 1:10:38 PM UTC-4, Barry Schwarz wrote:
>> On Fri, 19 Jun 2015 05:34:47 -0700 (PDT), "Rick C. Hodgin"
>> <rick.c.hodgin@gmail.com> wrote:
>>
>> >I don't understand why a standard would speak to such architectures
>> >in the year 2015.
>>
>> Is your experience so varied that your understanding encompasses
>> everything anyone would ever want to do with the C language?
>
> Negatory. No, sir. No how. No way. No chance. Not even close.
>
>> There is
>> a reason why so many different organizations representing a variety of
>> viewpoints participate in the efforts of the committee developing the
>> standard.
>
> With the complexity existing in C, it should've split into two groups:
> (1) the before, and (2) the after camps. The before camp keeps all the
> legacy baggage in tow which allows the standard to support the widest
> array of architectures. The after camp simplifies the core standard and
> removes support for things which are not in various mainstream hardware
> architectures (Intel and ARM as two mainstream examples).
>
> It's just my opinion. I could be wrong. :-)
You've said that the "after" version of C should require all pointer
types to be the same size.
Exactly what advantage do you derive from such a requirement, and how
does the lack of such a guarantee inconvenience you?
You've also said it should assume a fixed number of CPU registers.
Again, exactly what advantage do you derive from such a requirement?
Do you have concrete examples?
Personally, most of the C code I write should work correctly regardless
of how big a pointer is, or whether different pointer types have the
same size or not -- and the number of CPU registers is completely
irrelevant, a concern for the code generation phase of the compiler, not
for me.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-19 16:26 -0700 |
| Message-ID | <150ec33c-11ee-4738-953d-821aee6b5032@googlegroups.com> |
| In reply to | #63642 |
On Friday, June 19, 2015 at 4:45:36 PM UTC-4, Keith Thompson wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > With the complexity existing in C, it should've split into two groups: > > (1) the before, and (2) the after camps. The before camp keeps all the > > legacy baggage in tow which allows the standard to support the widest > > array of architectures. The after camp simplifies the core standard and > > removes support for things which are not in various mainstream hardware > > architectures (Intel and ARM as two mainstream examples). > > > > It's just my opinion. I could be wrong. :-) > > You've said that the "after" version of C should require all pointer > types to be the same size. > > Exactly what advantage do you derive from such a requirement, For me? Nothing. My compilers already guarantee that. :-) But in general, it would allow me (and others) to write code to the standard without jumping through hoops to get there. It would be automatic. > and how > does the lack of such a guarantee inconvenience you? It doesn't because I don't worry about writing to the standard because it's almost impossible to write to the standard without going far away from what's necessary. > You've also said it should assume a fixed number of CPU registers. It doesn't have to be a fixed number (such as 16), but rather that type of general design. > Again, exactly what advantage do you derive from such a requirement? > Do you have concrete examples? It would allow code written in C to always work on that target virtual machine, one that could be supported with a thin framework no matter the architecture, and without recompiling. For those tasks which don't really have to run at CPU speed, it would be nice to write the code once and have it work everywhere. And if you needed it to run on the actual hardware directly, it could be ported. > Personally, most of the C code I write should work correctly regardless > of how big a pointer is, or whether different pointer types have the > same size or not -- and the number of CPU registers is completely > irrelevant, a concern for the code generation phase of the compiler, > not for me. Excellent! Maybe someday, after years of practice, effort, and study, we'll get to the point where we all know enough about writing portable code that we too can do it on almost everything, and without giving it a second thought. I wonder what other things we could've done with that time invested in learning every nuance of C to be able to code like that, rather than just coding for a simpler standard at the sacrifice of a little speed and performance, but with 100% binary portability across hardware? We may never know. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-06-20 12:26 +1200 |
| Message-ID | <cujq9kF43fuU2@mid.individual.net> |
| In reply to | #63645 |
Rick C. Hodgin wrote: > > I wonder what other things we could've done with that time invested in > learning every nuance of C to be able to code like that, rather than > just coding for a simpler standard at the sacrifice of a little speed > and performance, but with 100% binary portability across hardware? We > may never know. You do realise that more C gets written for 8, 16 and small 32 bit CPUs than anything else, don't you? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-20 00:40 -0700 |
| Message-ID | <1fd69beb-8082-404b-93f0-fcbbef05520f@googlegroups.com> |
| In reply to | #63647 |
On Friday, June 19, 2015 at 8:26:38 PM UTC-4, Ian Collins wrote: > Rick C. Hodgin wrote: > > > > I wonder what other things we could've done with that time invested in > > learning every nuance of C to be able to code like that, rather than > > just coding for a simpler standard at the sacrifice of a little speed > > and performance, but with 100% binary portability across hardware? We > > may never know. > > You do realise that more C gets written for 8, 16 and small 32 bit CPUs > than anything else, don't you? I've heard that before. I've used C compilers on tiny microcontrollers that had less than 1 KB of memory. I always thought that was odd. :-) To be clear, the tiny virtual machine target I'm talking about would be for larger machines. One would write the code, debug it, and it would then always run moving forward provided the virtual machine was working properly. It wouldn't need to be re-written every time GCC released a new version, or a new version of some OS came out with some changes. Just one re-write of the virtual machine, and everything else always works using the same code base as before. As I see it with today's amazingly fast computers, it is of far greater benefit to spend little time on periodic maintenance when the software is otherwise debugged and working, and more time working on new code, or in refactoring old libraries to bring together something that is of greater benefit to people (developers, and then also regular users because the developers benefit first). Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-06-20 20:05 +1200 |
| Message-ID | <cukl5rF43fuU4@mid.individual.net> |
| In reply to | #63661 |
Rick C. Hodgin wrote: > On Friday, June 19, 2015 at 8:26:38 PM UTC-4, Ian Collins wrote: >> Rick C. Hodgin wrote: >>> >>> I wonder what other things we could've done with that time invested in >>> learning every nuance of C to be able to code like that, rather than >>> just coding for a simpler standard at the sacrifice of a little speed >>> and performance, but with 100% binary portability across hardware? We >>> may never know. >> >> You do realise that more C gets written for 8, 16 and small 32 bit CPUs >> than anything else, don't you? > > I've heard that before. I've used C compilers on tiny microcontrollers > that had less than 1 KB of memory. I always thought that was odd. :-) > > To be clear, the tiny virtual machine target I'm talking about would be > for larger machines. One would write the code, debug it, and it would > then always run moving forward provided the virtual machine was working > properly. Ah, Java... -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-20 01:17 -0700 |
| Message-ID | <bc74f9b7-dd0b-4464-97e8-7331e0721eca@googlegroups.com> |
| In reply to | #63665 |
On Saturday, June 20, 2015 at 4:05:24 AM UTC-4, Ian Collins wrote: > Rick C. Hodgin wrote: > > On Friday, June 19, 2015 at 8:26:38 PM UTC-4, Ian Collins wrote: > >> Rick C. Hodgin wrote: > >>> > >>> I wonder what other things we could've done with that time invested in > >>> learning every nuance of C to be able to code like that, rather than > >>> just coding for a simpler standard at the sacrifice of a little speed > >>> and performance, but with 100% binary portability across hardware? We > >>> may never know. > >> > >> You do realise that more C gets written for 8, 16 and small 32 bit CPUs > >> than anything else, don't you? > > > > I've heard that before. I've used C compilers on tiny microcontrollers > > that had less than 1 KB of memory. I always thought that was odd. :-) > > > > To be clear, the tiny virtual machine target I'm talking about would be > > for larger machines. One would write the code, debug it, and it would > > then always run moving forward provided the virtual machine was working > > properly. > > Ah, Java... Not quite. The Java JVM is huge and complex. I'm envisioning a runtime that is 1 Megabyte, with plugin modules available for various library support, all written in the C Language VM. It would be nice for C to introduce the basic class and its related syntax for easier member navigation (this->that->other()), and operator abilities. Much beyond that and people could go to C++. But in my opinion, C should have these two things because they greatly simplify source code for human beings. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-19 17:52 -0700 |
| Message-ID | <lnioajgq0h.fsf@nuthaus.mib.org> |
| In reply to | #63645 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Friday, June 19, 2015 at 4:45:36 PM UTC-4, Keith Thompson wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> > With the complexity existing in C, it should've split into two groups:
>> > (1) the before, and (2) the after camps. The before camp keeps all the
>> > legacy baggage in tow which allows the standard to support the widest
>> > array of architectures. The after camp simplifies the core standard and
>> > removes support for things which are not in various mainstream hardware
>> > architectures (Intel and ARM as two mainstream examples).
>> >
>> > It's just my opinion. I could be wrong. :-)
>>
>> You've said that the "after" version of C should require all pointer
>> types to be the same size.
>>
>> Exactly what advantage do you derive from such a requirement,
>
> For me? Nothing. My compilers already guarantee that. :-) But in
> general, it would allow me (and others) to write code to the
> standard without jumping through hoops to get there. It would be
> automatic.
>
>> and how
>> does the lack of such a guarantee inconvenience you?
>
> It doesn't because I don't worry about writing to the standard
> because it's almost impossible to write to the standard without
> going far away from what's necessary.
Perhaps my question was unclear, because you really haven't answered the
question I intended to ask.
What I'm looking for is a concrete example of C code that actually
depends on the size of a pointer, or on pointers of different types
being the same size, or on a CPU design that uses some fixed number of
registers.
I find the latter particularly confusing. Off the top of my head, I
wouldn't even know how to write C code that *cares* how many registers
there are, or if there are any registers at all, unless I use inline
assembly code. (I don't use the "register" keyword, and even if I did
it's not sensitive to the number of CPU registers.) And if I care about
the size of a pointer, I use "sizeof".
[...]
>> Personally, most of the C code I write should work correctly regardless
>> of how big a pointer is, or whether different pointer types have the
>> same size or not -- and the number of CPU registers is completely
>> irrelevant, a concern for the code generation phase of the compiler,
>> not for me.
>
> Excellent! Maybe someday, after years of practice, effort, and study,
> we'll get to the point where we all know enough about writing portable
> code that we too can do it on almost everything, and without giving it
> a second thought.
I don't want to make writing portable code easier than it is, but
for the most part it just requires ignorance (real or pretended)
of any system-specific characteristics.
I might happen to know that pointers are 8 bytes on the particular
machine I'm using, but knowing that is rarely useful, and if I just
ignore that fact when I'm writing code, that code is more likely
to work on machines with 4-byte pointers.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-06-20 01:12 +0000 |
| Message-ID | <mm2el0$e48$1@speranza.aioe.org> |
| In reply to | #63648 |
Keith Thompson <kst-u@mib.org> wrote: (snip) > Perhaps my question was unclear, because you really haven't answered the > question I intended to ask. > What I'm looking for is a concrete example of C code that actually > depends on the size of a pointer, or on pointers of different types > being the same size, or on a CPU design that uses some fixed number of > registers. Not exactly the question you asked, but there are programs that use large finite state machines to do DNA sequence comparison. They run on large data sets, so speed is important, and also memory usage. The favorite trick is to store the match bit as the low order bit of a pointer. One a byte addressed machine, it is always zero. One word addressed Cray machines, that didn't work, so they switched to the high bit. The inner loop is very small, fetching a pointer and small index, using a pointer, then checking the appropriate bit for a match. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-06-19 22:35 -0500 |
| Message-ID | <npn9oa91i6v3vheloo6k43geqlv3u59mh1@4ax.com> |
| In reply to | #63650 |
On Sat, 20 Jun 2015 01:12:00 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >Keith Thompson <kst-u@mib.org> wrote: > >(snip) >> Perhaps my question was unclear, because you really haven't answered the >> question I intended to ask. > >> What I'm looking for is a concrete example of C code that actually >> depends on the size of a pointer, or on pointers of different types >> being the same size, or on a CPU design that uses some fixed number of >> registers. > >Not exactly the question you asked, but there are programs that use >large finite state machines to do DNA sequence comparison. They run >on large data sets, so speed is important, and also memory usage. > >The favorite trick is to store the match bit as the low order bit >of a pointer. One a byte addressed machine, it is always zero. > >One word addressed Cray machines, that didn't work, so they switched >to the high bit. The inner loop is very small, fetching a pointer >and small index, using a pointer, then checking the appropriate >bit for a match. Although that's fundamentally non-portable.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-20 00:55 -0700 |
| Message-ID | <50a26f90-1855-4d5e-a805-32410724a9f2@googlegroups.com> |
| In reply to | #63648 |
On Friday, June 19, 2015 at 8:52:39 PM UTC-4, Keith Thompson wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > Perhaps my question was unclear, because you really haven't answered the > question I intended to ask. > > What I'm looking for is a concrete example of C code that actually > depends on the size of a pointer, or on pointers of different types > being the same size, or on a CPU design that uses some fixed number of > registers. I don't have a concrete example. I can't even think of one to contrive. However, my point is that if I want to adhere to the standard, then I'd have to consider such things. It's an absolute waste of time and resources to do so because the only machines that have varying pointer sizes are those machines with varying pointer sizes. And to date, apart from the early DOS segmented memory model days with near and far pointers, I've never seen one. Now, I don't have comprehensive experience on a vast array of machines ... but I have done software development for all of my adult life, and I do have yet to run in to a case where I use one in desktop machines, and mobile devices. This does not include the variations in a 32-bit or 64-bit compile, nor some specifics to the hardware where I have coded in assembly to allow segment overrides in assembly, or setup for low-level OS functions where its pointers are larger. > I find the latter particularly confusing. Off the top of my head, I > wouldn't even know how to write C code that *cares* how many registers > there are, or if there are any registers at all, unless I use inline > assembly code. (I don't use the "register" keyword, and even if I did > it's not sensitive to the number of CPU registers.) And if I care about > the size of a pointer, I use "sizeof". The register count is for the virtual machine I was talking about. It's a compiler consideration, not a developer consideration. The C language should provide a virtual machine which allows developers to target that machine for coding, debugging, and execution. It should be a feature provided for by the language maintainers, and in that way we all have a particular base from which we can proceed. Inside that VM we have a known set of operational abilities. They always work. Beyond that, we have specifics which run natively on the various and disparate target architectures. A person writing code for the C language's VM would be able to write their code one time, and then port anywhere with the same binary. It would not require recompiles, or tweaking this or that to ensure that on this OS or under this compiler it does X, Y, or Z, or doesn't do them. Instead, it would be "the unified C language," which operates on its baseline target machine. Then everything added by compiler authors beyond that would be extensions which are added because a particular CPU needs it, for example. > [...] > > >> Personally, most of the C code I write should work correctly regardless > >> of how big a pointer is, or whether different pointer types have the > >> same size or not -- and the number of CPU registers is completely > >> irrelevant, a concern for the code generation phase of the compiler, > >> not for me. > > > > Excellent! Maybe someday, after years of practice, effort, and study, > > we'll get to the point where we all know enough about writing portable > > code that we too can do it on almost everything, and without giving it > > a second thought. > > I don't want to make writing portable code easier than it is, but > for the most part it just requires ignorance (real or pretended) > of any system-specific characteristics. > > I might happen to know that pointers are 8 bytes on the particular > machine I'm using, but knowing that is rarely useful, and if I just > ignore that fact when I'm writing code, that code is more likely > to work on machines with 4-byte pointers. I have written in C since around 1989. I have never been able to write code of any significance (more than a few hundred lines) which has compiled in Windows and on another OS the first time. It always has required me tweaking something. On this machine I use this function to convert an unsigned long to a string, and on this other machine I use this one, etc. It's a hassle every single time to this day in 2015. It would be nice to have a "C Language" which is universal. No quirks. No oddities. And I think targeting that C Language Virtual Machine would do the trick. That's all. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-20 10:27 +0100 |
| Message-ID | <87y4jen308.fsf@bsb.me.uk> |
| In reply to | #63662 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Friday, June 19, 2015 at 8:52:39 PM UTC-4, Keith Thompson wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> Perhaps my question was unclear, because you really haven't answered the >> question I intended to ask. >> >> What I'm looking for is a concrete example of C code that actually >> depends on the size of a pointer, or on pointers of different types >> being the same size, or on a CPU design that uses some fixed number of >> registers. > > I don't have a concrete example. I can't even think of one to > contrive. That's odd because you claim to encounter the problem time and time again: <snip> > I have written in C since around 1989. I have never been able to write > code of any significance (more than a few hundred lines) which has > compiled in Windows and on another OS the first time. It always has > required me tweaking something. On this machine I use this function > to convert an unsigned long to a string, and on this other machine I > use this one, etc. It's a hassle every single time to this day in > 2015. So why can't your show this function you "always" had to tweak, or some of this code that won't compiler on another machine? It's a constant hassle, yet you can't come up with a single example to demonstrate the advantage of what you are proposing? For the moment, I'll simply call that extraordinary. > It would be nice to have a "C Language" which is universal. Not at the price Java had to pay, and you are not being clear enough to know what your cut price portable C is suppose to be like. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-20 02:31 -0700 |
| Message-ID | <32ed1c07-6216-49a4-9064-0ad8d8cdfb00@googlegroups.com> |
| In reply to | #63677 |
On Saturday, June 20, 2015 at 5:27:43 AM UTC-4, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > > On Friday, June 19, 2015 at 8:52:39 PM UTC-4, Keith Thompson wrote: > >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > >> Perhaps my question was unclear, because you really haven't answered the > >> question I intended to ask. > >> > >> What I'm looking for is a concrete example of C code that actually > >> depends on the size of a pointer, or on pointers of different types > >> being the same size, or on a CPU design that uses some fixed number of > >> registers. > > > > I don't have a concrete example. I can't even think of one to > > contrive. > > That's odd because you claim to encounter the problem time and time > again: Where do I claim that? > <snip> > > I have written in C since around 1989. I have never been able to write > > code of any significance (more than a few hundred lines) which has > > compiled in Windows and on another OS the first time. It always has > > required me tweaking something. On this machine I use this function > > to convert an unsigned long to a string, and on this other machine I > > use this one, etc. It's a hassle every single time to this day in > > 2015. > > So why can't your show this function you "always" had to tweak, or some > of this code that won't compiler on another machine? It's a constant > hassle, yet you can't come up with a single example to demonstrate the > advantage of what you are proposing? For the moment, I'll simply call > that extraordinary. It's not a single function that I'm talking about here in this part. It's the variation between machines, compilers, flavors of C, where the function is called _myfuncabc() on one machine, and myabcfunc() on another, and so on. > > It would be nice to have a "C Language" which is universal. > > Not at the price Java had to pay, and you are not being clear enough to > know what your cut price portable C is suppose to be like. I haven't tried to be. It's just an executable that runs on any various machine. It contains an API to access required OS services, and the C libs wrap there for anything OS-related, and wraps to its own libs for anything C-specific. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-20 15:45 +0100 |
| Message-ID | <87h9q2mob5.fsf@bsb.me.uk> |
| In reply to | #63679 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Saturday, June 20, 2015 at 5:27:43 AM UTC-4, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> >> > On Friday, June 19, 2015 at 8:52:39 PM UTC-4, Keith Thompson wrote: >> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> >> Perhaps my question was unclear, because you really haven't answered the >> >> question I intended to ask. >> >> >> >> What I'm looking for is a concrete example of C code that actually >> >> depends on the size of a pointer, or on pointers of different types >> >> being the same size, or on a CPU design that uses some fixed number of >> >> registers. >> > >> > I don't have a concrete example. I can't even think of one to >> > contrive. >> >> That's odd because you claim to encounter the problem time and time >> again: > > Where do I claim that? Look at the colon. It means "here". I left the quote intact: >> <snip> >> > I have written in C since around 1989. I have never been able to write >> > code of any significance (more than a few hundred lines) which has >> > compiled in Windows and on another OS the first time. It always has >> > required me tweaking something. On this machine I use this function >> > to convert an unsigned long to a string, and on this other machine I >> > use this one, etc. It's a hassle every single time to this day in >> > 2015. >> >> So why can't your show this function you "always" had to tweak, or some >> of this code that won't compiler on another machine? It's a constant >> hassle, yet you can't come up with a single example to demonstrate the >> advantage of what you are proposing? For the moment, I'll simply call >> that extraordinary. > > It's not a single function that I'm talking about here in this part. Now you are being evasive. The quoted paragraph ether means you encounter the sort of problem you'd like to have fixed time and time again, you you simply wrote it to confuse people into thinking you were saying something pertinent. > It's the variation between machines, compilers, flavors of C, where > the function is called _myfuncabc() on one machine, and myabcfunc() > on another, and so on. Post an example and stop being all coy about it -- an actual example (should be easy, after all it's a "constant hassle") of something you've been bothered by that you want fixed in a "better" language standard. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-22 15:13 -0400 |
| Message-ID | <mm9mls$rr8$1@dont-email.me> |
| In reply to | #63686 |
On 06/20/2015 10:45 AM, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > >> On Saturday, June 20, 2015 at 5:27:43 AM UTC-4, Ben Bacarisse wrote: >>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >>> >>>> On Friday, June 19, 2015 at 8:52:39 PM UTC-4, Keith Thompson wrote: >>>>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >>>>> Perhaps my question was unclear, because you really haven't answered the >>>>> question I intended to ask. >>>>> >>>>> What I'm looking for is a concrete example of C code that actually >>>>> depends on the size of a pointer, or on pointers of different types >>>>> being the same size, or on a CPU design that uses some fixed number of >>>>> registers. >>>> >>>> I don't have a concrete example. I can't even think of one to >>>> contrive. >>> >>> That's odd because you claim to encounter the problem time and time >>> again: >> >> Where do I claim that? > > Look at the colon. It means "here". I left the quote intact: > >>> <snip> >>>> I have written in C since around 1989. I have never been able to write >>>> code of any significance (more than a few hundred lines) which has >>>> compiled in Windows and on another OS the first time. It always has >>>> required me tweaking something. On this machine I use this function >>>> to convert an unsigned long to a string, and on this other machine I >>>> use this one, etc. It's a hassle every single time to this day in >>>> 2015. While he wrote that paragraph in response to a comment by Keith about variations in pointer sizes, that paragraph does not appear to be about pointer size variations, only about portability issues in general. While he is complaining about frequently running into portability problems with C, he is NOT claiming that he frequently runs into the particular type Keith asked him to provide a concrete example of. He's worried about that type of problem only because he doesn't understand how C pointer conversions work, not because he thinks he's actually run into such problems. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-20 11:56 -0700 |
| Message-ID | <ln4mm2gqex.fsf@nuthaus.mib.org> |
| In reply to | #63662 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Friday, June 19, 2015 at 8:52:39 PM UTC-4, Keith Thompson wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> Perhaps my question was unclear, because you really haven't answered the
>> question I intended to ask.
>>
>> What I'm looking for is a concrete example of C code that actually
>> depends on the size of a pointer, or on pointers of different types
>> being the same size, or on a CPU design that uses some fixed number of
>> registers.
>
> I don't have a concrete example. I can't even think of one to contrive.
Then why do you care?
> However, my point is that if I want to adhere to the standard, then I'd
> have to consider such things.
Apparently you *don't* have to consider such things.
When I write code that uses pointers, I declare objects of pointer
types, functions that take arguments and return results of pointer
types, define structs with pointer members, and so on. The only way
such code would depend on the size of a pointer type, or whether
different pointers have the same size, would be if I deliberately
went out of my way to do so.
You seem to have an assumption in the back of your mind that all
pointers are the same size, and that that size is either 32 or
64 bits, but if you don't make use of that assumption *it doesn't
matter*.
Without a single concrete example where it matters, your argument
is meaningless, and certainly not worth imposing restrictions
on C implementations for a convenience that you don't even take
advantage of.
> It's an absolute waste of time and
> resources to do so because the only machines that have varying pointer
> sizes are those machines with varying pointer sizes.
What time? What resources?
[...]
>> I find the latter particularly confusing. Off the top of my head, I
>> wouldn't even know how to write C code that *cares* how many registers
>> there are, or if there are any registers at all, unless I use inline
>> assembly code. (I don't use the "register" keyword, and even if I did
>> it's not sensitive to the number of CPU registers.) And if I care about
>> the size of a pointer, I use "sizeof".
>
> The register count is for the virtual machine I was talking about. It's
> a compiler consideration, not a developer consideration. The C language
> should provide a virtual machine which allows developers to target that
> machine for coding, debugging, and execution. It should be a feature
> provided for by the language maintainers, and in that way we all have a
> particular base from which we can proceed. Inside that VM we have a
> known set of operational abilities. They always work. Beyond that, we
> have specifics which run natively on the various and disparate target
> architectures.
Such a virtual machine might be useful -- and similar things have
been done in the past (UCSD Pascal p-code, the Java VM, etc.).
But it's outside the scope of the C standard. It would be yet
another potential target for C implementations.
The C standard committee doesn't write compilers. (Some members
probably do, but not as part of the committee.) There's no reason
they should concern themselves with defining a VM.
[...]
>> I don't want to make writing portable code easier than it is, but
>> for the most part it just requires ignorance (real or pretended)
>> of any system-specific characteristics.
>>
>> I might happen to know that pointers are 8 bytes on the particular
>> machine I'm using, but knowing that is rarely useful, and if I just
>> ignore that fact when I'm writing code, that code is more likely
>> to work on machines with 4-byte pointers.
>
> I have written in C since around 1989. I have never been able to write
> code of any significance (more than a few hundred lines) which has
> compiled in Windows and on another OS the first time. It always has
> required me tweaking something. On this machine I use this function
> to convert an unsigned long to a string, and on this other machine I
> use this one, etc. It's a hassle every single time to this day in 2015.
Perhaps you're paying too much attention to system-specific libraries.
C has standard functions, sprintf and snprintf, that will convert an
unsigned long to a string. If you wrote code that runs on Windows but
doesn't run on another OS, perhaps it's because you used a
Windows-specific library function. If you want your code to be
portable, don't do that.
> It would be nice to have a "C Language" which is universal. No quirks.
> No oddities. And I think targeting that C Language Virtual Machine
> would do the trick. That's all.
There are C implementations that have all the characteristics you're
looking for, and C implementations that don't, because they target
systems that can't support those characteristics. Nothing you suggest
would change that, except that the second set of implementations would
not conform to your new "C Language". Leave C as it is, call your
dialect something else, and everyone can be happy.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-22 05:36 -0700 |
| Message-ID | <1b405c3f-e69a-4155-a376-8eab19586174@googlegroups.com> |
| In reply to | #63698 |
On Saturday, June 20, 2015 at 2:56:14 PM UTC-4, Keith Thompson wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > I don't have a concrete example. I can't even think of one to contrive. > Then why do you care? The language itself should be defined to be a set of things and abilities. It should be a small core which are inherent in the language. Then, atop that, if it is desired, there should be a set of optimizations which are applied for the machine's quirks. Or there should be alternative definitions which exist when unique hardware is in play. > > However, my point is that if I want to adhere to the standard, then I'd > > have to consider such things. > Apparently you *don't* have to consider such things. Perhaps. > When I write code that uses pointers, I declare objects of pointer > types, functions that take arguments and return results of pointer > types, define structs with pointer members, and so on. The only way > such code would depend on the size of a pointer type, or whether > different pointers have the same size, would be if I deliberately > went out of my way to do so. It depends. People run into compiler quirks all the time. Things that should work, but don't due to bugs, or due to obscure facets of C. I ran into one a while back. I can't remember what the name was, but I was trying to declare a read-only block at compile-time. I had to use a seemingly obscure definition, but one which accomplished what I needed. > You seem to have an assumption in the back of your mind that all > pointers are the same size, and that that size is either 32 or > 64 bits, but if you don't make use of that assumption *it doesn't > matter*. As I understand it, on x86 and ARM that is a proper assumption. It's the only reason I make it. > Without a single concrete example where it matters, your argument > is meaningless, and certainly not worth imposing restrictions > on C implementations for a convenience that you don't even take > advantage of. I disagree. C is full of nebulous concepts which are designed for the machine's speed, but not for the programmer's need. An integer is not a finite quantity, except as applied to a specific machine, and even then I'd wager the compiler has the ability to swap it out with another type if it deems the optimization acceptable. A much smaller core definition for C is needed, and then there should be room for expansion into peculiarities beyond that. > > It's an absolute waste of time and > > resources to do so because the only machines that have varying pointer > > sizes are those machines with varying pointer sizes. > What time? What resources? A developer's time, and to code to the language when the code is designed to run on a particular platform that doesn't need to be tied to the limits of the language (which many will argue are not limits because if they're adhered to the same code runs on many machines). > >> I find the latter particularly confusing. Off the top of my head, I > >> wouldn't even know how to write C code that *cares* how many registers > >> there are, or if there are any registers at all, unless I use inline > >> assembly code. (I don't use the "register" keyword, and even if I did > >> it's not sensitive to the number of CPU registers.) And if I care about > >> the size of a pointer, I use "sizeof". > > > > The register count is for the virtual machine I was talking about. It's > > a compiler consideration, not a developer consideration. The C language > > should provide a virtual machine which allows developers to target that > > machine for coding, debugging, and execution. It should be a feature > > provided for by the language maintainers, and in that way we all have a > > particular base from which we can proceed. Inside that VM we have a > > known set of operational abilities. They always work. Beyond that, we > > have specifics which run natively on the various and disparate target > > architectures. > > Such a virtual machine might be useful -- and similar things have > been done in the past (UCSD Pascal p-code, the Java VM, etc.). > But it's outside the scope of the C standard. It would be yet > another potential target for C implementations. I think it should be part of the C standard. I think there should be a "C Machine" that is provided for by the standards committee, a baseline which accounts for all features of C, including even a compiler design, debugger design, etc. These could all be improved upon in an open source effort which then yields easy porting to other platforms. It's similar to what I want to do with Visual FreePro's virtual machine, and the RDC language and compiler. > The C standard committee doesn't write compilers. (Some members > probably do, but not as part of the committee.) There's no reason > they should concern themselves with defining a VM. Disagree. A standards committee is paperwork without some tangible example of their work. It is an exercise in paperwork which explains the (how many pages is it now) page bloat? > >> I don't want to make writing portable code easier than it is, but > >> for the most part it just requires ignorance (real or pretended) > >> of any system-specific characteristics. > >> > >> I might happen to know that pointers are 8 bytes on the particular > >> machine I'm using, but knowing that is rarely useful, and if I just > >> ignore that fact when I'm writing code, that code is more likely > >> to work on machines with 4-byte pointers. > > > > I have written in C since around 1989. I have never been able to write > > code of any significance (more than a few hundred lines) which has > > compiled in Windows and on another OS the first time. It always has > > required me tweaking something. On this machine I use this function > > to convert an unsigned long to a string, and on this other machine I > > use this one, etc. It's a hassle every single time to this day in 2015. > > Perhaps you're paying too much attention to system-specific libraries. Obviously. It's because that's what's available on that machine. But when I port to another machine, I'm required to add underscores on this function or that, remove them on this or that, reorder parts of the names on this or that, etc. It's a total quagmire because there wasn't a true example written by the core C group to demonstrate how it should be. Instead, everybody's able to write their own variety or version, and they're just not interoperable apart from writing only to the standard, in which case you're now subject to some peculiar coding choices given the type of machine you're writing code for, accounting for odd endianness that you'll likely never see. > C has standard functions, sprintf and snprintf, that will convert an > unsigned long to a string. If you wrote code that runs on Windows but > doesn't run on another OS, perhaps it's because you used a > Windows-specific library function. If you want your code to be > portable, don't do that. And how do I separate the two? I include some standard header which has Microsoft extensions, or GCC extensions, and I code using those. How do I know those aren't part of core C without learning every nuance of core C? It's not possible without a protractive effort. And it's not feasible. It's why C should be tightened down, and reined in, and made core with all extensions clearly identified as extensions (by being in the "ext" directory or folder off the main include directory for example). > > It would be nice to have a "C Language" which is universal. No quirks. > > No oddities. And I think targeting that C Language Virtual Machine > > would do the trick. That's all. > > There are C implementations that have all the characteristics you're > looking for, and C implementations that don't, because they target > systems that can't support those characteristics. Nothing you suggest > would change that, except that the second set of implementations would > not conform to your new "C Language". Leave C as it is, call your > dialect something else, and everyone can be happy. RDC. And "rdc -c99" (and the like) to be (largely) compliant (I doubt I'll ever support everything -- should I ever get it finished that is). Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
Page 7 of 23 — ← Prev page 1 … 5 6 [7] 8 9 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web