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 11 of 23 — ← Prev page 1 … 9 10 [11] 12 13 … 23 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-23 16:40 +0200 |
| Message-ID | <mmbr27$lpf$1@dont-email.me> |
| In reply to | #63921 |
On 23/06/15 15:37, Richard Heathfield wrote: > On 23/06/15 14:00, Rick C. Hodgin wrote: >> On Monday, June 22, 2015 at 5:38:39 PM UTC-4, Keith Thompson wrote: >>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >>> > On Monday, June 22, 2015 at 4:16:10 PM UTC-4, Keith Thompson wrote: >>> >> Why? What specific problem would such a definition solve? >>> > >>> > It's one of those things ... if I have to explain it to you, it's >>> > likely you won't understand it even when explained. >>> >>> Are you saying that if I disagree with you it must be because I'm >>> unable to understand your position? >> >> No. However, if you don't already understand it, then it's likely you >> won't be able to because you place emphasis on different things than >> I do. > > In my experience, Keith thinks that sound technical arguments carry more > weight than personal opinions. "Don't X because Y (see Z part of > Standard)" carries more weight than "I don't think X is the right thing > to do". > I'd go further than that and say "Don't X because Y" carries more weight than "I don't think X is the right thing to do". /Any/ technical 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. > <snip> > >> However, I place priorities on different things. I look to the human >> being and their natural way of thinking. I try to make the machine >> do for people what people need, rather than giving to people what the >> machine is doing. > > Okay, that's fair enough. But according to my natural way of thinking, > people don't need pointer sizes to be uniform. So why cause a lot of > people a lot of work by lobbying for that uniformity? When people talk about "natural way of thinking" or "from the human viewpoint", they invariably mean "/my/ way of thinking" and "from /my/ viewpoint". It can't be avoided. Obviously it is fair enough to discuss things from one's own viewpoint. And for RDC, it is clearly Rick's personal viewpoint that is most important, as it is his language. But when considering something like the C standards, a wider range of viewpoints must be taken - including machines (of many sorts), compiler implementers, standards authors, as well as human programmers (and the odd non-human programmer). > >> It's what I mean when I say that if you don't already understand it, >> you likely won't be able to (because the inertia of your present >> thinking will overshadow this idea). > > I have greater faith in Keith's objectivity than you do, and I'm sure > he's capable of understanding your idea, but that doesn't mean he has to > agree with it. What he is saying, and what I am saying, is that your > proposal to make pointer sizes uniform addresses a non-existent problem. > I have never, ever, /ever/ been caused extra work by the possibility > that pointers might be different sizes. Have you? > I have only worked with one system with non-uniform pointer sizes - avr-gcc has support for generic 24-bit pointers as well as 16-bit pointers to different address spaces (the AVR is an 8-bit microcontroller with Harvard architecture. And while it's usage is in the decline, it is still a highly popular device). The wider pointers exist to save effort and make more general code. Removing the possibility of such pointers would unnecessarily limit that compiler. > <snip> > >>> The specific thing being discussed was your suggestion that >>> all pointer types should have the same size. That's a very >>> specific proposal. In my opinion it is not supported by the >>> vague generalities above. >> >> The pointer issue is an extremely small point to me. > > Okay, so do you want to drop that? If so, I could understand it, since > you're on very shaky ground with that one. But what, then, are the > larger points? And is this, again, a matter of "I have a certain > philosophy that I expect you to agree with", or do you have sound > technical reasons for your stance on those points? > >> My initial reaction and thinking is as I've indicated: having >> multiple and varied sized pointers is not desirable in the standard. > > You have yet to say *why* you would impose this unnecessary constraint > on *all* implementations. > >> It may be desirable (and necessary) on certain architectures, > > So why forbid it? > >> but >> not in general in moving forward, and not in the standard. > > The Standard *does not say* "you must have a plethora of pointer sizes". > The Standard simply does not require pointer sizes to be uniform. Why > should it impose arbitrary constraints on implementations? What is the > *point*, other than some nebulous idea of "wouldn't it be nice if all C > implementations were like the one I think I know well?" > There are many points in the standards where the flexibility /can/ make it inconvenient to write code that is portable across any hypothetical conforming compilers, and certainly many I would want to change long before worrying about pointer sizes. But I think Keith's "profile" suggestion, or additional standards such as POSIX, are the way to go forward here. >>> The fact that pointers can possibly be of different sizes does not, >>> any any case I'm aware of, seriously get in the way of that. >> >> Agreed. > > Fine, so we can ditch that one, yes? > >>> Your suggested change has the potential >>> of inconveniencing others with, as far as I've been able to tell, >>> no real benefit to you. >> >> It has potential benefit, but as of yet, no real practical benefit >> which has been observed. > > What potential benefit might it have? Or would you rather let it drop? > >>> There are many ways a language can be "uniform". It can be uniform >>> by requiring all pointers to be the same size, or it can uniformly >>> leave the size of each pointer type up to the implementation. Or, >>> as some languages do, it can not expose pointers to the programmer >>> at all, so their size is irrelevant. >> >> In my view, uniformity would target the ideal machine, and then allow >> extensions out to peculiar quirks found on other machines. > > I don't see what's so ideal about requiring that all pointers should be > the same size. Surely, it's a better (more ideal) machine if all > pointers are an *appropriate* size, and that appropriate size may well > vary from pointer type to pointer type and from machine to machine. > >> PS - I realize you've added me to your killfile... but I offer this >> for others, and in the hopes that perhaps you didn't killfile me. > > If he has killfiled you, it won't be for any technical arguments you may > have advanced, sound or otherwise, but for being repeatedly idiotic. > *Everyone* is idiotic from time to time. The trick is not to do it too > often. >
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-23 16:14 +0100 |
| Message-ID | <mmbt2k$v1s$1@dont-email.me> |
| In reply to | #63935 |
On 23/06/15 15:40, David Brown wrote: <snip> > There are many points in the standards where the flexibility /can/ make > it inconvenient to write code that is portable across any hypothetical > conforming compilers, and certainly many I would want to change long > before worrying about pointer sizes. I tried to think of some examples of what you are saying here, and I struggled. For instance, I'd kind of like to see CHAR_BIT have a maximum value that made it practical to have an array of unsigned char that is UCHAR_MAX + 1 (i.e. 1 << CHAR_BIT) elements in size without imposing a significant burden on the machine's memory resources. But who knows? Perhaps, some way down the line from here, RAM will be measured in yottabytes (where "byte" means "64 bits") and everybody will be using 64-bit Multicode character sets, and nobody will consider it impractical, unwise, or even unusual to declare an array of 18446744073709551616 elements. C has proved to be remarkably resilient in the face of continual technical change, largely because it /is/ so flexible, and to place artificial limits on it for the sake of momentary convenience would seem to me to be a backward step. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-23 22:51 +0200 |
| Message-ID | <mmcgqo$j4i$1@dont-email.me> |
| In reply to | #63948 |
On 23/06/15 17:14, Richard Heathfield wrote: > On 23/06/15 15:40, David Brown wrote: > > <snip> > >> There are many points in the standards where the flexibility /can/ make >> it inconvenient to write code that is portable across any hypothetical >> conforming compilers, and certainly many I would want to change long >> before worrying about pointer sizes. > > I tried to think of some examples of what you are saying here, and I > struggled. For instance, I'd kind of like to see CHAR_BIT have a maximum > value that made it practical to have an array of unsigned char that is > UCHAR_MAX + 1 (i.e. 1 << CHAR_BIT) elements in size without imposing a > significant burden on the machine's memory resources. > Examples of inconveniences from the flexibility of C are that the format of most types (such as signed integer types and floating point) are not fixed - this makes it very difficult to write fully portable code that deals with data in binary formats. You cannot, for example, be sure that if C code on one system writes out an int to a file, that you will be able to read it as an int from C code on another system. Even if you make sure that the integer types you use are the same size, you could find that one of the systems is using two's complement, while the other is using one's complement. Certainly /some/ flexibility is useful - it would be unreasonable for the C standards to impose endianness choices. But I don't think many people would be harmed if the next C standard insisted that signed integer types were always two's complement, and that endianness was either big or little - no mixed formats. There are a few current systems that cannot address individual octets, and thus have CHAR_BIT either 16 or 32, so no doubt there would be complaints if CHAR_BIT were fixed at 8. But perhaps it could be limited to 8, 16 or 32. As I said, I think the idea of making this sort of thing a "profile" or additional restriction on top of the normal standards is more practical than restricting the standards as we have them now. My point is merely that /if/ we were going to restrict and limit the standards, then making pointer sizes consistent is certainly not the area I would change first.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-23 22:06 +0100 |
| Message-ID | <mmchmc$m63$1@dont-email.me> |
| In reply to | #63988 |
On 23/06/15 21:51, David Brown wrote: > On 23/06/15 17:14, Richard Heathfield wrote: >> On 23/06/15 15:40, David Brown wrote: >> >> <snip> >> >>> There are many points in the standards where the flexibility /can/ make >>> it inconvenient to write code that is portable across any hypothetical >>> conforming compilers, and certainly many I would want to change long >>> before worrying about pointer sizes. >> >> I tried to think of some examples of what you are saying here, and I >> struggled. For instance, I'd kind of like to see CHAR_BIT have a maximum >> value that made it practical to have an array of unsigned char that is >> UCHAR_MAX + 1 (i.e. 1 << CHAR_BIT) elements in size without imposing a >> significant burden on the machine's memory resources. >> > > Examples of inconveniences from the flexibility of C are that the format > of most types (such as signed integer types and floating point) are not > fixed - this makes it very difficult to write fully portable code that > deals with data in binary formats. You cannot, for example, be sure > that if C code on one system writes out an int to a file, that you will > be able to read it as an int from C code on another system. Even if you > make sure that the integer types you use are the same size, you could > find that one of the systems is using two's complement, while the other > is using one's complement. Whilst that's true, it's hardly C's fault, and it's difficult to see how changing C would do any good. These differences between platforms do exist, and C didn't get to be as portable as it is by demanding that platform architects conform to its idea of what constitutes a good architecture. > Certainly /some/ flexibility is useful - it would be unreasonable for > the C standards to impose endianness choices. But I don't think many > people would be harmed if the next C standard insisted that signed > integer types were always two's complement, and that endianness was > either big or little - no mixed formats. It would be interesting to hear about architects' views on this proposal. Are there any extant platforms that use ones' complement or sign-and-magnitude? (By "extant" I mean platforms with at least one production machine currently running for reasons other than nostalgia, and for which an ISO C implementation exists.) Or, for that matter, are there any extant platforms that use any of the flavours of middle-endian? > There are a few current > systems that cannot address individual octets, and thus have CHAR_BIT > either 16 or 32, so no doubt there would be complaints if CHAR_BIT were > fixed at 8. But perhaps it could be limited to 8, 16 or 32. ...which would make sense *now*, but might be considered short-sighted a few years or decades down the line. > As I said, I think the idea of making this sort of thing a "profile" or > additional restriction on top of the normal standards is more practical > than restricting the standards as we have them now. My point is merely > that /if/ we were going to restrict and limit the standards, then making > pointer sizes consistent is certainly not the area I would change first. Or indeed at all. Perhaps we as a group need to spend a little time thinking through how we might formalise this "profile" idea. (But if we do, let it be in a new thread!) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-06-24 00:14 +0000 |
| Message-ID | <mmcsos$7mo$1@speranza.aioe.org> |
| In reply to | #63992 |
Richard Heathfield <rjh@cpax.org.uk> wrote: (snip) > Whilst that's true, it's hardly C's fault, and it's difficult to see how > changing C would do any good. These differences between platforms do > exist, and C didn't get to be as portable as it is by demanding that > platform architects conform to its idea of what constitutes a good > architecture. (snip) > It would be interesting to hear about architects' views on this > proposal. Are there any extant platforms that use ones' complement or > sign-and-magnitude? (By "extant" I mean platforms with at least one > production machine currently running for reasons other than nostalgia, > and for which an ISO C implementation exists.) Or, for that matter, are > there any extant platforms that use any of the flavours of middle-endian? I believe Unisys still has ones complement machines in production, and has a C compiler for them. As well as I understand it, the implementation of unsigned integer types is a little strange, but I don't know the details. It might be, for example, that UINT_MAX==0 is true. (Consider the bit patterns and a ones-complement ALU.) The last I know of sign-magnitude machines is the 7094. It would be nice to have a C compiler for one, but I don't believe IBM ever sold one. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-24 01:17 +0100 |
| Message-ID | <mmcsro$rj6$1@dont-email.me> |
| In reply to | #64011 |
On 24/06/15 01:14, glen herrmannsfeldt wrote: > Richard Heathfield <rjh@cpax.org.uk> wrote: > > (snip) >> Whilst that's true, it's hardly C's fault, and it's difficult to see how >> changing C would do any good. These differences between platforms do >> exist, and C didn't get to be as portable as it is by demanding that >> platform architects conform to its idea of what constitutes a good >> architecture. > > (snip) > >> It would be interesting to hear about architects' views on this >> proposal. Are there any extant platforms that use ones' complement or >> sign-and-magnitude? (By "extant" I mean platforms with at least one >> production machine currently running for reasons other than nostalgia, >> and for which an ISO C implementation exists.) Or, for that matter, are >> there any extant platforms that use any of the flavours of middle-endian? > > I believe Unisys still has ones complement machines in production, > and has a C compiler for them. > > As well as I understand it, the implementation of unsigned integer > types is a little strange, but I don't know the details. It might > be, for example, that UINT_MAX==0 is true. (Consider the bit > patterns and a ones-complement ALU.) If that's true, then the implementation isn't conforming. UINT_MAX is /required/ to be at least 65535, so 0 doesn't really cut it. No matter what the hardware is doing underneath, the implementation has to make magic happen to ensure that unsigned integer arithmetic works correctly. > The last I know of sign-magnitude machines is the 7094. It would > be nice to have a C compiler for one, but I don't believe IBM ever > sold one. Leased, perhaps? ;-) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-06-24 05:18 +0000 |
| Message-ID | <mmdeif$6ri$1@speranza.aioe.org> |
| In reply to | #64012 |
Richard Heathfield <rjh@cpax.org.uk> wrote: (snip) >> I believe Unisys still has ones complement machines in production, >> and has a C compiler for them. >> As well as I understand it, the implementation of unsigned integer >> types is a little strange, but I don't know the details. It might >> be, for example, that UINT_MAX==0 is true. (Consider the bit >> patterns and a ones-complement ALU.) > If that's true, then the implementation isn't conforming. UINT_MAX is > /required/ to be at least 65535, so 0 doesn't really cut it. No matter > what the hardware is doing underneath, the implementation has to make > magic happen to ensure that unsigned integer arithmetic works correctly. It isn't that it is zero, but that it compares equal to zero. I have read the description, didn't track down the exact details, but a ones-complement system will normally compare 0 and ~0 as equal. >> The last I know of sign-magnitude machines is the 7094. It would >> be nice to have a C compiler for one, but I don't believe IBM ever >> sold one. > Leased, perhaps? ;-) I meant the compiler, but yes, they probably lease software, too. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-24 09:35 +0100 |
| Message-ID | <mmdq24$76h$2@dont-email.me> |
| In reply to | #64020 |
On 24/06/15 06:18, glen herrmannsfeldt wrote: > Richard Heathfield <rjh@cpax.org.uk> wrote: > (snip) > >>> I believe Unisys still has ones complement machines in production, >>> and has a C compiler for them. > >>> As well as I understand it, the implementation of unsigned integer >>> types is a little strange, but I don't know the details. It might >>> be, for example, that UINT_MAX==0 is true. (Consider the bit >>> patterns and a ones-complement ALU.) > >> If that's true, then the implementation isn't conforming. UINT_MAX is >> /required/ to be at least 65535, so 0 doesn't really cut it. No matter >> what the hardware is doing underneath, the implementation has to make >> magic happen to ensure that unsigned integer arithmetic works correctly. > > It isn't that it is zero, but that it compares equal to zero. Again, it can't do that and still be conforming. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-24 10:43 +0100 |
| Message-ID | <87oak5igqi.fsf@bsb.me.uk> |
| In reply to | #64020 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Richard Heathfield <rjh@cpax.org.uk> wrote: > (snip) > >>> I believe Unisys still has ones complement machines in production, >>> and has a C compiler for them. > >>> As well as I understand it, the implementation of unsigned integer >>> types is a little strange, but I don't know the details. It might >>> be, for example, that UINT_MAX==0 is true. (Consider the bit >>> patterns and a ones-complement ALU.) > >> If that's true, then the implementation isn't conforming. UINT_MAX is >> /required/ to be at least 65535, so 0 doesn't really cut it. No matter >> what the hardware is doing underneath, the implementation has to make >> magic happen to ensure that unsigned integer arithmetic works correctly. > > It isn't that it is zero, but that it compares equal to zero. > > I have read the description, didn't track down the exact details, > but a ones-complement system will normally compare 0 and ~0 as > equal. On a ones' complement machine 0 == ~0 is permitted (required in fact) when the machine has a negative zero rather than a trap representation, but ~0 is not UINT_MAX because 0 is a sign int value. 0 != ~0u is always true on all conforming implementations. I think what you are remembering is that the machine in question did not have an unsigned int type in hardware so to get C semantics for unsigned int you had to ask for it since it had cost in terms of the code generated. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-24 11:19 -0400 |
| Message-ID | <mmehnp$scp$1@dont-email.me> |
| In reply to | #64020 |
On 06/24/2015 01:18 AM, glen herrmannsfeldt wrote: > Richard Heathfield <rjh@cpax.org.uk> wrote: > (snip) > >>> I believe Unisys still has ones complement machines in production, >>> and has a C compiler for them. > >>> As well as I understand it, the implementation of unsigned integer >>> types is a little strange, but I don't know the details. It might >>> be, for example, that UINT_MAX==0 is true. (Consider the bit >>> patterns and a ones-complement ALU.) > >> If that's true, then the implementation isn't conforming. UINT_MAX is >> /required/ to be at least 65535, so 0 doesn't really cut it. No matter >> what the hardware is doing underneath, the implementation has to make >> magic happen to ensure that unsigned integer arithmetic works correctly. > > It isn't that it is zero, but that it compares equal to zero. Then it violates C requirements for comparison operators. It doesn't matter whether if the only comparison instructions provided by the hardware have that property - the C implementation is required to contain whatever additional special-case instructions are needed to produce the result required by the C standard. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-14 07:20 -0700 |
| Message-ID | <kfnvbdmu8g9.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #63988 |
David Brown <david.brown@hesbynett.no> writes: > [re: flexibility of C] > > Examples of inconveniences from the flexibility of C are that the > format of most types (such as signed integer types and floating > point) are not fixed - this makes it very difficult to write fully > portable code that deals with data in binary formats. [snip] Floating-point, yes; integers, no. Writing portable code to read/write binary integer values isn't difficult, let alone very difficult. Any competent C developer should be able to write portable binary I/O routines for, eg, 32-bit values, both signed and unsigned, in an hour or less.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-14 17:55 +0000 |
| Message-ID | <mo3idp$794$1@speranza.aioe.org> |
| In reply to | #65545 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > David Brown <david.brown@hesbynett.no> writes: >> [re: flexibility of C] (snip) > Floating-point, yes; integers, no. Writing portable code to > read/write binary integer values isn't difficult, let alone very > difficult. Any competent C developer should be able to write > portable binary I/O routines for, eg, 32-bit values, both signed > and unsigned, in an hour or less. A little longer to get it right for ones complement and sign magnitude, though. Still no C compiler for the 7094. -- glen
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-15 20:06 -0700 |
| Message-ID | <08874c76-0207-4b08-867e-7034cf030337@googlegroups.com> |
| In reply to | #65572 |
On Tuesday, July 14, 2015 at 10:55:16 AM UTC-7, glen herrmannsfeldt wrote: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > > David Brown <david.brown@hesbynett.no> writes: > > >> [re: flexibility of C] > > (snip) > > Floating-point, yes; integers, no. Writing portable code to > > read/write binary integer values isn't difficult, let alone very > > difficult. Any competent C developer should be able to write > > portable binary I/O routines for, eg, 32-bit values, both signed > > and unsigned, in an hour or less. > > A little longer to get it right for ones complement and sign > magnitude, though. > > Still no C compiler for the 7094. I may have written one for the 704 (which I think would run on a 7094) but that was a long time ago. I can't believe I still have any notes but they would be in the deadest of my dead files. If I get up enough energy I'll look for them. If I don't post a report that means I couldn't find anything.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-07-15 23:28 -0500 |
| Message-ID | <40ceqahhp7oe1c93sh77oe1ofgq6425bdm@4ax.com> |
| In reply to | #65675 |
On Wed, 15 Jul 2015 20:06:28 -0700 (PDT), David Kleinecke <dkleinecke@gmail.com> wrote: >On Tuesday, July 14, 2015 at 10:55:16 AM UTC-7, glen herrmannsfeldt wrote: >> Tim Rentsch <txr@alumni.caltech.edu> wrote: >> > David Brown <david.brown@hesbynett.no> writes: >> >> >> [re: flexibility of C] >> >> (snip) >> > Floating-point, yes; integers, no. Writing portable code to >> > read/write binary integer values isn't difficult, let alone very >> > difficult. Any competent C developer should be able to write >> > portable binary I/O routines for, eg, 32-bit values, both signed >> > and unsigned, in an hour or less. >> >> A little longer to get it right for ones complement and sign >> magnitude, though. >> >> Still no C compiler for the 7094. > >I may have written one for the 704 (which I think would run on a 7094) >but that was a long time ago. I can't believe I still have any notes >but they would be in the deadest of my dead files. If I get up enough >energy I'll look for them. If I don't post a report that means I >couldn't find anything. Errr... you do know that the last 704 was shipped in 1960? And would have been a dozen years old in 1972?
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-15 22:06 -0700 |
| Message-ID | <31b30d90-b58c-459c-9785-175973552d7b@googlegroups.com> |
| In reply to | #65680 |
On Wednesday, July 15, 2015 at 9:28:28 PM UTC-7, robert...@yahoo.com wrote: > On Wed, 15 Jul 2015 20:06:28 -0700 (PDT), David Kleinecke > <dkleinecke@gmail.com> wrote: > > >On Tuesday, July 14, 2015 at 10:55:16 AM UTC-7, glen herrmannsfeldt wrote: > >> Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> > David Brown <david.brown@hesbynett.no> writes: > >> > >> >> [re: flexibility of C] > >> > >> (snip) > >> > Floating-point, yes; integers, no. Writing portable code to > >> > read/write binary integer values isn't difficult, let alone very > >> > difficult. Any competent C developer should be able to write > >> > portable binary I/O routines for, eg, 32-bit values, both signed > >> > and unsigned, in an hour or less. > >> > >> A little longer to get it right for ones complement and sign > >> magnitude, though. > >> > >> Still no C compiler for the 7094. > > > >I may have written one for the 704 (which I think would run on a 7094) > >but that was a long time ago. I can't believe I still have any notes > >but they would be in the deadest of my dead files. If I get up enough > >energy I'll look for them. If I don't post a report that means I > >couldn't find anything. > > > Errr... you do know that the last 704 was shipped in 1960? And would > have been a dozen years old in 1972? I believe the machine I was working with was the penultimate 704 in operation anywhere in the world. But I agree the dates look stretched. I can remember discussing Multics in the context of the 704 but I don't think I ever knew enough PL/1 to write a compiler. It may have been a FORTRAN compiler (I wrote one once) or I may have written a compiler for an extinct machine as an intellectual exercise. But that was when I working on the Basic compiler for the GE 235. But I don't remember my first C compiler and I do remember that in 1978 K&R all seemed old stuff to me. Sorry - too many years. I wonder - was I sophisticated enough to use the 704 instruction set as an intermediate language to feed to a back end that generated actual code for various machines?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-20 09:42 -0700 |
| Message-ID | <kfn1tg2ok67.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65572 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> [re: flexibility of C]
>
> (snip)
>
>> Floating-point, yes; integers, no. Writing portable code to
>> read/write binary integer values isn't difficult, let alone very
>> difficult. Any competent C developer should be able to write
>> portable binary I/O routines for, eg, 32-bit values, both signed
>> and unsigned, in an hour or less.
>
> A little longer to get it right for ones complement and sign
> magnitude, though.
No, the hour time should be enough to produce the code necessary
for all the representations C allows. If limited to two's
complement the task should take no more than 15 minutes.
The key insight is that converting a signed integer to an
unsigned integer produces what is essentially a two's complement
representation (ie, in the unsigned type), regardless of the
representation of the signed type. So doing output is easy.
Going the other way, reading a two's complement bit pattern
into an unsigned type, and computing the corresponding signed
value in a representation-independent way, is a little bit
harder, especially since some care must be taken to avoid
the problem with producing the most negative integer. Even
this though is not too hard. Here is an illustrating example,
assuming 16-bit int types:
unsigned u = ... bits read from input channel ...
signed s;
s = u < 0x8000 ? (signed) u : -(signed)(0xFFFF - u) - 1;
It should be easy to see that (0xFFFF - u) always produces a
value in the range that 'signed' can hold (ie, as a positive
number or zero). Negating that signed value produces a value
that is one greater than the value desired, so we subtract one
to get the final answer. Obviously it might be important in
some cases to test in advance for the distinguished negative
value, to be sure we don't cross undefined behavior on those
platforms where it might occur, but that's a simple test which
I am confident people can figure out without needing it to be
explained further.
Another way of writing the last part of the ?: is
-(signed)(-1U - u) - 1
which may be easier to see that it produces the right value.
If types are ignored, this is
-(1-u) - 1, or (1+u) - 1, or just u
after which we just need to be sure that the type conversions
respect the values invovled, which they do.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-06-23 09:16 -0700 |
| Message-ID | <31163b47-0a59-4b4f-b3eb-bf5e2391263e@googlegroups.com> |
| In reply to | #63935 |
On Tuesday, June 23, 2015 at 7:40:31 AM UTC-7, David Brown wrote: > On 23/06/15 15:37, Richard Heathfield wrote: > > On 23/06/15 14:00, Rick C. Hodgin wrote: > >> On Monday, June 22, 2015 at 5:38:39 PM UTC-4, Keith Thompson wrote: > >>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > >>> > On Monday, June 22, 2015 at 4:16:10 PM UTC-4, Keith Thompson wrote: > >>> >> Why? What specific problem would such a definition solve? > >>> > > >>> > It's one of those things ... if I have to explain it to you, it's > >>> > likely you won't understand it even when explained. > >>> > >>> Are you saying that if I disagree with you it must be because I'm > >>> unable to understand your position? > >> > >> No. However, if you don't already understand it, then it's likely you > >> won't be able to because you place emphasis on different things than > >> I do. > > > > In my experience, Keith thinks that sound technical arguments carry more > > weight than personal opinions. "Don't X because Y (see Z part of > > Standard)" carries more weight than "I don't think X is the right thing > > to do". > > > > I'd go further than that and say "Don't X because Y" carries more weight > than "I don't think X is the right thing to do". /Any/ technical > 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. > > > <snip> > > > >> However, I place priorities on different things. I look to the human > >> being and their natural way of thinking. I try to make the machine > >> do for people what people need, rather than giving to people what the > >> machine is doing. > > > > Okay, that's fair enough. But according to my natural way of thinking, > > people don't need pointer sizes to be uniform. So why cause a lot of > > people a lot of work by lobbying for that uniformity? > > When people talk about "natural way of thinking" or "from the human > viewpoint", they invariably mean "/my/ way of thinking" and "from /my/ > viewpoint". It can't be avoided. > > Obviously it is fair enough to discuss things from one's own viewpoint. > And for RDC, it is clearly Rick's personal viewpoint that is most > important, as it is his language. But when considering something like > the C standards, a wider range of viewpoints must be taken - including > machines (of many sorts), compiler implementers, standards authors, as > well as human programmers (and the odd non-human programmer). > > > > >> It's what I mean when I say that if you don't already understand it, > >> you likely won't be able to (because the inertia of your present > >> thinking will overshadow this idea). > > > > I have greater faith in Keith's objectivity than you do, and I'm sure > > he's capable of understanding your idea, but that doesn't mean he has to > > agree with it. What he is saying, and what I am saying, is that your > > proposal to make pointer sizes uniform addresses a non-existent problem. > > I have never, ever, /ever/ been caused extra work by the possibility > > that pointers might be different sizes. Have you? > > > > I have only worked with one system with non-uniform pointer sizes - > avr-gcc has support for generic 24-bit pointers as well as 16-bit > pointers to different address spaces (the AVR is an 8-bit > microcontroller with Harvard architecture. And while it's usage is in > the decline, it is still a highly popular device). The wider pointers > exist to save effort and make more general code. Removing the > possibility of such pointers would unnecessarily limit that compiler. > > > <snip> > > > >>> The specific thing being discussed was your suggestion that > >>> all pointer types should have the same size. That's a very > >>> specific proposal. In my opinion it is not supported by the > >>> vague generalities above. > >> > >> The pointer issue is an extremely small point to me. > > > > Okay, so do you want to drop that? If so, I could understand it, since > > you're on very shaky ground with that one. But what, then, are the > > larger points? And is this, again, a matter of "I have a certain > > philosophy that I expect you to agree with", or do you have sound > > technical reasons for your stance on those points? > > > >> My initial reaction and thinking is as I've indicated: having > >> multiple and varied sized pointers is not desirable in the standard. > > > > You have yet to say *why* you would impose this unnecessary constraint > > on *all* implementations. > > > >> It may be desirable (and necessary) on certain architectures, > > > > So why forbid it? > > > >> but > >> not in general in moving forward, and not in the standard. > > > > The Standard *does not say* "you must have a plethora of pointer sizes". > > The Standard simply does not require pointer sizes to be uniform. Why > > should it impose arbitrary constraints on implementations? What is the > > *point*, other than some nebulous idea of "wouldn't it be nice if all C > > implementations were like the one I think I know well?" > > > > There are many points in the standards where the flexibility /can/ make > it inconvenient to write code that is portable across any hypothetical > conforming compilers, and certainly many I would want to change long > before worrying about pointer sizes. But I think Keith's "profile" > suggestion, or additional standards such as POSIX, are the way to go > forward here. > > >>> The fact that pointers can possibly be of different sizes does not, > >>> any any case I'm aware of, seriously get in the way of that. > >> > >> Agreed. > > > > Fine, so we can ditch that one, yes? > > > >>> Your suggested change has the potential > >>> of inconveniencing others with, as far as I've been able to tell, > >>> no real benefit to you. > >> > >> It has potential benefit, but as of yet, no real practical benefit > >> which has been observed. > > > > What potential benefit might it have? Or would you rather let it drop? > > > >>> There are many ways a language can be "uniform". It can be uniform > >>> by requiring all pointers to be the same size, or it can uniformly > >>> leave the size of each pointer type up to the implementation. Or, > >>> as some languages do, it can not expose pointers to the programmer > >>> at all, so their size is irrelevant. > >> > >> In my view, uniformity would target the ideal machine, and then allow > >> extensions out to peculiar quirks found on other machines. > > > > I don't see what's so ideal about requiring that all pointers should be > > the same size. Surely, it's a better (more ideal) machine if all > > pointers are an *appropriate* size, and that appropriate size may well > > vary from pointer type to pointer type and from machine to machine. > > > >> PS - I realize you've added me to your killfile... but I offer this > >> for others, and in the hopes that perhaps you didn't killfile me. > > > > If he has killfiled you, it won't be for any technical arguments you may > > have advanced, sound or otherwise, but for being repeatedly idiotic. > > *Everyone* is idiotic from time to time. The trick is not to do it too > > often. > > I fear I started the different sized pointers mess by accident. I apologize. I was led to the issue by considering Harvard-type hardware. Where the data and the code are entirely separated. I advocate that kind of hardware. Then I observed that most often programs used much more data memory than code memory so I wondered whether - in a Harvard-type machine - code pointers might not be shorter than data pointers. At that time I was under the impression that all pointers had to have the same size - the size of a data/code pointer. I see now that this can be done in standard C. I would deplore any attempt to force all pointers to the same size.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-23 09:27 -0700 |
| Message-ID | <2f073800-5717-4861-b68a-265a6aed91a2@googlegroups.com> |
| In reply to | #63959 |
On Tuesday, June 23, 2015 at 12:16:44 PM UTC-4, David Kleinecke wrote: > ...I would deplore any attempt to force all pointers to the > same size. In my proposal, the changes to core C would be that all pointers are the same size. Any variations to this would be included as extension to core C. This would allow all architectures which use the same size pointers to be completely inside of core C without support for those architectures which do have varying size pointers. It would not prevent them from existing, nor even being in wide use, but they would be explicitly noted for what they are (by being given them the "extension" status): oddities / peculiarities. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-06-24 07:38 -0700 |
| Message-ID | <236cba96-973f-4764-aba4-a69f8515ac3a@googlegroups.com> |
| In reply to | #63960 |
On Tuesday, June 23, 2015 at 9:27:19 AM UTC-7, Rick C. Hodgin wrote: > On Tuesday, June 23, 2015 at 12:16:44 PM UTC-4, David Kleinecke wrote: > > ...I would deplore any attempt to force all pointers to the > > same size. > > In my proposal, the changes to core C would be that all pointers are > the same size. Any variations to this would be included as extension > to core C. > > This would allow all architectures which use the same size pointers > to be completely inside of core C without support for those > architectures which do have varying size pointers. > > It would not prevent them from existing, nor even being in wide use, > but they would be explicitly noted for what they are (by being given > them the "extension" status): oddities / peculiarities. I can't see that pointer size restriction gains you anything. So why require it?
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-24 07:55 -0700 |
| Message-ID | <a6ed88d3-6e8f-4d3b-86ef-ce6e9a7d055d@googlegroups.com> |
| In reply to | #64061 |
On Wednesday, June 24, 2015 at 10:38:15 AM UTC-4, David Kleinecke wrote:
> On Tuesday, June 23, 2015 at 9:27:19 AM UTC-7, Rick C. Hodgin wrote:
> > On Tuesday, June 23, 2015 at 12:16:44 PM UTC-4, David Kleinecke wrote:
> > > ...I would deplore any attempt to force all pointers to the
> > > same size.
> >
> > In my proposal, the changes to core C would be that all pointers are
> > the same size. Any variations to this would be included as extension
> > to core C.
> >
> > This would allow all architectures which use the same size pointers
> > to be completely inside of core C without support for those
> > architectures which do have varying size pointers.
> >
> > It would not prevent them from existing, nor even being in wide use,
> > but they would be explicitly noted for what they are (by being given
> > them the "extension" status): oddities / peculiarities.
>
> I can't see that pointer size restriction gains you anything. So why
> require it?
In my "proposal," fixed size pointers is not a requirement. They are
only defined to be part of core C. Anything which is not the same size
is called an "extension" to core C, and is allowed. And for a feature
like this which is in wide use it would be defined to be a known
extension. However, I would also not define other things which are in
use as known extensions, but still allow them as other extensions which
encompass the full range of unique hardware abilities.
I would also define a common interface into assembly code blocks for
target machines. One of the things my compiler does is allow for
simultaneous compiles to multiple target architectures. And in those
cases, the need to have more than one assembly output block is
required.
#ifdef defined(__ARM__) || defined(__X86__)
_asm {
.x86
// Assembly code goes here for x86
.arm
// Assembly code goes here for ARM
}
#else
// "Slower" equivalent C source code goes here
#endif
And other things. If I ever get RDC completed, you'll see it in
practical use.
You'll also see the "#stop Nnn" directive to force the compiler to
stop compiling at that point in source code, such as after examining
the compiler environment to see that there is no Xyz module available.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
Page 11 of 23 — ← Prev page 1 … 9 10 [11] 12 13 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web