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 17 of 23 — ← Prev page 1 … 15 16 [17] 18 19 … 23 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-29 06:40 -0700 |
| Message-ID | <6047be0f-f26c-495d-814c-f03339d5f88e@googlegroups.com> |
| In reply to | #64444 |
On Monday, June 29, 2015 at 9:21:44 AM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>
> > On Monday, June 29, 2015 at 7:10:45 AM UTC-4, Ben Bacarisse wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> > On Sunday, June 28, 2015 at 3:56:53 PM UTC-4, Ben Bacarisse wrote:
> <snip>
> >> >> int f(int x)
> >> >> {
> >> >> return(*(char*)&x);
> >> >> }
> >>
> >> I did not write that. Please don't edit other people's words when
> >> quoting.
> >
> > You wrote it, Ben. Both forms would compile to the same form.
> > I edited it so it was easier for me to read and understand.
>
> Please don't edit quotes -- particularly code. It's not polite and
> helps no one. You can re-write code, in your preferred style, all you
> like, but you should not suggest that I would write it like that.
Is this really an issue to you? So much so that you're really asking
me not to revise your source code?
I will honor your request, but I am floored.
> <snip stuff that does not matter now>
>
> > However, my goal is to provide Core C on all platforms, with extensions
> > out to non-Core C features also being allowed to address machine
> > quirks.
>
> Eh? I thought your goal was a change in the specification of C. Had I
> understood that you just want to implement a VM-based language you call
> "core C", then I would not have commented. Sorry for the waste of time,
> but it really sounded like you were talking about changing the language
> we talk about here called C.
My goal is to change the specification of C to be Core C, which is then
used on all hardware. The extensions allowed to Core C would enable the
existing hardware to operate as per its machine quirks, but it would not
be part of the core C definition, but only in extension allowances.
And, as part of the Core C spec being written, the Core C group
responsible for creating and maintaining the spec, would not be an idle
body who just writes paper. They would actually write a real working
compiler, and provide a Core C VM which allows it to be distributed out
to all platforms for processing.
Very few things in C are truly time critical. If most apps ran a few
percentage points slower (even 20% slower), then the user would still
never see the difference. And in those cases where it is an issue,
the option to write for native hardware still exists.
> (I'd advice a less confusing name, but there are already a lot of C-like
> languages with similarly confusing names, so I don't suppose yet another
> one will cause any significant confusion.)
I think you still misunderstand. And have misunderstood at many points
throughout our discussions. But, as I say, it's not an issue for me to
pursue it. I was simply answering your questions.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-29 17:38 +0100 |
| Message-ID | <87k2umcvw0.fsf@bsb.me.uk> |
| In reply to | #64448 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Monday, June 29, 2015 at 9:21:44 AM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>
>> > On Monday, June 29, 2015 at 7:10:45 AM UTC-4, Ben Bacarisse wrote:
>> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> >> > On Sunday, June 28, 2015 at 3:56:53 PM UTC-4, Ben Bacarisse wrote:
>> <snip>
>> >> >> int f(int x)
>> >> >> {
>> >> >> return(*(char*)&x);
>> >> >> }
>> >>
>> >> I did not write that. Please don't edit other people's words when
>> >> quoting.
>> >
>> > You wrote it, Ben. Both forms would compile to the same form.
>> > I edited it so it was easier for me to read and understand.
>>
>> Please don't edit quotes -- particularly code. It's not polite and
>> helps no one. You can re-write code, in your preferred style, all you
>> like, but you should not suggest that I would write it like that.
>
> Is this really an issue to you?
Yes.
> So much so that you're really asking
> me not to revise your source code?
I didn't ask for that. Revise it all you like. Re-write it "better"
and post it with knobs on. I asked that you don't edit a direct quote
(at least not without indicating an edit), a courtesy that applies to
code and text alike.
> I will honor your request, but I am floored.
Thank you.
>> <snip stuff that does not matter now>
>>
>> > However, my goal is to provide Core C on all platforms, with extensions
>> > out to non-Core C features also being allowed to address machine
>> > quirks.
>>
>> Eh? I thought your goal was a change in the specification of C. Had I
>> understood that you just want to implement a VM-based language you call
>> "core C", then I would not have commented. Sorry for the waste of time,
>> but it really sounded like you were talking about changing the language
>> we talk about here called C.
>
> My goal is to change the specification of C to be Core C, which is then
> used on all hardware.
Oh we're back on are we? OK. It won't happen. No one wants C to be
Java lite, even if it does not need a VM on an Intel chip (it's not
clear what scope you propose for the VM).
> The extensions allowed to Core C would enable the
> existing hardware to operate as per its machine quirks, but it would not
> be part of the core C definition, but only in extension allowances.
We have that already.
> And, as part of the Core C spec being written, the Core C group
> responsible for creating and maintaining the spec, would not be an idle
> body who just writes paper.
Really? Is that a jibe at the ISO committee? Do you know who's on it?
> They would actually write a real working
> compiler, and provide a Core C VM which allows it to be distributed out
> to all platforms for processing.
>
> Very few things in C are truly time critical. If most apps ran a few
> percentage points slower (even 20% slower), then the user would still
> never see the difference. And in those cases where it is an issue,
> the option to write for native hardware still exists.
Yes, that's why Python and Java and so on are so successful in that
arena. C's natural home is elsewhere.
>> (I'd advice a less confusing name, but there are already a lot of C-like
>> languages with similarly confusing names, so I don't suppose yet another
>> one will cause any significant confusion.)
>
> I think you still misunderstand. And have misunderstood at many points
> throughout our discussions. But, as I say, it's not an issue for me to
> pursue it. I was simply answering your questions.
Ah, so you're *not* pursuing it? I'm glad.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-29 10:44 -0700 |
| Message-ID | <22f51b77-903d-4d53-9cae-be5a1abd06b9@googlegroups.com> |
| In reply to | #64471 |
On Monday, June 29, 2015 at 12:38:49 PM UTC-4, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > On Monday, June 29, 2015 at 9:21:44 AM UTC-4, Ben Bacarisse wrote: > >> Eh? I thought your goal was a change in the specification of C. Had I > >> understood that you just want to implement a VM-based language you call > >> "core C", then I would not have commented. Sorry for the waste of time, > >> but it really sounded like you were talking about changing the language > >> we talk about here called C. > > > > My goal is to change the specification of C to be Core C, which is then > > used on all hardware. > > Oh we're back on are we? You have not understood this point at any point I believe, Ben. I have never not been interested in doing this. I just don't have a great deal of drive or passion to do it. But were something to change, I would pursue it. I probably actually wouldn't pursue it actually, but instead I would probably just do it. > OK. It won't happen. No one wants C to be Java lite, The TinyC folk would disagree with you. :-) And there are lots others who would like a small, tight, VM that had a compiler for C code. > even if it does not need a VM on an Intel chip (it's not > clear what scope you propose for the VM). The VM would run on x86 hardware. It would probably just run natively with exception trapping as with a typical VM. No great required on that platform. > > The extensions allowed to Core C would enable the > > existing hardware to operate as per its machine quirks, but it would not > > be part of the core C definition, but only in extension allowances. > > We have that already. You have it all in one. I would break them out logically, and remove them from any compiler requirement, except for those which desire to use it because of their hardware quirks. > > And, as part of the Core C spec being written, the Core C group > > responsible for creating and maintaining the spec, would not be an idle > > body who just writes paper. > > Really? Yes. > Is that a jibe at the ISO committee? Somewhat. And, I could be wrong about their group. As I understand it they do not author anything except paper, even though many of their members do for the other entities they represent. > Do you know who's on it? Not by name. > > They would actually write a real working > > compiler, and provide a Core C VM which allows it to be distributed out > > to all platforms for processing. > > > > Very few things in C are truly time critical. If most apps ran a few > > percentage points slower (even 20% slower), then the user would still > > never see the difference. And in those cases where it is an issue, > > the option to write for native hardware still exists. > > Yes, that's why Python and Java and so on are so successful in that > arena. C's natural home is elsewhere. Today. Because this thing I'm talking about doesn't exist for C. > >> (I'd advice a less confusing name, but there are already a lot of C-like > >> languages with similarly confusing names, so I don't suppose yet another > >> one will cause any significant confusion.) > > > > I think you still misunderstand. And have misunderstood at many points > > throughout our discussions. But, as I say, it's not an issue for me to > > pursue it. I was simply answering your questions. > > Ah, so you're *not* pursuing it? I'm glad. See above. If things drastically changed in my life (I inherited ten million dollars), I would complete Visual FreePro and RDC, then my operating system, then an ARM port of my OS, then the 64-bit versions, and then I would work on completing RDC to be fully C compliant, and then I would work on Core C, and finally I would complete my LibSF 386-x40 CPU design and start building machines which run my entire software stack. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-29 22:10 +0100 |
| Message-ID | <87a8vicjba.fsf@bsb.me.uk> |
| In reply to | #64476 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Monday, June 29, 2015 at 12:38:49 PM UTC-4, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> > On Monday, June 29, 2015 at 9:21:44 AM UTC-4, Ben Bacarisse wrote: >> >> Eh? I thought your goal was a change in the specification of C. Had I >> >> understood that you just want to implement a VM-based language you call >> >> "core C", then I would not have commented. Sorry for the waste of time, >> >> but it really sounded like you were talking about changing the language >> >> we talk about here called C. >> > >> > My goal is to change the specification of C to be Core C, which is then >> > used on all hardware. >> >> Oh we're back on are we? > > You have not understood this point at any point I believe, Ben. Spot on. I am still confused but I can cover both cases in one reply. If you want to change the definition of the C language I will simply note my objection, safe in the knowledge that it will never be changed in the way you would like. Even if doing so were possible, it's a huge amount of work and you've said many times that you are not that interested in it. If you want to implement something you call "core C" I have no objection. How could I have? Implement away. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-29 15:09 -0700 |
| Message-ID | <fbbd2151-99d4-4022-ac43-05fd271a81f0@googlegroups.com> |
| In reply to | #64501 |
On Monday, June 29, 2015 at 5:10:27 PM UTC-4, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > > On Monday, June 29, 2015 at 12:38:49 PM UTC-4, Ben Bacarisse wrote: > >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > >> > On Monday, June 29, 2015 at 9:21:44 AM UTC-4, Ben Bacarisse wrote: > >> >> Eh? I thought your goal was a change in the specification of C. Had I > >> >> understood that you just want to implement a VM-based language you call > >> >> "core C", then I would not have commented. Sorry for the waste of time, > >> >> but it really sounded like you were talking about changing the language > >> >> we talk about here called C. > >> > > >> > My goal is to change the specification of C to be Core C, which is then > >> > used on all hardware. > >> > >> Oh we're back on are we? > > > > You have not understood this point at any point I believe, Ben. > > Spot on. I am still confused but I can cover both cases in one reply. > If you want to change the definition of the C language I will simply > note my objection, safe in the knowledge that it will never be changed > in the way you would like. Even if doing so were possible, it's a huge > amount of work and you've said many times that you are not that > interested in it. > > If you want to implement something you call "core C" I have no > objection. How could I have? Implement away. We'll see what comes. The enemy has been hitting me pretty hard for several years. It's really drained me all around. I will continue to do my best, however. It's all I can do. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-28 11:43 -0700 |
| Message-ID | <lnd20ffzcq.fsf@kst-u.example.com> |
| In reply to | #64346 |
raltbos@xs4all.nl (Richard Bos) writes:
[...]
> Then you're simply wrong. C, as a language, was created specifically
> _for_ practical, everyday programming purposes. It was not created as a
> research language, let alone as a philosophical statement. If you want
> those, you can go to Lisp, or Ada, or Pascal. But stop insisting that C
> is wrong for not being a theoretical language. It is a practical
> language, and that is _right_.
Ada was created for practical programming purposes. Quoting the Ada
standard:
Ada was originally designed with three overriding concerns: program
reliability and maintenance, programming as a human activity, and
efficiency.
Whether it achieved those goals is another question (perhaps for another
forum), but that was the intent.
--
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-28 10:43 +0000 |
| Message-ID | <558fcf73.4910921@news.xs4all.nl> |
| In reply to | #64070 |
David Brown <david.brown@hesbynett.no> wrote: > Where Harvard architecture gets relevant is when code and data spaces > are separate, and this is exposed in the ISA - typically there are > different instructions for accessing the two spaces. On the AVR, > loading data from code space uses the "lpm" instruction, while loading > data from data space uses the "ld" instruction (or other related > instructions). Thus pointers to data in the two spaces must be treated > very differently. It makes no real difference to normal code and > function pointers, or normal ram variables or pointers to them - but it > makes a huge difference when you want to keep constant read-only data > alongside the code (in flash on the microcontroller). (It would also > make a difference if you wanted to put some code in ram - on the AVR, > this is simply not allowed.) Which, by the way, is a _very_ good idea for microcontrollers. Allowing someone to mung your elevator controller by flashing the EPROM is one thing; letting J. Random Passerby do so with just a patch, while the elevator is still going up and down is quite another. Richard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-29 08:50 +0200 |
| Message-ID | <mmqpoi$eh0$1@dont-email.me> |
| In reply to | #64343 |
On 28/06/15 12:43, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> Where Harvard architecture gets relevant is when code and data spaces >> are separate, and this is exposed in the ISA - typically there are >> different instructions for accessing the two spaces. On the AVR, >> loading data from code space uses the "lpm" instruction, while loading >> data from data space uses the "ld" instruction (or other related >> instructions). Thus pointers to data in the two spaces must be treated >> very differently. It makes no real difference to normal code and >> function pointers, or normal ram variables or pointers to them - but it >> makes a huge difference when you want to keep constant read-only data >> alongside the code (in flash on the microcontroller). (It would also >> make a difference if you wanted to put some code in ram - on the AVR, >> this is simply not allowed.) > > Which, by the way, is a _very_ good idea for microcontrollers. Allowing > someone to mung your elevator controller by flashing the EPROM is one > thing; letting J. Random Passerby do so with just a patch, while the > elevator is still going up and down is quite another. > Protecting your software code is clearly a good thing. But the Harvard separation of code and data spaces has nothing to do with that - most processors are logically von Neumann, yet have no problems in this area. You put your code in flash, and run it from there - you don't (normally) run code from ram. And if you want extra protection, many micros allow you to set up memory protection areas to explicitly disable running code from outside of the flash. The Harvard setup on the AVR is /bad/ for security and safety, because it forces data that should be protected and read-only to be copied from flash into ram, where it is vulnerable to buffer overflows, run-away pointers, etc. (if you make such mistakes!), instead of being safely in read-only flash.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-06-27 12:32 -0400 |
| Message-ID | <seAjx.25891$Ml.23812@fx23.iad> |
| In reply to | #64064 |
On 6/24/15 10:52 AM, David Kleinecke wrote: > On Tuesday, June 23, 2015 at 1:58:04 PM UTC-7, David Brown wrote: ... >> However, having used processors with Harvard ISAs and separate code and >> data spaces (as distinct from merely having separate code and data buses >> as a feature of the implementation), I can say that it is a truly >> horrible idea that leads to ugly and messy code, as constant data is >> generally in code space and cannot be accessed in the same way as >> non-constant data in data space. On microcontrollers with such >> architectures (as they are invariably small microcontrollers or DSP's), >> you need to waste precious RAM resources on copies of flash data, or >> duplicate functions to let you have ram-pointer and flash-pointer >> versions. It's a mess. > > It sounds to me like Harvard architecture is either not well designed > or not well coded. It seems obvious to me that constant data should be > in data space. In embedded systems lots of things I don't understand > happen and I was imagining a larger machine with Harvard architecture > of a sort that does not exist so far as I know. > > I just think it should exist and it poses some interesting system > problems. > My biggest experience with a Harvard Architecture is with the Pic24 (and related) line of processors. The code space is 24 bits wide and the data space is 16 bits wide (with a 16 bit address). There are two different ways to access code space for data. There are "table" instructions which read/write to the 24 bit code space, with separate instructions for accessing the low 16 bit of a word, or the high 8 bits. There is also a mapping register which allows you to map the lower 16 bits of a region of code space into a 'page' of data space. This gives you ability to setup a page of constants that are visible as ordinary memory without using up precious ram. (For members of this family with lots of ram, they also use this method for mapping the memory above what can be based addressed into the same window). This does bring up the memory model issues that many are familiar with from 16 bit x86 programming. Programs not needing excessive memory just set the map once and just live with a uniform 64kB address space and a 16bit data pointer, program that need more than that, can manipulate the mapping register, and pointers need to include the value of the mapping register. I do agree that the Harvard Architecture while having some interesting properties for embedded sized system, has less applicability for larger systems, although the definite separation of 'data' and 'code' does add a degree of protection from a number of the common exploits (it is much harder to inject executable code with buffer overruns if changing executable code requires special instructions)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-23 13:17 -0400 |
| Message-ID | <mmc48c$v6e$1@dont-email.me> |
| In reply to | #63935 |
On 06/23/2015 10:40 AM, David Brown wrote: ... > reasoning here would be better than "it doesn't feel right to me". The > obvious benefit of standard pointer sizes - that it could simplify > compiler implementations - hasn't even been mentioned. I don't see how. The only places where pointers of multiple sizes are used are places where using a single size would make things more complicated or inefficient. No one does these things just for the fun of it. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-23 13:20 -0400 |
| Message-ID | <mmc4ed$v6e$2@dont-email.me> |
| In reply to | #63963 |
On 06/23/2015 01:17 PM, James Kuyper wrote: > On 06/23/2015 10:40 AM, David Brown wrote: > ... >> reasoning here would be better than "it doesn't feel right to me". The >> obvious benefit of standard pointer sizes - that it could simplify >> compiler implementations - hasn't even been mentioned. > > I don't see how. The only places where pointers of multiple sizes are > used are places where using a single size would make things more > complicated or inefficient. No one does these things just for the fun of it. Sorry - I forgot the DS9000, which has dozens of different pointers sizes. *Almost" no one does these things just for the fun of it. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-23 10:25 -0700 |
| Message-ID | <0efce288-fddb-4abd-97ca-86f28d43cff5@googlegroups.com> |
| In reply to | #63964 |
On Tuesday, June 23, 2015 at 1:20:38 PM UTC-4, James Kuyper wrote: > On 06/23/2015 01:17 PM, James Kuyper wrote: > > On 06/23/2015 10:40 AM, David Brown wrote: > > ... > >> reasoning here would be better than "it doesn't feel right to me". The > >> obvious benefit of standard pointer sizes - that it could simplify > >> compiler implementations - hasn't even been mentioned. > > > > I don't see how. The only places where pointers of multiple sizes are > > used are places where using a single size would make things more > > complicated or inefficient. No one does these things just for the fun > > of it. > > Sorry - I forgot the DS9000, which has dozens of different pointers > sizes. *Almost" no one does these things just for the fun of it. Obviously, James. Things should be used appropriately where they are available to be used appropriately. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-24 09:51 +0200 |
| Message-ID | <mmdngc$vae$1@dont-email.me> |
| In reply to | #63963 |
On 23/06/15 19:17, James Kuyper wrote: > On 06/23/2015 10:40 AM, David Brown wrote: > ... >> reasoning here would be better than "it doesn't feel right to me". The >> obvious benefit of standard pointer sizes - that it could simplify >> compiler implementations - hasn't even been mentioned. > > I don't see how. The only places where pointers of multiple sizes are > used are places where using a single size would make things more > complicated or inefficient. No one does these things just for the fun of it. > I am thinking here of a hypothetical compiler that is written to target systems where pointers must always be the same size, compared to a hypothetical compiler that supports different sizes for different types. The single pointer size compiler would have a simpler job representing target pointers in its internal code trees and other structures, while the flexible pointer size compiler would have to have structures and code to handle the flexibility. It would need that even if all the pointer sizes happen to be the same on a given target architecture. I doubt it this would be a big point for the compiler developer, but it certainly seems to me that consistent pointer size would be easier for the compiler implementer than flexible sizes.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-24 12:05 -0400 |
| Message-ID | <mmekdp$7mn$1@dont-email.me> |
| In reply to | #64022 |
On 06/24/2015 03:51 AM, David Brown wrote: > On 23/06/15 19:17, James Kuyper wrote: >> On 06/23/2015 10:40 AM, David Brown wrote: >> ... >>> reasoning here would be better than "it doesn't feel right to me". The >>> obvious benefit of standard pointer sizes - that it could simplify >>> compiler implementations - hasn't even been mentioned. >> >> I don't see how. The only places where pointers of multiple sizes are >> used are places where using a single size would make things more >> complicated or inefficient. No one does these things just for the fun of it. >> > > I am thinking here of a hypothetical compiler that is written to target > systems where pointers must always be the same size, compared to a > hypothetical compiler that supports different sizes for different types. > The single pointer size compiler would have a simpler job representing > target pointers in its internal code trees and other structures, while > the flexible pointer size compiler would have to have structures and > code to handle the flexibility. It would need that even if all the > pointer sizes happen to be the same on a given target architecture. You've got the basic idea wrong. When someone provides an implementation of C that allows multiple pointer sizes, it isn't to satisfy some weird goal of "flexibility". They are different because the architecture provides strong incentives for doing so. Consider a platform where the hardware-addressable memory unit (word) is 16 bits, which has a maximum of 2^16 words of memory installed. A pointer to any word-aligned type (which would be basically anything other than char, unsigned char, and signed char, and possibly _Bool) can therefore be stored in a single word. However, void*, char*, unsigned char*, and char* have to be implemented by the combination of a 16-bit word address, and a 1-bit offset indicating whether it points at the first or second byte of the word. The smallest permitted size for a void* is therefore 3 bytes (1.5 words), but that would require extracting one of the three bytes by mask-and-shift operations. You could simplify the handling of pointers at the cost of expanding them to 4 bytes. On a platform with such a small amount of memory installed, that might be unacceptable. So, assuming that the typical program targeting this platform uses pointers to word-aligned types far more often than byte-aligned types (this is a platform-specific tendency; I'm not claiming it's true of all computer programs), which compiler would you prefer to work with: A) UniformA - all pointers to all types are 3 bytes in length. All pointers are read by reading two words from memory, and using mask and shift instructions to extract only one byte from one of those two words. Different instructions are needed depending upon whether the word address is even or odd. All pointers are written by reading one word from memory, and using mask and shift operations to set one byte of that word to the appropriate value, and then writing it back, and then writing another word. The instructions are different depending upon whether the word address is even or odd. B) UniformB - all pointers to all types are 4 bytes in length. They are read and written two words at a time, which is a lot simpler than UniformA. However, the take up a lot more space on a platform where memory is tight. C) TwoSize - pointers to word-aligned types are stored in a single word, allowing them to be read and written even faster than the pointers used by UniformB. Pointers to byte-aligned types are stored as three words, using the same implementation that UniformA uses for all pointer types. I'd expect UniformB to produce the simplest code, but TwoSize to produce code that is significantly faster and uses a lot less memory, for the typical program targeting this platform. Is it really important to impose a requirement that would render TwoSize non-conforming? If so, why? It wouldn't stop people from preferring TwoSize, they just wouldn't be able to call the language it implements "C". This is useful?! > I doubt it this would be a big point for the compiler developer, but it > certainly seems to me that consistent pointer size would be easier for > the compiler implementer than flexible sizes. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-24 10:43 -0700 |
| Message-ID | <a0896a47-3183-47e8-a8a5-b11526b938fc@googlegroups.com> |
| In reply to | #64083 |
On Wednesday, June 24, 2015 at 12:05:40 PM UTC-4, James Kuyper wrote: > Is it really important to > impose a requirement that would render TwoSize non-conforming? If so, > why? It wouldn't stop people from preferring TwoSize, they just wouldn't > be able to call the language it implements "C". This is useful?! If you're referring to my "proposal" here, then there's a disconnect. In my "proposal" there would be core C, and then there would be extension C. Core C would have those things which are defined to be part of the core language (uniform pointer sizes, finite data quantities known by their name, thread and process awareness, and more). Beyond those core abilities, a set of extensions would be allowed which are now under the name "extensions to core C." These extensions would allow your example with two pointer sizes, and it would all still be called C. However, it would be noted that this ability included in this version of the compiler on this architecture would be using extensions outside of core C. Would you still write source code the same way? Yes. Would you still compile source code the same way? Yes. Would you still run your executable the same way? Yes. What's different? Only the fact that parts of core C are employed, along with some extensions to core C. Make sense now? Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-06-27 12:18 +0000 |
| Message-ID | <558e9488.6410531@news.xs4all.nl> |
| In reply to | #64085 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: > Would you still write source code the same way? Yes. > Would you still compile source code the same way? Yes. > Would you still run your executable the same way? Yes. > What's different? Only the fact that parts of core C are employed, > along with some extensions to core C. If it doesn't change anything but the terminology, why are you so upset by our pointing out that it doesn't do any good? Richard
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-27 05:26 -0700 |
| Message-ID | <27301066-0ba8-43a2-b2b6-f341aef26dad@googlegroups.com> |
| In reply to | #64288 |
On Saturday, June 27, 2015 at 8:19:01 AM UTC-4, Richard Bos wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: > > > Would you still write source code the same way? Yes. > > Would you still compile source code the same way? Yes. > > Would you still run your executable the same way? Yes. > > What's different? Only the fact that parts of core C are employed, > > along with some extensions to core C. > > If it doesn't change anything but the terminology, why are you so > upset by our pointing out that it doesn't do any good? Your reply postulates a position that is not mine (that I am upset), and then asks me how I can be that way. I believe that's called a non-sequitor, or a strawman argument. My position is here: Core C needs to be the smaller core. Extensions out to non-standard things need to be extensions. In so doing, fully compatible C compilers can be created which target the core. This makes them smaller and easier to understand as compiler authors, developers in general, and new users coming to the language. Then, for those who are seeking additional training or knowledge, they can enter in to the extensions which are import to them on their architectures, rather than having to be inundated by the entirety of it all at one go. I recognize other people do not subscribe to this idea. I do. And it will be the driving force in my endeavors moving forward. I would like to see it incorporated into C, but I hold only remote hope of that ever happening. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-27 14:11 +0100 |
| Message-ID | <87k2upguss.fsf@bsb.me.uk> |
| In reply to | #64290 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: <snip> > My position is here: > > Core C needs to be the smaller core. Extensions out to non-standard > things need to be extensions. This terminology is not at all clear. What is smaller? More rules? Fewer restrictions? More features? Less latitude given to compiler writers? More latitude? Answering the following questions might me understand: (1) Are all valid "core C" programs valid ISO standard C programs (with the same semantics, of course)? (2) Are all ISO standard C programs, valid "core C" programs? Given that the answers are not both going to be "yes", please show a few of programs (a line or two is enough) that are outside the common intersection of valid "core C" programs and valid ISO C programs. <snip> > I recognize other people do not subscribe to this idea. I do. > And it will be the driving force in my endeavors moving forward. To be clear: the driving focus will be on developing a new, bigger, language (one with more features than C) called RDC, yes? And this language currently has no specification, yes? I ask because a specification of RDC might help explain this mysterious "core C". <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-27 06:38 -0700 |
| Message-ID | <cf506977-bc7e-4109-b60a-ba1f8044cee9@googlegroups.com> |
| In reply to | #64292 |
[As a prefix, exerting effort to get these things changed in C is a
very low priority for me. I post this to answer your questions, but
it is not a political movement, nor is it even a significant concern
of mine any longer (because of my work on RDC).]
On Saturday, June 27, 2015 at 9:11:56 AM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> > My position is here:
> > Core C needs to be the smaller core. Extensions out to non-standard
> > things need to be extensions.
>
> This terminology is not at all clear. What is smaller? More rules?
> Fewer restrictions? More features? Less latitude given to compiler
> writers? More latitude?
It means fewer allowances for arcane features. I don't have a
comprehensive list, but off the top of my head and for starters:
(1) Everything is little-endian (or big-endian, doesn't matter, but
only one them is supported in the standard).
(2) Everything is two's complement.
(3) char = 8 bits, short = 16 bits, int = 32 bits, long = 32 bits,
long long = 64 bits, and all of those names are deprecated or
flatly deleted from the core language (with them being allowed
back with #defines), and in their place the forms s8,s16,s32,s64
are introduced, with u8,u16,u32,u64 for unsigned values, with
f32 and f64 being provided for float and double.
I also propose a new "flag" variable type, which is a one-bit
value the compiler will reference for boolean values. They are
also set with Yes/No, Up/Down, On/Off keyword names, rather than
1 or 0.
Any sizes beyond these are reserved for definition in the known
extensions, or in the unlimited world of custom extensions.
(4) All pointers are the same size.
(5) All comparisons between different-signed values are upsized to
the largest signed value which guarantees an appropriate compare.
This may include upsizing to a double.
> Answering the following questions might me understand:
>
> (1) Are all valid "core C" programs valid ISO standard C programs
> (with the same semantics, of course)?
No idea what that sentence means.
> (2) Are all ISO standard C programs, valid "core C" programs?
I don't know but I doubt it. The changes to "core C" I'm proposing
change some fundamental "roots" of C, which would make even the
simple "hello world" programs no longer compile without changes
(changing int to s32, for example).
> Given that the answers are not both going to be "yes", please show
> a few of programs (a line or two is enough) that are outside the
> common intersection of valid "core C" programs and valid ISO C
> programs.
The amount of time required for me to do this would be out of
proportion to my interest in the matter.
> <snip>
> > I recognize other people do not subscribe to this idea. I do.
> > And it will be the driving force in my endeavors moving forward.
>
> To be clear: the driving focus will be on developing a new, bigger,
> language (one with more features than C) called RDC, yes? And this
> language currently has no specification, yes? I ask because a
> specification of RDC might help explain this mysterious "core C".
RDC provides additional features for developers, but it is wrapped
around a very simple core.
The specs have been published on clc before:
https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/compiler/rdc/rdc_specs.txt
They are relatively solidified in content. A few things are
still in flux, or being refined as I progress in the compiler's
development. But what is there will be largely what there will
be ... except that I will eventually provide switches to make
it fully compatible with various C standards as they exist
today. It's only a matter of resources to do so as I do have
the interest, drive, and desire.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2015-06-27 13:55 +0000 |
| Message-ID | <mmma0p$erd$1@news.xmission.com> |
| In reply to | #64294 |
In article <cf506977-bc7e-4109-b60a-ba1f8044cee9@googlegroups.com>, Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: ... >It means fewer allowances for arcane features. I don't have a >comprehensive list, but off the top of my head and for starters: > >(1) Everything is little-endian (or big-endian, doesn't matter, but > only one them is supported in the standard). This would have been a problem back in the day - when the two main contenders were x86 and Sparc, which have different endianness. >(2) Everything is two's complement. As for the rest of these, it looks like you want POSIX. And, yes, there's a lot that says that people should be programming to the POSIX standard(s), not to the C standard(s). Except for the existence of this small, insignificant company in Redmond, WA... You see the parallel? If it hadn't been for the existence of x86 (and some small, insignificant company in Oregon), we'd probably all be big-endian and that would be that. And if it hadn't been for Windows, we'd probably all be POSIX and that would be that. -- Just for a change of pace, this sig is *not* an obscure reference to comp.lang.c...
[toc] | [prev] | [next] | [standalone]
Page 17 of 23 — ← Prev page 1 … 15 16 [17] 18 19 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web