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 3 of 23 — ← Prev page 1 2 [3] 4 5 … 23 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-06-19 21:02 -0400 |
| Message-ID | <gY2hx.33644$Ul4.7408@fx23.iad> |
| In reply to | #63606 |
Rick, I don't think you understand who language extensions work. The normal way to build an extension is to assign meaning to something that is "invalid" in the base language. Add meaning to code that is invalid, not change the meaning of currently valid code (as much as practical, adding new keywords have the possibility of breaking code that uses those words in existing code, which is why many extensions use "ugly" keywords unless some new header is included). This says that it would NOT be a proper extension to a language where all pointers have the same size to make char pointers bigger because they need to add bits for which character in a word addressed machine are pointed to. You can have modifiers like __far on a pointer to let it reach to something not otherwise accessible (like out of primary segments objects in a segmented address machine). What might reach your goal is to start with a base standard that handles "all" machines, and an extension that defines additional restrictions on the implementation (i.e. allow the user to assume additional things). This is a bit like the POSIX standard, which is basically a list of restrictions on the implementation plus a list of additional library functions. In your case, you may want to go a bit farther, and define meaning to some things that currently require a diagnostic, for example, coming up with a to forward declare a type (other than a struct), something like: typedef typename foo *fooptr;
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-19 18:57 -0700 |
| Message-ID | <lnegl7gmzq.fsf@nuthaus.mib.org> |
| In reply to | #63649 |
Richard Damon <Richard@Damon-Family.org> writes:
> Rick,
> I don't think you understand who language extensions work. The normal
> way to build an extension is to assign meaning to something that is
> "invalid" in the base language. Add meaning to code that is invalid, not
> change the meaning of currently valid code (as much as practical, adding
> new keywords have the possibility of breaking code that uses those words
> in existing code, which is why many extensions use "ugly" keywords
> unless some new header is included).
>
> This says that it would NOT be a proper extension to a language where
> all pointers have the same size to make char pointers bigger because
> they need to add bits for which character in a word addressed machine
> are pointed to. You can have modifiers like __far on a pointer to let it
> reach to something not otherwise accessible (like out of primary
> segments objects in a segmented address machine).
>
> What might reach your goal is to start with a base standard that handles
> "all" machines, and an extension that defines additional restrictions on
> the implementation (i.e. allow the user to assume additional things).
> This is a bit like the POSIX standard, which is basically a list of
> restrictions on the implementation plus a list of additional library
> functions.
>
> In your case, you may want to go a bit farther, and define meaning to
> some things that currently require a diagnostic, for example, coming up
> with a to forward declare a type (other than a struct), something like:
>
> typedef typename foo *fooptr;
Something that I think would accomplish a lot of what Rick is talking
about would be to define a "profile" on top of the C standard.
It would be a document that defines a set of restrictions on C
implementations. It could, for example, narrow the set of possible
values for some constants and define the behavior of some constructs
that have undefined behavior in standard C.
For example, a profile might require:
CHAR_BIT == 8.
char, short, int, long, and long long are 1, 2, 4, 8, and 8 bytes,
respectively.
Integer types have no padding bits; signed types use 2's-complement.
Floating-point types use IEEE representation (C11 Annex F).
The null pointer is represented as all-bits-zero.
All pointers are 8 bytes and have the same representation.
ASCII (or ASCII-based) character set.
Plain char is [un]signed.
Relational operators between pointers to different objects are well
behaved.
Some particular set of the features that are optional in C11 is
supported.
And so forth. Any interested compiler vendors could claim conformance
both to the ISO C standard and to a particular profile, and could
predefine some macro (__PROFILE_FOO__) to claim performance.
ISO wouldn't even have to be involved. Heck, you could publish such a
profile yourself if you like, perhaps along with a small conformance
test suite and a list of implementations that conform.
--
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-20 00:59 -0700 |
| Message-ID | <f279bf89-8b79-49f3-9903-8f8a4f645903@googlegroups.com> |
| In reply to | #63652 |
On Friday, June 19, 2015 at 9:57:53 PM UTC-4, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: > > Rick, > > I don't think you understand who language extensions work. The normal > > way to build an extension is to assign meaning to something that is > > "invalid" in the base language. Add meaning to code that is invalid, not > > change the meaning of currently valid code (as much as practical, adding > > new keywords have the possibility of breaking code that uses those words > > in existing code, which is why many extensions use "ugly" keywords > > unless some new header is included). > > > > This says that it would NOT be a proper extension to a language where > > all pointers have the same size to make char pointers bigger because > > they need to add bits for which character in a word addressed machine > > are pointed to. You can have modifiers like __far on a pointer to let it > > reach to something not otherwise accessible (like out of primary > > segments objects in a segmented address machine). > > > > What might reach your goal is to start with a base standard that handles > > "all" machines, and an extension that defines additional restrictions on > > the implementation (i.e. allow the user to assume additional things). > > This is a bit like the POSIX standard, which is basically a list of > > restrictions on the implementation plus a list of additional library > > functions. > > > > In your case, you may want to go a bit farther, and define meaning to > > some things that currently require a diagnostic, for example, coming up > > with a to forward declare a type (other than a struct), something like: > > > > typedef typename foo *fooptr; > > Something that I think would accomplish a lot of what Rick is talking > about would be to define a "profile" on top of the C standard. > > It would be a document that defines a set of restrictions on C > implementations. It could, for example, narrow the set of possible > values for some constants and define the behavior of some constructs > that have undefined behavior in standard C. > > For example, a profile might require: > > CHAR_BIT == 8. > > char, short, int, long, and long long are 1, 2, 4, 8, and 8 bytes, > respectively. > > Integer types have no padding bits; signed types use 2's-complement. > > Floating-point types use IEEE representation (C11 Annex F). > > The null pointer is represented as all-bits-zero. > > All pointers are 8 bytes and have the same representation. > > ASCII (or ASCII-based) character set. > > Plain char is [un]signed. > > Relational operators between pointers to different objects are well > behaved. > > Some particular set of the features that are optional in C11 is > supported. > > And so forth. Any interested compiler vendors could claim conformance > both to the ISO C standard and to a particular profile, and could > predefine some macro (__PROFILE_FOO__) to claim performance. > > ISO wouldn't even have to be involved. Heck, you could publish such a > profile yourself if you like, perhaps along with a small conformance > test suite and a list of implementations that conform. I like the idea. If we could add the simple C Language VM, write the skeleton OS, editors, debuggers, and API to the host OS, then I'd be all for it. It would accomplish nearly all of what I'm searching for. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-20 17:25 +0200 |
| Message-ID | <mm40hu$mu8$1@dont-email.me> |
| In reply to | #63652 |
On 20/06/15 03:57, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> Rick, >> I don't think you understand who language extensions work. The normal >> way to build an extension is to assign meaning to something that is >> "invalid" in the base language. Add meaning to code that is invalid, not >> change the meaning of currently valid code (as much as practical, adding >> new keywords have the possibility of breaking code that uses those words >> in existing code, which is why many extensions use "ugly" keywords >> unless some new header is included). >> >> This says that it would NOT be a proper extension to a language where >> all pointers have the same size to make char pointers bigger because >> they need to add bits for which character in a word addressed machine >> are pointed to. You can have modifiers like __far on a pointer to let it >> reach to something not otherwise accessible (like out of primary >> segments objects in a segmented address machine). >> >> What might reach your goal is to start with a base standard that handles >> "all" machines, and an extension that defines additional restrictions on >> the implementation (i.e. allow the user to assume additional things). >> This is a bit like the POSIX standard, which is basically a list of >> restrictions on the implementation plus a list of additional library >> functions. >> >> In your case, you may want to go a bit farther, and define meaning to >> some things that currently require a diagnostic, for example, coming up >> with a to forward declare a type (other than a struct), something like: >> >> typedef typename foo *fooptr; > > Something that I think would accomplish a lot of what Rick is talking > about would be to define a "profile" on top of the C standard. > > It would be a document that defines a set of restrictions on C > implementations. It could, for example, narrow the set of possible > values for some constants and define the behavior of some constructs > that have undefined behavior in standard C. > > For example, a profile might require: > > CHAR_BIT == 8. > > char, short, int, long, and long long are 1, 2, 4, 8, and 8 bytes, > respectively. > > Integer types have no padding bits; signed types use 2's-complement. > > Floating-point types use IEEE representation (C11 Annex F). > > The null pointer is represented as all-bits-zero. > > All pointers are 8 bytes and have the same representation. > > ASCII (or ASCII-based) character set. > > Plain char is [un]signed. > > Relational operators between pointers to different objects are well > behaved. > > Some particular set of the features that are optional in C11 is > supported. > > And so forth. Any interested compiler vendors could claim conformance > both to the ISO C standard and to a particular profile, and could > predefine some macro (__PROFILE_FOO__) to claim performance. > > ISO wouldn't even have to be involved. Heck, you could publish such a > profile yourself if you like, perhaps along with a small conformance > test suite and a list of implementations that conform. > That is a nice idea. I think there would need to be a certain degree of hierarchy in such a profile system, since some items on your list (such as 32-bit int) would be convenient assumptions for a lot of programs, but are not valid on a number of modern targets (especially in the embedded world). But it is a lot more realistic than making major changes to the ISO standards.
[toc] | [prev] | [next] | [standalone]
| From | Nathan Wagner <nw@hydaspes.if.org> |
|---|---|
| Date | 2015-06-21 12:04 +0000 |
| Message-ID | <slrnmoda37.2ub.nw@granicus.if.org> |
| In reply to | #63652 |
On 2015-06-20, Keith Thompson <kst-u@mib.org> wrote: > Something that I think would accomplish a lot of what Rick is talking > about would be to define a "profile" on top of the C standard. > > It would be a document that defines a set of restrictions on C > implementations. It could, for example, narrow the set of possible > values for some constants and define the behavior of some constructs > that have undefined behavior in standard C. > > For example, a profile might require: > > CHAR_BIT == 8. [snip] That's more or less what posix does. I think these sorts of suggestions (or discussions, or arguments, or whatever they are) are the result of being confused about what C is, and wanting it to be something different. There's nothing wrong with targeting some other standard than the C standard. All that means is that C and the C standard don't necessarily give you any guarantees. Which is fine. Personally, I try to write portable C code where that is both possible and relatively painless. But I am quite happy to code to the posix spec and dump strict C conformance overboard if that makes sense. C doesn't need to be, and shouldn't try to be, all things to all people. It's useful as is. If you want a different language, go ahead and use it. If you want a more specific spec that specifies requirements for implementation defined behavior, or specifies behavior for undefined behavior, go ahead and either adopt or write one. But the purpose of the C standard's leaving things to the implementation or undefined was to make it possible to provide those things that C *does* specify without requiring a full blown emulation of the C abstract machine. In otherwords, if C doesn't specify every detail, it becomes possible for a wider array of hardware architectures to provide *in hardware* those things that C does guarantee. FWIW, I think even C11 went too far and added things that should have been left to specifications layered on top of C. I can't off-hand think of a single bit of C11 that I would call an improvement, though I've mostly ignored it. Lots of C99 wasn't necessary either, for that matter. -- nw
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-21 13:07 -0700 |
| Message-ID | <ln616gg706.fsf@nuthaus.mib.org> |
| In reply to | #63714 |
Nathan Wagner <nw@hydaspes.if.org> writes:
> On 2015-06-20, Keith Thompson <kst-u@mib.org> wrote:
>> Something that I think would accomplish a lot of what Rick is talking
>> about would be to define a "profile" on top of the C standard.
>>
>> It would be a document that defines a set of restrictions on C
>> implementations. It could, for example, narrow the set of possible
>> values for some constants and define the behavior of some constructs
>> that have undefined behavior in standard C.
>>
>> For example, a profile might require:
>>
>> CHAR_BIT == 8.
>
> [snip]
>
> That's more or less what posix does.
It's a small part of what POSIX does. POSIX specifis CHAR_BIT==8,
INT_MAX>=2147483647, and a few other things, but most of POSIX is a
large collection of headers and library functions. My "profile"
suggestion is *only* a set of restrictions on the characteristics of a
conforming ISO C implementation.
> I think these sorts of suggestions
> (or discussions, or arguments, or whatever they are) are the result of
> being confused about what C is, and wanting it to be something
> different. There's nothing wrong with targeting some other standard
> than the C standard. All that means is that C and the C standard don't
> necessarily give you any guarantees. Which is fine. Personally, I try
> to write portable C code where that is both possible and relatively
> painless. But I am quite happy to code to the posix spec and dump
> strict C conformance overboard if that makes sense.
>
> C doesn't need to be, and shouldn't try to be, all things to all people.
> It's useful as is. If you want a different language, go ahead and use
> it. If you want a more specific spec that specifies requirements for
> implementation defined behavior, or specifies behavior for undefined
> behavior, go ahead and either adopt or write one. But the purpose of
> the C standard's leaving things to the implementation or undefined was
> to make it possible to provide those things that C *does* specify
> without requiring a full blown emulation of the C abstract machine. In
> otherwords, if C doesn't specify every detail, it becomes possible for a
> wider array of hardware architectures to provide *in hardware* those
> things that C does guarantee.
I fail to see how my suggestion is inconsistent with anything you're
saying. The kind of "profile" I'm suggesting would not be part of the C
standard; it would be a secondary standard applied on top of the C
standard. Sort of like POSIX, but less ambitious.
It's basically a way to give a name to a set of non-portable
assumptions.
[...]
--
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 | Nathan Wagner <nw@hydaspes.if.org> |
|---|---|
| Date | 2015-06-23 13:08 +0000 |
| Message-ID | <slrnmoimif.1a3.nw@granicus.if.org> |
| In reply to | #63745 |
On 2015-06-21, Keith Thompson <kst-u@mib.org> wrote: > Nathan Wagner <nw@hydaspes.if.org> writes: >> On 2015-06-20, Keith Thompson <kst-u@mib.org> wrote: >>> For example, a profile might require: >>> >>> CHAR_BIT == 8. >> That's more or less what posix does. > > It's a small part of what POSIX does. POSIX specifis CHAR_BIT==8, > INT_MAX>=2147483647, and a few other things, but most of POSIX is a > large collection of headers and library functions. My "profile" > suggestion is *only* a set of restrictions on the characteristics of a > conforming ISO C implementation. Well, covered by the "less" part I think. :) [snip] > I fail to see how my suggestion is inconsistent with anything you're > saying. It wasn't meant to be. After commenting directly on your post, I wandered into a general observation. My quoting and lack of a transitional statement failed to make that clear. -- nw
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-10 17:36 -0700 |
| Message-ID | <kfnzj3334z4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #63652 |
Keith Thompson <kst-u@mib.org> writes: > > Something that [might serve to identify suitable implementations] > would be to define a "profile" on top of the C standard. > > It would be a document that defines a set of restrictions on C > implementations. It could, for example, narrow the set of possible > values for some constants and define the behavior of some constructs > that have undefined behavior in standard C. > > For example, a profile might require: > > CHAR_BIT == 8. > > char, short, int, long, and long long are 1, 2, 4, 8, and 8 bytes, > respectively. > > Integer types have no padding bits; signed types use 2's-complement. > > Floating-point types use IEEE representation (C11 Annex F). > > The null pointer is represented as all-bits-zero. > > All pointers are 8 bytes and have the same representation. > > ASCII (or ASCII-based) character set. > > Plain char is [un]signed. > > Relational operators between pointers to different objects are well > behaved. > > Some particular set of the features that are optional in C11 is > supported. > > And so forth. Any interested compiler vendors could claim conformance > both to the ISO C standard and to a particular profile, and could > predefine some macro (__PROFILE_FOO__) to claim performance. > > ISO wouldn't even have to be involved. Heck, you could publish such a > profile yourself if you like, perhaps along with a small conformance > test suite and a list of implementations that conform. Kind of a nice idea, but I do have an observation, or perhaps it might be called a complaint. Most of the properties listed can be checked for reliably, either by running program tests or by reading an implementation's documentation, but one cannot - namely, what happens when pointers to different objects are compared. ISTM that it is not good to put such conditions in the same category as other profile conditions. It's okay to state them as assumptions, but they aren't testable in the same way that the other example condtions are, so they shouldn't be included the same way.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-20 01:00 -0700 |
| Message-ID | <fa405fca-c096-49dc-be40-15af8dcb2161@googlegroups.com> |
| In reply to | #63649 |
On Friday, June 19, 2015 at 9:02:12 PM UTC-4, Richard Damon wrote: > Rick, > I don't think you understand who language extensions work. The normal > way to build an extension is to assign meaning to something that is > "invalid" in the base language. Add meaning to code that is invalid, not > change the meaning of currently valid code (as much as practical, adding > new keywords have the possibility of breaking code that uses those words > in existing code, which is why many extensions use "ugly" keywords > unless some new header is included). > > This says that it would NOT be a proper extension to a language where > all pointers have the same size to make char pointers bigger because > they need to add bits for which character in a word addressed machine > are pointed to. You can have modifiers like __far on a pointer to let it > reach to something not otherwise accessible (like out of primary > segments objects in a segmented address machine). > > What might reach your goal is to start with a base standard that handles > "all" machines, and an extension that defines additional restrictions on > the implementation (i.e. allow the user to assume additional things). > This is a bit like the POSIX standard, which is basically a list of > restrictions on the implementation plus a list of additional library > functions. > > In your case, you may want to go a bit farther, and define meaning to > some things that currently require a diagnostic, for example, coming up > with a to forward declare a type (other than a struct), something like: > > typedef typename foo *fooptr; You describe more or less what I'm talking about, but I come at it from a fundamental revamp whereby the standard targets a type of machine which is its fundamental base, and then everything that addresses machine- specific quirks (those that are deemed still necessary in 2015) are added as extension allowances, and then do use those ugly names. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-19 08:40 -0700 |
| Message-ID | <lnd20riu5g.fsf@nuthaus.mib.org> |
| In reply to | #63598 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Friday, June 19, 2015 at 8:45:12 AM UTC-4, Richard Heathfield wrote:
>> On 19/06/15 13:34, Rick C. Hodgin wrote:
>>
>> <snip>
>>
>> > I don't understand why a standard would speak to such architectures
>> > in the year 2015.
>>
>> For the time being, let's set the reason aside, and ask instead what
>> harm it does to *you* for the Standard to support such architectures?
>
> Now I'm comparing my char* size to int* size to see if they're valid on
> a machine where I know they are the same size, but I'm doing this just
> to adhere to a standard providing support that is not necessary to my
> machine.
Why are you making that comparison in the first place? What will your
program do differently if char* and int* have different sizes?
If you write portable code, it doesn't matter whether pointers are 32 or
64 bits, for example; the code will work either way, and all you have to
do is recompile it. It also doesn't matter whether int* and char* are
the same size.
Of course there are cases where you need to write non-portable code, and
I'm sure there are scenarios where there's some advantage in assuming
that int* and char* are the same size. I just can't think of any such
plausible scenario off the top of my head.
If I want to store generic pointer values, I can use void*, and I can
convert a void* value back to char* or int* without loss of information.
>> For you to argue that, say, the support for various sizes of pointer is
>> of no value, presumably all the platforms that you target have pointers
>> all the same size. If that is true, then you can freely assume that all
>> pointers /are/ the same size, and what have you lost? The fact that a
>> document says this is not guaranteed is of no relevance to you if you
>> have the sure and certain knowledge that, for you, it /is/ guaranteed.
>
> If I wish to adhere to the standard, then I cannot make that assumption
> because there's the possibility that my source code could some day be
> compiled on some unusual architecture, and it would be wrong for those
> developers on that machine to fixup my code when I should've done it
> right in the first place.
That concern exists whether differently sized pointers are permitted by
the standard or not. Assuming you actually derive some benefit from
assuming all pointers have the same size, either you care about
platforms where that assumption is incorrect or you don't.
>> So the support that the Standard offers for such platforms is, to you,
>> cost-free.
>
> It's not, because I cannot code to the standard and make that assumption.
> I have to pick one or the other.
The standard doesn't forbid non-portable code.
>> The cost to /others/ of withdrawing that support is presumably non-zero.
>
> I don't think it should be withdrawn, just not made part of the standard.
> It should be an extension or allowance on top of the standard, because it
> is recognized that some machines out there have this unusual pointer-size
> architecture.
To be clear, the standard has no explicit support for having pointers of
different sizes. It simply doesn't require all pointers to have the
same size. It's permissive, not restrictive. You propose imposing a
new restriction on implementations.
[...]
--
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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-06-20 08:54 +0000 |
| Message-ID | <55852992.996296@news.xs4all.nl> |
| In reply to | #63598 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: > On Friday, June 19, 2015 at 8:45:12 AM UTC-4, Richard Heathfield wrote: > > On 19/06/15 13:34, Rick C. Hodgin wrote: > > > > > I don't understand why a standard would speak to such architectures > > > in the year 2015. > > > > For the time being, let's set the reason aside, and ask instead what > > harm it does to *you* for the Standard to support such architectures? > > Now I'm comparing my char* size to int* size to see if they're valid on > a machine where I know they are the same size, but I'm doing this just > to adhere to a standard providing support that is not necessary to my > machine. No, no - move back a step. Why do you even _care_ whether char *s and int *s are the same size? There are many other ways in which they can differ (alignment requirements being merely the most common of these), so you cannot assume that you can use any random char * as an int * anyway, nor vice versa. Assuming that sizeof (char *) == sizeof (int *) _on its own_ buys you exactly nothing. And if you're going to assume all the various other things you have to assume to make use of this one, you might as well go the whole hog and demand POSIX compliance. Richard
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-20 02:06 -0700 |
| Message-ID | <5cd3013b-a625-4bd5-9cb4-3b7437efbb66@googlegroups.com> |
| In reply to | #63668 |
On Saturday, June 20, 2015 at 4:54:51 AM UTC-4, Richard Bos wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: > > > On Friday, June 19, 2015 at 8:45:12 AM UTC-4, Richard Heathfield wrote: > > > On 19/06/15 13:34, Rick C. Hodgin wrote: > > > > > > > I don't understand why a standard would speak to such architectures > > > > in the year 2015. > > > > > > For the time being, let's set the reason aside, and ask instead what > > > harm it does to *you* for the Standard to support such architectures? > > > > Now I'm comparing my char* size to int* size to see if they're valid on > > a machine where I know they are the same size, but I'm doing this just > > to adhere to a standard providing support that is not necessary to my > > machine. > > No, no - move back a step. > > Why do you even _care_ whether char *s and int *s are the same size? I don't. But in order to be compliant with the standard, I need to. And I don't think I should have to do that to be compliant with the standard. I think that should be the default, and then any extensions beyond that allow for unusual sized pointers. > There are many other ways in which they can differ (alignment > requirements being merely the most common of these), so you cannot > assume that you can use any random char * as an int * anyway, nor vice > versa. > Assuming that sizeof (char *) == sizeof (int *) _on its own_ buys you > exactly nothing. And if you're going to assume all the various other > things you have to assume to make use of this one, you might as well go > the whole hog and demand POSIX compliance. Never! :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-20 10:46 +0100 |
| Message-ID | <87si9mn24l.fsf@bsb.me.uk> |
| In reply to | #63670 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Saturday, June 20, 2015 at 4:54:51 AM UTC-4, Richard Bos wrote:
<snip>
>> Why do you even _care_ whether char *s and int *s are the same size?
>
> I don't. But in order to be compliant with the standard, I need to.
How do you explain the fact that there are many people who have been
writing portable, standards compliant C, but who would be shocked if you
told them that char *s and int *s don't have to be the same size?
It's actually quite hard to write a bit of code where the size of a data
pointer matters, but it can, of course, be done. Where is your example
of the last time you needed to know this, or was your claim a
hypothetical one ("*were* I to write standard compliant code I *would*
need to know")?
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-20 03:16 -0700 |
| Message-ID | <a64162ee-920f-4f26-8a42-f41fbf2864a1@googlegroups.com> |
| In reply to | #63680 |
On Saturday, June 20, 2015 at 5:46:43 AM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>
> > On Saturday, June 20, 2015 at 4:54:51 AM UTC-4, Richard Bos wrote:
> <snip>
> >> Why do you even _care_ whether char *s and int *s are the same size?
> >
> > I don't. But in order to be compliant with the standard, I need to.
>
> How do you explain the fact that there are many people who have been
> writing portable, standards compliant C, but who would be shocked if you
> told them that char *s and int *s don't have to be the same size?
I can't.
> It's actually quite hard to write a bit of code where the size of a data
> pointer matters, but it can, of course, be done. Where is your example
> of the last time you needed to know this, or was your claim a
> hypothetical one ("*were* I to write standard compliant code I *would*
> need to know")?
I've never known that the pointers could be different sizes apart from
DOS code with near/far pointers. It's never been an issue. I can't
imagine it being an issue for any of the code I write. However, were
I to write portable code I assume at some point I'd have to know that
information because I couldn't know for sure that a cast from int* to
char* would be valid. Maybe if it's const int* or const char* it uses
the pointer size required for accessing the code segment as data,
whereas if I use int* or char* it uses the data segment, which is a
different size. The ability to interchange those pointers no longer
exists.
Consider also a weakly typed variable structure:
struct SVar
{
int varType;
union {
char c;
short s;
int i;
long l;
unsigned char uc;
unsigned short us;
unsigned int ui;
unsigned long ul;
char* cp;
short* sp;
int* ip;
long* lp;
};
};
Based on varType, the appropriate union member is populated.
Here we have pointers interspersed with finite data items, the maximum
of which on some platforms will be 32-bits. On others, 64-bits. The
pointers on some platforms will be 32-bits. On others, 64-bits. But
I have to recognize the possibility that on machine xyz there could
be a 5-byte pointer, or a 13-byte pointer which happens to exist.
If everything else is 32-bits, that could affect things... So in my
design I may want to align these structures to the nearest 2^n
boundary for performance.
It wouldn't break the code to not have it aligned, or to know or not
know anything about the pointer size ... but it may help the
developer.
I can't see it being an issue for me though. I can't imagine a time
when I will use some unusual architecture with such odd quirks. So
for me I'm back to the general idea of C being standard across all
platforms, all versions, which means the core C standard, its own
virtual machine target, and then extensions out to all of the other
hardware abilities which feel need to be supported as part of the
standard.
(1) Get rid of char, short, int, long, long long (LOL!) and so on...
(2) Ascribe sizes to things, such as s8 or i8 for an integer of 8-bits,
s16, s32, s64, for signed, u8, u16, u32, u64 for unsigned, f32,
f64, f80 for floating point, and allow a "p" suffix for pointers,
as in s8p, u64p, and a "pp" for pointer-to-pointers, as in s8pp.
(3) Create a skeleton VM and a skeleton OS which runs in the VM to
handle interfacing between the host OS and itself.
(4) Create a compiler toolchain which runs in the target and is
defined to be the standard C compiler, with all core features
available exposed.
(5) Re-write the standard libraries to use this new s/u/f variable
name model, and never look back.
But, in all honesty, who cares? It's a lot of work to do what I suggest.
And most people are fine with the way things are ... so until someone
drops millions of dollars in my lap and says, "Run, Rick! Run!" [with
your ideas], I'll just leave it there and proceed with RDC and Visual
FreePro. 'Tis enough work for one man.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-06-20 09:01 -0400 |
| Message-ID | <uudhx.34904$3s.6570@fx22.iad> |
| In reply to | #63681 |
On 6/20/15 6:16 AM, Rick C. Hodgin wrote:
> On Saturday, June 20, 2015 at 5:46:43 AM UTC-4, Ben Bacarisse wrote:
>> It's actually quite hard to write a bit of code where the size of a data
>> pointer matters, but it can, of course, be done. Where is your example
>> of the last time you needed to know this, or was your claim a
>> hypothetical one ("*were* I to write standard compliant code I *would*
>> need to know")?
>
> I've never known that the pointers could be different sizes apart from
> DOS code with near/far pointers. It's never been an issue. I can't
> imagine it being an issue for any of the code I write. However, were
> I to write portable code I assume at some point I'd have to know that
> information because I couldn't know for sure that a cast from int* to
> char* would be valid. Maybe if it's const int* or const char* it uses
> the pointer size required for accessing the code segment as data,
> whereas if I use int* or char* it uses the data segment, which is a
> different size. The ability to interchange those pointers no longer
> exists.
>
In C, casting a int* to a char* ALWAYS works, and gives you a pointer to
the first byte of the int (what that will be in implementation
dependent). Converting a char* to int* might not work if the char* isn't
pointing to the first byte of an int, but that fails even on your
"normal" machines, and dereferencing it might give you an unaligned
exception, or scrambled results (most modern machines have data
alignment restrictions).
Casting is defined (in most places) as value preserving (where value
make sense), so it works (this is especially important when casting
between integral types and floating types).
If you do the conversion "behind the back" of the compiler (using a
union to type pun for instance) is where you can run into issues.
> Consider also a weakly typed variable structure:
>
> struct SVar
> {
> int varType;
>
> union {
> char c;
> short s;
> int i;
> long l;
> unsigned char uc;
> unsigned short us;
> unsigned int ui;
> unsigned long ul;
> char* cp;
> short* sp;
> int* ip;
> long* lp;
> };
> };
>
> Based on varType, the appropriate union member is populated.
>
> Here we have pointers interspersed with finite data items, the maximum
> of which on some platforms will be 32-bits. On others, 64-bits. The
> pointers on some platforms will be 32-bits. On others, 64-bits. But
> I have to recognize the possibility that on machine xyz there could
> be a 5-byte pointer, or a 13-byte pointer which happens to exist.
> If everything else is 32-bits, that could affect things... So in my
> design I may want to align these structures to the nearest 2^n
> boundary for performance.
The language will insure that any such structure will be aligned
properly, and as long as you only read the item that was last written
you will get the right value.
> It wouldn't break the code to not have it aligned, or to know or not
> know anything about the pointer size ... but it may help the
> developer.
>
> I can't see it being an issue for me though. I can't imagine a time
> when I will use some unusual architecture with such odd quirks. So
> for me I'm back to the general idea of C being standard across all
> platforms, all versions, which means the core C standard, its own
> virtual machine target, and then extensions out to all of the other
> hardware abilities which feel need to be supported as part of the
> standard.
>
> (1) Get rid of char, short, int, long, long long (LOL!) and so on...
>
> (2) Ascribe sizes to things, such as s8 or i8 for an integer of 8-bits,
> s16, s32, s64, for signed, u8, u16, u32, u64 for unsigned, f32,
> f64, f80 for floating point, and allow a "p" suffix for pointers,
> as in s8p, u64p, and a "pp" for pointer-to-pointers, as in s8pp.
>
> (3) Create a skeleton VM and a skeleton OS which runs in the VM to
> handle interfacing between the host OS and itself.
>
> (4) Create a compiler toolchain which runs in the target and is
> defined to be the standard C compiler, with all core features
> available exposed.
>
> (5) Re-write the standard libraries to use this new s/u/f variable
> name model, and never look back.
>
> But, in all honesty, who cares? It's a lot of work to do what I suggest.
> And most people are fine with the way things are ... so until someone
> drops millions of dollars in my lap and says, "Run, Rick! Run!" [with
> your ideas], I'll just leave it there and proceed with RDC and Visual
> FreePro. 'Tis enough work for one man.
>
> Best regards,
> Rick C. Hodgin
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-20 15:44 +0100 |
| Message-ID | <87k2uymobf.fsf@bsb.me.uk> |
| In reply to | #63681 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Saturday, June 20, 2015 at 5:46:43 AM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>
>> > On Saturday, June 20, 2015 at 4:54:51 AM UTC-4, Richard Bos wrote:
>> <snip>
>> >> Why do you even _care_ whether char *s and int *s are the same size?
>> >
>> > I don't. But in order to be compliant with the standard, I need to.
>>
>> How do you explain the fact that there are many people who have been
>> writing portable, standards compliant C, but who would be shocked if you
>> told them that char *s and int *s don't have to be the same size?
>
> I can't.
Could it be that your remark is wrong, then -- that you can write
standard compliant code without needing to care about the relative sizes
of char * and int *?
>> It's actually quite hard to write a bit of code where the size of a data
>> pointer matters, but it can, of course, be done. Where is your example
>> of the last time you needed to know this, or was your claim a
>> hypothetical one ("*were* I to write standard compliant code I *would*
>> need to know")?
>
> I've never known that the pointers could be different sizes apart from
> DOS code with near/far pointers. It's never been an issue. I can't
> imagine it being an issue for any of the code I write. However, were
> I to write portable code I assume at some point I'd have to know that
> information because I couldn't know for sure that a cast from int* to
> char* would be valid. Maybe if it's const int* or const char* it uses
> the pointer size required for accessing the code segment as data,
> whereas if I use int* or char* it uses the data segment, which is a
> different size. The ability to interchange those pointers no longer
> exists.
I won't repeat all the things that Richard has said but it's clear you
don't know what the language standard says. It is not rather arrogant
to say that you'd like changes in a standard you don't seem to know to
accommodate perceived problems that turn out not to be problems?
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-20 12:08 -0700 |
| Message-ID | <lnzj3ufb9u.fsf@nuthaus.mib.org> |
| In reply to | #63681 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Saturday, June 20, 2015 at 5:46:43 AM UTC-4, Ben Bacarisse wrote:
[...]
>> It's actually quite hard to write a bit of code where the size of a data
>> pointer matters, but it can, of course, be done. Where is your example
>> of the last time you needed to know this, or was your claim a
>> hypothetical one ("*were* I to write standard compliant code I *would*
>> need to know")?
>
> I've never known that the pointers could be different sizes apart from
> DOS code with near/far pointers. It's never been an issue. I can't
> imagine it being an issue for any of the code I write. However, were
> I to write portable code I assume at some point I'd have to know that
> information because I couldn't know for sure that a cast from int* to
> char* would be valid. Maybe if it's const int* or const char* it uses
> the pointer size required for accessing the code segment as data,
> whereas if I use int* or char* it uses the data segment, which is a
> different size. The ability to interchange those pointers no longer
> exists.
Your assumption is incorrect.
The behavior of a pointer conversion does not depend on the sizes of the
pointer types. A conversion from int* to char* is always valid.
int n = 42;
int *iptr = &n;
char *cptr = (char*)n;
printf("%d\n", *cptr);
The value printed by this code is implementation-defined; it will be one
byte of the representation of n. The bhavior depends on the
representations of int and char. It does not depend on the
representations of int* and char*. If int* and char* are different
sizes, the code generated for the conversion will do whatever it needs
to do to allow for that.
> Consider also a weakly typed variable structure:
>
> struct SVar
> {
> int varType;
>
> union {
> char c;
> short s;
> int i;
> long l;
> unsigned char uc;
> unsigned short us;
> unsigned int ui;
> unsigned long ul;
> char* cp;
> short* sp;
> int* ip;
> long* lp;
> };
> };
>
> Based on varType, the appropriate union member is populated.
>
> Here we have pointers interspersed with finite data items, the maximum
> of which on some platforms will be 32-bits. On others, 64-bits. The
> pointers on some platforms will be 32-bits. On others, 64-bits. But
> I have to recognize the possibility that on machine xyz there could
> be a 5-byte pointer, or a 13-byte pointer which happens to exist.
> If everything else is 32-bits, that could affect things... So in my
> design I may want to align these structures to the nearest 2^n
> boundary for performance.
>
> It wouldn't break the code to not have it aligned, or to know or not
> know anything about the pointer size
That's exactly my point.
> ... but it may help the
> developer.
Not much.
> I can't see it being an issue for me though. I can't imagine a time
> when I will use some unusual architecture with such odd quirks.
But even if you did use such an unusual architecture, your code can
still work as long as you don't rely on non-portable assumptions when
you write it. I think you vastly underestimate how much you can do
based only on the guarantees given by the standard.
> So
> for me I'm back to the general idea of C being standard across all
> platforms, all versions, which means the core C standard, its own
> virtual machine target, and then extensions out to all of the other
> hardware abilities which feel need to be supported as part of the
> standard.
>
> (1) Get rid of char, short, int, long, long long (LOL!) and so on...
You've just broken every C program ever written.
If you want a new language, by all means go ahead and define and
implement it. People do that all the time. You just don't get to
call it C.
[...]
--
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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-21 21:02 +0100 |
| Message-ID | <mm755n$dem$1@dont-email.me> |
| In reply to | #63699 |
On 20/06/2015 20:08, Keith Thompson wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> (1) Get rid of char, short, int, long, long long (LOL!) and so on... > > You've just broken every C program ever written. > > If you want a new language, by all means go ahead and define and > implement it. People do that all the time. You just don't get to > call it C. Why not, is 'C' copyrighted or trademarked? There aren't that many decent single-letter names to go around (unless we start delving into Unicode but we all know that's never going to work). (I've used designations 'A' and 'B' recently, it would be nice to use 'C' next, even if it would be a little confusing.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-21 21:24 +0100 |
| Message-ID | <mm76fv$ih5$1@dont-email.me> |
| In reply to | #63744 |
On 21/06/15 21:02, Bartc wrote: > On 20/06/2015 20:08, Keith Thompson wrote: >> >> If you want a new language, by all means go ahead and define and >> implement it. People do that all the time. You just don't get to >> call it C. > > Why not, is 'C' copyrighted or trademarked? No. You can call it C if you like. But is that a useful thing to do? It's not as if C is a particularly good name for a language. In fact, the more unique the name, the better, and C is far from being a unique name. It's a single letter, a musical note, a fitness grade, an academic grade, a (hex) digit, a vitamin, a battery size, a temperature scale, a unit of charge, a chemical element, a nucleic acid, and the head of MI6. It's a *terrible* name for a language, and IMHO it has always been the C language's greatest weakness. > There aren't that many decent single-letter names to go around (unless > we start delving into Unicode but we all know that's never going to work). There aren't *any* decent single-letter names to go around. Firstly, they've all been used, and secondly a single-letter name is *not* a decent name. Far better to call your language "Centrox" or "FireDream" or "Stomple" - something that isn't going to generate too many false positives in a search engine. C: 22,210,000,000 hits Centrox: 268,000 hits FireDream: 101,000 hits Stomple: 22,700 hits Of the four, Stomple (while still being a terrible name) is the best, simply because there's so little else around on the Web to get it confused with. Until some complete bonehead comes up with Stomple++ or Stomple#, that is, whereupon we will be given even more evidence that recruiters are incapable of writing proper filters. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-21 22:41 +0100 |
| Message-ID | <mm7auu$2te$1@dont-email.me> |
| In reply to | #63748 |
On 21/06/2015 21:24, Richard Heathfield wrote: > On 21/06/15 21:02, Bartc wrote: >> On 20/06/2015 20:08, Keith Thompson wrote: >>> >>> If you want a new language, by all means go ahead and define and >>> implement it. People do that all the time. You just don't get to >>> call it C. >> >> Why not, is 'C' copyrighted or trademarked? > > No. You can call it C if you like. But is that a useful thing to do? > > It's not as if C is a particularly good name for a language. In fact, > the more unique the name, the better, and C is far from being a unique > name. It's a single letter, a musical note, a fitness grade, an academic > grade, a (hex) digit, a vitamin, a battery size, a temperature scale, a > unit of charge, a chemical element, a nucleic acid, and the head of MI6. > It's a *terrible* name for a language, and IMHO it has always been the C > language's greatest weakness. I think you've just shown that a single-letter name can be used successfully, when there is some context. It's handy as a prefix and suffix too, or as an easy choice for a file extension (because language names usually need abbreviating at some point for such purposes). >> There aren't that many decent single-letter names to go around (unless >> we start delving into Unicode but we all know that's never going to >> work). > > There aren't *any* decent single-letter names to go around. Firstly, > they've all been used, So despite being poor names, there is still strong competition for them! > Far better to call your language "Centrox" or "FireDream" or "Stomple" - > something that isn't going to generate too many false positives in a > search engine. > > C: 22,210,000,000 hits Perhaps that partly explains C's high TIOBE rating then! > Centrox: 268,000 hits > FireDream: 101,000 hits > Stomple: 22,700 hits There are also plenty of language names which can be ambiguous despite not being that short (Basic, Python, Ada, Go (although that /is/ rather sort), Dart and so on). -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 3 of 23 — ← Prev page 1 2 [3] 4 5 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web