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 16 of 23 — ← Prev page 1 … 14 15 [16] 17 18 … 23 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-27 09:10 -0700 |
| Subject | Re: [OT] was Re: typedef forward declaration |
| Message-ID | <a2706db0-c60d-4e83-9cb6-a93325d6b2e4@googlegroups.com> |
| In reply to | #64305 |
Geoff, you see in things which run contrary to Biblical teachings of Jesus Christ the nature of sin, and the death present in sin. Such is not God, nor the act of born again believers. It is the death, in sin, manifested in our lives here on the Earth, and it is of Satan's lead, not God's. Do not let Satan's use of sinful men professing to do things in the name of Jesus Christ keep you from approaching Him yourself. There are a lot of sinful men out there doing sinful things to their own destruction, but the relationship between a person and God is personal, 1:1, and all who are born again will be as He is, the ignorance and inertia of their former life notwithstanding. Jesus literally gives men new life. Life eternal. Taste and see for yourself. You will find in Jesus a man who is not like other men, because He is God. His sacrifice at the cross will rattle your soul, and shake everything about your life. When you meet Him, you will never be the same again. He changes everything because He brings new life. Love you. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-27 11:25 -0700 |
| Subject | Re: [OT] was Re: typedef forward declaration |
| Message-ID | <lnpp4hf1ph.fsf@kst-u.example.com> |
| In reply to | #64287 |
raltbos@xs4all.nl (Richard Bos) writes:
> David Kleinecke <dkleinecke@gmail.com> wrote:
>> Technically he is not a troll but his sermon is completely under the
>> bridge. His theology is tendentious and, IMO, very incorrect
>
> Entirely incorrect, but unfortunately very typical of USA-specific
> nutjobs. I'm just grateful we barely have any of this kind of
> not-actually-Christianity over here in the civilised world.
*Please* don't feed the troll. (Or technically-not-a-troll, or
whatever; the effect is the same.) Your opinions about Christianity
are no more or less topical here than his, and you are directly
and indirectly harming the signal-to-noise ratio of this newsgroup.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-26 08:56 -0700 |
| Subject | Re: [OT] was Re: typedef forward declaration |
| Message-ID | <lna8vmh39q.fsf@kst-u.example.com> |
| In reply to | #64219 |
David Brown <david.brown@hesbynett.no> writes:
> On 26/06/15 14:01, Rick C. Hodgin wrote:
[SNIP]
> I know I shouldn't reply here, but I can't resist it.
*Please* try harder. Rick posts with what appears to be a valid
e-mail address; if you wanted to debate theology with him, you
could use it and spare the rest of us. (I've already tried asking
Rick not to post his off-topic stuff, and it hasn't worked, so all
I can do is ignore him.)
[SNIP]
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-27 22:05 +0200 |
| Subject | Re: [OT] was Re: typedef forward declaration |
| Message-ID | <mmmvkg$ibq$1@dont-email.me> |
| In reply to | #64239 |
On 26/06/15 17:56, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 26/06/15 14:01, Rick C. Hodgin wrote: > [SNIP] >> I know I shouldn't reply here, but I can't resist it. > > *Please* try harder. Rick posts with what appears to be a valid > e-mail address; if you wanted to debate theology with him, you > could use it and spare the rest of us. (I've already tried asking > Rick not to post his off-topic stuff, and it hasn't worked, so all > I can do is ignore him.) > I'm sorry, and I will not reply to his non-technical posts again. I had hoped that when he came back here after his recent absence, he might have changed - but I was clearly wrong.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-25 12:46 -0400 |
| Message-ID | <558C3069.2000303@verizon.net> |
| In reply to | #64121 |
On 06/25/2015 09:15 AM, Richard Heathfield wrote: > On 25/06/15 13:51, Rick C. Hodgin wrote: >> On Wednesday, June 24, 2015 at 5:13:58 PM UTC-4, James Kuyper wrote: >>> On 06/24/2015 05:01 PM, David Brown wrote: >>>> On 24/06/15 17:47, Rick C. Hodgin wrote: >>> ... >>>>> C tolerates self-modifying code. >>> >>> There is no such thing as C code that has, as it's standard-defined >>> behavior, modification of the code itself. Any C construct that might >>> reasonably have such a consequence necessarily has undefined behavior, >>> which is the worst thing the C standard says about any code construct. >> >> I was referring to the ability to self-modify a program using only C >> code at runtime, provided you have externally created the opcodes >> needed, stored them to some location, and basically do a memcpy. >> >> But as far as the ability to use some kind of syntax which dynamically >> modifies code at runtime, obviously no such creature exists. The syntax exists, there's just nothing in the standard to suggest that it would have the desired effect. All the standard says about it is that it has undefined behavior - which includes, as one possibility, that it would actually work as expected. I've known people who were actually surprised that it didn't work as they expected it to: unsigned char *pcode = (unsigned char*)function_name; pcode[expected_offset] = modified_op_code; I've even used systems where (I think - I never tested it) it would have worked (for suitable values of expected_offset and modified_op_code).
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-25 10:00 -0700 |
| Message-ID | <b903b9a6-4eea-4dc8-a70c-df22b45536db@googlegroups.com> |
| In reply to | #64136 |
On Thursday, June 25, 2015 at 12:46:41 PM UTC-4, James Kuyper wrote: > On 06/25/2015 09:15 AM, Richard Heathfield wrote: > > On 25/06/15 13:51, Rick C. Hodgin wrote: > >> On Wednesday, June 24, 2015 at 5:13:58 PM UTC-4, James Kuyper wrote: > >>> On 06/24/2015 05:01 PM, David Brown wrote: > >>>> On 24/06/15 17:47, Rick C. Hodgin wrote: > >>> ... > >>>>> C tolerates self-modifying code. > >>> > >>> There is no such thing as C code that has, as it's standard-defined > >>> behavior, modification of the code itself. Any C construct that might > >>> reasonably have such a consequence necessarily has undefined behavior, > >>> which is the worst thing the C standard says about any code construct. > >> > >> I was referring to the ability to self-modify a program using only C > >> code at runtime, provided you have externally created the opcodes > >> needed, stored them to some location, and basically do a memcpy. > >> > >> But as far as the ability to use some kind of syntax which dynamically > >> modifies code at runtime, obviously no such creature exists. > > The syntax exists, there's just nothing in the standard to suggest that > it would have the desired effect. All the standard says about it is that > it has undefined behavior - which includes, as one possibility, that it > would actually work as expected. I've known people who were actually > surprised that it didn't work as they expected it to: > > unsigned char *pcode = (unsigned char*)function_name; > pcode[expected_offset] = modified_op_code; > > I've even used systems where (I think - I never tested it) it would have > worked (for suitable values of expected_offset and modified_op_code). That's basic data copying. I'm talking about some kind of actual C syntax whereby you declare in source code that the source code contained within a function is modified in this way or that way based on a runtime examination of the environment, and the code generated by the compiler does that for you. In your example, the developer himself must code that methodology. You can't use some type of #selfmodify directive with various #selfelse blocks based on other tests, and then performs that last runtime compilation or code adjustment / tweaking. It's amazing posting to this group. It's unlike other things I've encountered in my life. The replies I read routinely cause me to drop my jaw and literally say out loud, "Seriously?" Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-06-28 10:58 +0000 |
| Message-ID | <558fcffb.5047046@news.xs4all.nl> |
| In reply to | #64119 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: > On Wednesday, June 24, 2015 at 5:13:58 PM UTC-4, James Kuyper wrote: > > On 06/24/2015 05:01 PM, David Brown wrote: > > > On 24/06/15 17:47, Rick C. Hodgin wrote: > > ... > > >> C tolerates self-modifying code. > > > > There is no such thing as C code that has, as it's standard-defined > > behavior, modification of the code itself. Any C construct that might > > reasonably have such a consequence necessarily has undefined behavior, > > which is the worst thing the C standard says about any code construct. > > I was referring to the ability to self-modify a program using only C > code at runtime, provided you have externally created the opcodes > needed, stored them to some location, and basically do a memcpy. Good luck trying to do that on a Z80, for any sizable amount of code. Where "sizable" means: "more than 256 bytes"... > But as far as the ability to use some kind of syntax which dynamically > modifies code at runtime, obviously no such creature exists. Well, then. What's the difference, in this regard, between "self-modifying a program" and the famous "demons flying out of your nose"? In both cases, you can only get there using undefined behaviour. In both cases, you need significant support from the system _beyond_ the C language. In both cases, there is nothing in C _itself_ which explicitly caters for it. In both cases, there is nothing in C which explicitly forbids it, either; in both cases, this is because it makes no sense to forbid something _you_ aren't providing the facilities for. C "tolerates" self-modifying code the same way > I do disagree with many aspects of the C standard > because it is, as Keith has indicated, targeted at real-world applications > which need to run on real-world equipment. And whereas I agree that > those should be targets, they should not be paramount. The needs of > people, and of people's thinking, should be paramount. 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_. Richard
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-28 04:03 -0700 |
| Message-ID | <ff631aaa-35c8-49a0-ad1b-857cb6bbbb84@googlegroups.com> |
| In reply to | #64346 |
Richard Bos wrote: > Then you're simply wrong. C, as a language, > was created specifically _for_ practical, > everyday programming purposes. That's why I want the changes. I want it altered to support less wide hardware in core C, and to then use extensions for support of other hardware. It's a change from how it is today that I'm pursuing. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-28 12:43 +0100 |
| Message-ID | <87lhf4f47u.fsf@bsb.me.uk> |
| In reply to | #64349 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > Richard Bos wrote: >> Then you're simply wrong. C, as a language, >> was created specifically _for_ practical, >> everyday programming purposes. > > That's why I want the changes. I want it altered > to support less wide hardware in core C, and to > then use extensions for support of other hardware. > > It's a change from how it is today that I'm > pursuing. I thought you weren't pursuing that anymore. I thought that was why you did not answer the C-specific part of my last reply to you. If are pursuing it, please answer: what should happen on a big-endian machine? No "core C" implementation, or a slow one that emulates little-endian hardware? (And so one for the other specifics you gave.) I'd like to see what (if anything) I, as a programmer, would gain from this purposed change. If you are not going to pursue it, that's fine too. Just please stop saying that you are (and it would help if you stopped talking about it too since that looks very much like pursuing it and it's a bit rude to talk about something you won't discuss). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-28 06:05 -0700 |
| Message-ID | <a30c7c24-c06e-4e0b-b0d2-e27bc6c8e241@googlegroups.com> |
| In reply to | #64350 |
On Sunday, June 28, 2015 at 7:43:43 AM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> > Richard Bos wrote:
> >> Then you're simply wrong. C, as a language,
> >> was created specifically _for_ practical,
> >> everyday programming purposes.
> >
> > That's why I want the changes. I want it altered
> > to support less wide hardware in core C, and to
> > then use extensions for support of other hardware.
> >
> > It's a change from how it is today that I'm
> > pursuing.
>
> I thought you weren't pursuing that anymore.
(1) It's not that I'm not pursuing it anymore. It's just that I
(2) have very little interest, drive, passion, in pursuing it, or
even hope that it will ever be received. So it's
(3) been pushed to the back burner and turned down on low heat.
> I thought that was why you did not answer the C-specific part of
> my last reply to you.
Incorrect (in that I am not pursuing it at all), but partially correct
(in that I am still pursuing it, just with little interest).
> If are pursuing it, please answer: what should happen on a big-endian
> machine?
It would be big-endian, and use a big-endian compiler extension
(assuming the standard was little-endian, but the same would be true
in the reverse case).
> No "core C" implementation
No "core C" implementation. It would be an "extension C" implementation.
> or a slow one that emulates little-endian hardware? (And so one for
> the other specifics you gave.)
No emulation. Native hardware abilities at full speed.
> I'd like to see what (if anything) I, as a programmer, would gain
> from this purposed change.
You? Little if any. Developers, they would have a much smaller,
tighter language to learn initially. Compiler writers would have
a smaller framework to deal with for core C, and would have an
implementation in the core C virtual machine which would be a
starting point for then implementing features of newer / different
architectures. They would also be able to look at the diffs
between core C and the extensions made to another big-endian
machine, for example, and use portions of that code, if not all.
> If you are not going to pursue it, that's fine too. Just please stop
> saying that you are (and it would help if you stopped talking about it
> too since that looks very much like pursuing it and it's a bit rude to
> talk about something you won't discuss).
I'm amazed such a concept as my state in this matter eludes you.
(1) I was responding to his comment regarding my purpose which
existed at the time of the post he cited. My purpose at that
time was this pursuit.
(2) Even in my previous response to you I did not indicate I wasn't
interested in pursuing it, just that my interest level was low.
If, for example, a neighbor dropped by and asked me if I wanted
to come see his two-year old son's latest fingerpaint drawing,
I would forego my "core C" pursuits in favor of viewing the
masterpiece.
> --
> Ben.
Now, if you'll permit me:
Ben Ben, bo en.
Banana fana fo fen.
Fe fi mo men. B-en.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-28 06:33 -0700 |
| Message-ID | <602c0b01-e18d-42b2-89ee-c6f82b81f108@googlegroups.com> |
| In reply to | #64361 |
On Sunday, June 28, 2015 at 9:05:23 AM UTC-4, Rick C. Hodgin wrote: > Now, if you'll permit me: > > Ben Ben, bo en. > Banana fana fo fen. > Fe fi mo men. B-en. My wife tells me this may be in bad taste. If so, I apologize. I was sending this out to people at my work in their email last week and it's just stuck with me. No offense intended. Just a little humor. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-28 18:28 +0100 |
| Message-ID | <871tgvg2so.fsf@bsb.me.uk> |
| In reply to | #64367 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Sunday, June 28, 2015 at 9:05:23 AM UTC-4, Rick C. Hodgin wrote: >> Now, if you'll permit me: >> >> Ben Ben, bo en. >> Banana fana fo fen. >> Fe fi mo men. B-en. > > My wife tells me this may be in bad taste. It looked to me aribtrary and absurd and so I had no view on its tastefulness (or otherwise). Anyway, the internet being what it is, I was able to do decode the reference and all I can say is that we listened to very different music in the 60s! > If so, I apologize. > I was sending this out to people at my work in their email last > week and it's just stuck with me. No offense intended. Just a > little humor. None taken (either offence or humour!). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-28 10:42 -0700 |
| Message-ID | <048baba8-f249-4915-a2ac-05e87895ce53@googlegroups.com> |
| In reply to | #64382 |
Ben Bacarisse wrote: > ...all I can say is that we listened to very > different music in the 60s! My age was measured in months in the 60s. :-) However, in the late 70s and early 80s when I would go to roller skating rinks or various sports games, songs like this were played for fun. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-28 18:17 +0100 |
| Message-ID | <877fqng3c3.fsf@bsb.me.uk> |
| In reply to | #64361 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Sunday, June 28, 2015 at 7:43:43 AM UTC-4, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> > Richard Bos wrote: >> >> Then you're simply wrong. C, as a language, >> >> was created specifically _for_ practical, >> >> everyday programming purposes. >> > >> > That's why I want the changes. I want it altered >> > to support less wide hardware in core C, and to >> > then use extensions for support of other hardware. >> > >> > It's a change from how it is today that I'm >> > pursuing. >> >> I thought you weren't pursuing that anymore. > > (1) It's not that I'm not pursuing it anymore. It's just that I > (2) have very little interest, drive, passion, in pursuing it, or > even hope that it will ever be received. So it's > (3) been pushed to the back burner and turned down on low heat. > >> I thought that was why you did not answer the C-specific part of >> my last reply to you. > > Incorrect (in that I am not pursuing it at all), but partially correct > (in that I am still pursuing it, just with little interest). > >> If are pursuing it, please answer: what should happen on a big-endian >> machine? > > It would be big-endian, and use a big-endian compiler extension > (assuming the standard was little-endian, but the same would be true > in the reverse case). > >> No "core C" implementation > > No "core C" implementation. It would be an "extension C" implementation. > >> or a slow one that emulates little-endian hardware? (And so one for >> the other specifics you gave.) > > No emulation. Native hardware abilities at full speed. Right. That's really all I wanted to know. I now see that if all the permitted "extensions" are documented and just cover all the things you don't like about the current C standard (you don't say and I won't ask), then "core C + extensions" is just C as we know it today and I would be able to get the same portability by writing to that standard. "Core C" is just C without anything that would surprise an Intel aficionado. Lot's of people used to write a form of "core C" (my job was once to fix such code) but in those days it meant C without the bits that would surprise a VAX aficionado. >> I'd like to see what (if anything) I, as a programmer, would gain >> from this purposed change. > > You? Little if any. Developers, they would have a much smaller, > tighter language to learn initially. Not if they wanted to write portable code. They have to know what extensions they might hit on all those systems that don't have "core C only" compilers and that might be the same size of language as C currently is. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-28 10:32 -0700 |
| Message-ID | <b7bdd676-05eb-4400-bbda-d5755c73441a@googlegroups.com> |
| In reply to | #64381 |
Ben Bacariase wrote: > Not if they wanted to write portable code. > They have to know what extensions they > might hit on all those systems that don't > have "core C only" compilers and that might > be the same size of language as C currently is. Write to the core C virtual machine if you're worried about portability. Write to the peculiarities of the machine if you're worried about performance. Write to the standard variable type names which are #defined to be that which is needed on each machine if you're worried about both. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-28 20:53 +0100 |
| Message-ID | <87ioa7ehds.fsf@bsb.me.uk> |
| In reply to | #64383 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> Ben Bacariase wrote:
>> Not if they wanted to write portable code.
>> They have to know what extensions they
>> might hit on all those systems that don't
>> have "core C only" compilers and that might
>> be the same size of language as C currently is.
>
> Write to the core C virtual machine if you're
> worried about portability.
I can't square this with your other remarks. Core C specifies
little-endian, but you tell me that there is no emulation on hardware
that is big-endian. With any core C compiler, given
int f(int x) { return *(char *)&x; }
presumably f(1) returns 1. That is a supposed benefit of core C -- I
know what this code will do. But you seem to have said that I can't
write that and expect the same result on a big-endian machine because it
need not bend over backwards to pretend to have another byte order. So
what does "write to the core C virtual machine" actually mean? Does it
mean I can assume that f(x) == 1 on all machines with Rick's c compiler
and I should just forget about big-endian machines, or does it mean I
must assume that f(x) may or may not be 1, just as I have to do now,
because the core C virtual machine does not guarantee anything about
byte order (just like the current definition of C).
> Write to the peculiarities of the machine if you're worried about
> performance. Write to the standard variable type names which are
> #defined to be that which is needed on each machine if you're worried
> about both.
You said "no emulation", so I assumed this meant that on my trusty old
mainframe with 36-bit integers the type i23 will simply not be defined.
What is the type to use when I want portability, and what can I assume
about it (the type I should use) on all "core C with extensions"
implementations?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-28 17:53 -0700 |
| Message-ID | <be5ae82d-a418-42c1-bcee-e9a04e85a820@googlegroups.com> |
| In reply to | #64391 |
On Sunday, June 28, 2015 at 3:56:53 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> > Ben Bacariase wrote:
> >> Not if they wanted to write portable code.
> >> They have to know what extensions they
> >> might hit on all those systems that don't
> >> have "core C only" compilers and that might
> >> be the same size of language as C currently is.
> >
> > Write to the core C virtual machine if you're
> > worried about portability.
>
> I can't square this with your other remarks. Core C specifies
> little-endian, but you tell me that there is no emulation on
> hardware that is big-endian. With any core C compiler, given
>
> int f(int x)
> {
> return(*(char*)&x);
> }
>
> presumably f(1) returns 1. That is a supposed benefit of core C -- I
> know what this code will do. But you seem to have said that I can't
> write that and expect the same result on a big-endian machine because
> it need not bend over backwards to pretend to have another byte order.
If you write to the virtual machine, the virtual machine will access
its memory using little-endian regardless of the host platform. That's
why I say if you want portability, write for the VM.
> So what does "write to the core C virtual machine" actually mean?
In the Core C definition, there would be defined a virtual machine
that would be provided from the Core C group. They would write the
VM, and the compiler, and prayerfully the debugger and editor as
well, and then release it all as a bundled package for each
version. A person would be able to run the ccc (Core C Compiler)
version inside the ccvm (Core C Virtual Machine) and access machine
resources through an API which provided for all of its UI abilities
much like a graphical terminal.
Program designed and coded for Core C would always run correctly in
the VM regardless of the host machine.
> Does
> it mean I can assume that f(x) == 1 on all machines with Rick's c compiler
> and I should just forget about big-endian machines, or does it mean I
> must assume that f(x) may or may not be 1, just as I have to do now,
> because the core C virtual machine does not guarantee anything about
> byte order (just like the current definition of C).
If you are running on the native machine, the hardware providers or OS
devs or some enthusiast group devs for that machine would've provided
a version of the Core C Compiler which extends its definition out into
extended C support, whereby they now support big-endian. In that case,
you would need to pay attention to your endian need on the native
hardware.
To bypass that requirement, you would write your code for the VM, and
then run your code in there always assuming little-endian regardless
of the host's facilities.
> > Write to the peculiarities of the machine if you're worried about
> > performance. Write to the standard variable type names which are
> > #defined to be that which is needed on each machine if you're
> > worried about both.
>
> You said "no emulation", so I assumed this meant that on my trusty old
> mainframe with 36-bit integers the type i23 will simply not be defined.
I assume you mean "s32"? But regardless, it depends on how the port to
that native machine was implemented. In Core C there are certain 8-bit
forms (and 16-bit, 32-bit, 64-bit) which are defined, and the host
hardware will work to present that ability. However, in extended C,
the full abilities of the machine are exposed and on that version of
the compiler, new types would exist. An s36 and u36 would presumably
be available, which you could #define into an int or whatever.
> What is the type to use when I want portability, and what can I assume
> about it (the type I should use) on all "core C with extensions"
> implementations?
Core C's virtual machine will give you portability. You are in that
case always writing for a little-endian two's complement machine with
equal sized pointers and standard 8-bit-based n-multiple variable
types.
Easy peasy for all the app developers out there. A bit of work for
the compiler developers, but not much once the Core C group develops
and releases the prototype. Then it's just adding on modules to the
core as needed to address the extensions on each peculiar machine,
or recompiling the VM to run on the host hardware with its peculiar
abilities.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-29 12:10 +0100 |
| Message-ID | <871tguepn6.fsf@bsb.me.uk> |
| In reply to | #64401 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Sunday, June 28, 2015 at 3:56:53 PM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> > Ben Bacariase wrote:
>> >> Not if they wanted to write portable code.
>> >> They have to know what extensions they
>> >> might hit on all those systems that don't
>> >> have "core C only" compilers and that might
>> >> be the same size of language as C currently is.
>> >
>> > Write to the core C virtual machine if you're
>> > worried about portability.
>>
>> I can't square this with your other remarks. Core C specifies
>> little-endian, but you tell me that there is no emulation on
>> hardware that is big-endian. With any core C compiler, given
>>
>> int f(int x)
>> {
>> return(*(char*)&x);
>> }
I did not write that. Please don't edit other people's words when
quoting.
>> presumably f(1) returns 1. That is a supposed benefit of core C -- I
>> know what this code will do. But you seem to have said that I can't
>> write that and expect the same result on a big-endian machine because
>> it need not bend over backwards to pretend to have another byte order.
>
> If you write to the virtual machine, the virtual machine will access
> its memory using little-endian regardless of the host platform. That's
> why I say if you want portability, write for the VM.
>
>> So what does "write to the core C virtual machine" actually mean?
>
> In the Core C definition, there would be defined a virtual machine
> that would be provided from the Core C group. They would write the
> VM, and the compiler, and prayerfully the debugger and editor as
> well, and then release it all as a bundled package for each
> version. A person would be able to run the ccc (Core C Compiler)
> version inside the ccvm (Core C Virtual Machine) and access machine
> resources through an API which provided for all of its UI abilities
> much like a graphical terminal.
>
> Program designed and coded for Core C would always run correctly in
> the VM regardless of the host machine.
That seems to contradict your statement before about there being no
requirement to emulate core C features on hardware that does not match
the core specification. But I now like your suggesting even less
because there are lots of languages that have an expensive VM and I
don't want C to be yet another.
>> Does
>> it mean I can assume that f(x) == 1 on all machines with Rick's c compiler
>> and I should just forget about big-endian machines, or does it mean I
>> must assume that f(x) may or may not be 1, just as I have to do now,
>> because the core C virtual machine does not guarantee anything about
>> byte order (just like the current definition of C).
>
> If you are running on the native machine, the hardware providers or OS
> devs or some enthusiast group devs for that machine would've provided
> a version of the Core C Compiler which extends its definition out into
> extended C support, whereby they now support big-endian. In that case,
> you would need to pay attention to your endian need on the native
> hardware.
>
> To bypass that requirement, you would write your code for the VM, and
> then run your code in there always assuming little-endian regardless
> of the host's facilities.
Or we could leave C alone and have one language specification and no
costly VM.
>> > Write to the peculiarities of the machine if you're worried about
>> > performance. Write to the standard variable type names which are
>> > #defined to be that which is needed on each machine if you're
>> > worried about both.
>>
>> You said "no emulation", so I assumed this meant that on my trusty old
>> mainframe with 36-bit integers the type i23 will simply not be defined.
>
> I assume you mean "s32"? But regardless, it depends on how the port to
> that native machine was implemented. In Core C there are certain 8-bit
> forms (and 16-bit, 32-bit, 64-bit) which are defined, and the host
> hardware will work to present that ability. However, in extended C,
> the full abilities of the machine are exposed and on that version of
> the compiler, new types would exist. An s36 and u36 would presumably
> be available, which you could #define into an int or whatever.
>
>> What is the type to use when I want portability, and what can I assume
>> about it (the type I should use) on all "core C with extensions"
>> implementations?
>
> Core C's virtual machine will give you portability. You are in that
> case always writing for a little-endian two's complement machine with
> equal sized pointers and standard 8-bit-based n-multiple variable
> types.
I want a fast type but, as is so often the case, I don't care if it's
32, 36 or 60 bits. What do I do in your supposedly better C? s32 will
be a simulated type on 36-bit hardware and I don't want that cost. But
I don't want to have to keep changing the code (or use a pile of
conditionals) when it moves from one place to another.
> Easy peasy for all the app developers out there.
Sure. That's why people like Java. It's good, but it's not C.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-29 04:59 -0700 |
| Message-ID | <3a34b69b-5db6-49f1-b5ae-a13c694e5ecf@googlegroups.com> |
| In reply to | #64437 |
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:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> > Ben Bacariase wrote:
> >> >> Not if they wanted to write portable code.
> >> >> They have to know what extensions they
> >> >> might hit on all those systems that don't
> >> >> have "core C only" compilers and that might
> >> >> be the same size of language as C currently is.
> >> >
> >> > Write to the core C virtual machine if you're
> >> > worried about portability.
> >>
> >> I can't square this with your other remarks. Core C specifies
> >> little-endian, but you tell me that there is no emulation on
> >> hardware that is big-endian. With any core C compiler, given
> >>
> >> 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.
> >> presumably f(1) returns 1. That is a supposed benefit of core C -- I
> >> know what this code will do. But you seem to have said that I can't
> >> write that and expect the same result on a big-endian machine because
> >> it need not bend over backwards to pretend to have another byte order.
> >
> > If you write to the virtual machine, the virtual machine will access
> > its memory using little-endian regardless of the host platform. That's
> > why I say if you want portability, write for the VM.
> >
> >> So what does "write to the core C virtual machine" actually mean?
> >
> > In the Core C definition, there would be defined a virtual machine
> > that would be provided from the Core C group. They would write the
> > VM, and the compiler, and prayerfully the debugger and editor as
> > well, and then release it all as a bundled package for each
> > version. A person would be able to run the ccc (Core C Compiler)
> > version inside the ccvm (Core C Virtual Machine) and access machine
> > resources through an API which provided for all of its UI abilities
> > much like a graphical terminal.
> >
> > Program designed and coded for Core C would always run correctly in
> > the VM regardless of the host machine.
>
> That seems to contradict your statement before about there being no
> requirement to emulate core C features on hardware that does not match
> the core specification.
I don't think I ever said that, but if I did there was a misunderstanding
there. While there is no requirement to emulate anything in Core C, it
is defined to be Core C. So when it is not included in a target
implementation of the compiler, it will be so noted in the extensions it
has.
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.
> But I now like your suggesting even less
> because there are lots of languages that have an expensive VM and I
> don't want C to be yet another.
>
> >> Does
> >> it mean I can assume that f(x) == 1 on all machines with Rick's c compiler
> >> and I should just forget about big-endian machines, or does it mean I
> >> must assume that f(x) may or may not be 1, just as I have to do now,
> >> because the core C virtual machine does not guarantee anything about
> >> byte order (just like the current definition of C).
> >
> > If you are running on the native machine, the hardware providers or OS
> > devs or some enthusiast group devs for that machine would've provided
> > a version of the Core C Compiler which extends its definition out into
> > extended C support, whereby they now support big-endian. In that case,
> > you would need to pay attention to your endian need on the native
> > hardware.
> >
> > To bypass that requirement, you would write your code for the VM, and
> > then run your code in there always assuming little-endian regardless
> > of the host's facilities.
>
> Or we could leave C alone and have one language specification and no
> costly VM.
Not too costly. And for what you gain in saving every developer the
need to port non-performance-critical code to other hardware, it's a
total bargain.
> >> > Write to the peculiarities of the machine if you're worried about
> >> > performance. Write to the standard variable type names which are
> >> > #defined to be that which is needed on each machine if you're
> >> > worried about both.
> >>
> >> You said "no emulation", so I assumed this meant that on my trusty old
> >> mainframe with 36-bit integers the type i23 will simply not be defined.
> >
> > I assume you mean "s32"? But regardless, it depends on how the port to
> > that native machine was implemented. In Core C there are certain 8-bit
> > forms (and 16-bit, 32-bit, 64-bit) which are defined, and the host
> > hardware will work to present that ability. However, in extended C,
> > the full abilities of the machine are exposed and on that version of
> > the compiler, new types would exist. An s36 and u36 would presumably
> > be available, which you could #define into an int or whatever.
> >
> >> What is the type to use when I want portability, and what can I assume
> >> about it (the type I should use) on all "core C with extensions"
> >> implementations?
> >
> > Core C's virtual machine will give you portability. You are in that
> > case always writing for a little-endian two's complement machine with
> > equal sized pointers and standard 8-bit-based n-multiple variable
> > types.
>
> I want a fast type but, as is so often the case, I don't care if it's
> 32, 36 or 60 bits. What do I do in your supposedly better C?
Use the "int" define which was created by those who ported Core C to
your hardware. They will have mapped it onto the best candidate.
> s32 will be a simulated type on 36-bit hardware and I don't want
> that cost. But I don't want to have to keep changing the code (or
> use a pile of conditionals) when it moves from one place to another.
Use int.
> > Easy peasy for all the app developers out there.
>
> Sure. That's why people like Java. It's good, but it's not C.
I'm talking about Core C virtual machine. Smaller and tighter than
Java, and one which directly leverages the machine's abilities
through a well-defined API which allows extensions to address unique
things on peculiar machines.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-29 14:21 +0100 |
| Message-ID | <87vbe6d50f.fsf@bsb.me.uk> |
| In reply to | #64438 |
"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.
<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.
(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.)
<snip more stuff that does not matter now>
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 16 of 23 — ← Prev page 1 … 14 15 [16] 17 18 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web