Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #60841 > unrolled thread
| Started by | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| First post | 2015-04-23 08:09 +0100 |
| Last post | 2015-04-25 04:01 -0700 |
| Articles | 20 on this page of 432 — 38 participants |
Back to article view | Back to comp.lang.c
Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-04-23 08:09 +0100
Re: Spurious diagnostic messages Noob <root@127.0.0.1> - 2015-04-23 10:56 +0200
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-04-23 21:13 +1200
Re: Spurious diagnostic messages Noob <root@127.0.0.1> - 2015-04-23 11:25 +0200
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-04-23 10:36 +0100
Re: Spurious diagnostic messages Noob <root@127.0.0.1> - 2015-04-23 11:54 +0200
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-04-23 11:06 +0100
Re: Spurious diagnostic messages Noob <root@127.0.0.1> - 2015-04-23 12:35 +0200
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-04-23 11:44 +0100
Re: Spurious diagnostic messages Noob <root@127.0.0.1> - 2015-04-23 12:56 +0200
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-04-23 12:16 +0100
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-04-23 12:09 -0700
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-04-24 07:52 +1200
Re: Spurious diagnostic messages James Kuyper <jameskuyper@verizon.net> - 2015-04-23 16:15 -0400
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-04-24 08:21 +1200
Re: Spurious diagnostic messages James Kuyper <jameskuyper@verizon.net> - 2015-04-23 16:44 -0400
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-04-24 13:01 +0200
Re: Spurious diagnostic messages gwowen <gwowen@gmail.com> - 2015-04-23 04:16 -0700
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-04-23 12:19 +0100
Re: Spurious diagnostic messages Robbie Hatley <see.my.sig@for.my.address> - 2015-04-24 04:42 -0700
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-04-24 16:07 +0100
Re: Spurious diagnostic messages Robbie Hatley <see.my.sig@for.my.address> - 2015-04-25 22:08 -0700
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-04-26 14:29 +0100
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-04-26 15:45 +0000
Re: Spurious diagnostic messages Ben Bacarisse <ben.lists@bsb.me.uk> - 2015-04-23 11:43 +0100
Re: Spurious diagnostic messages gazelle@shell.xmission.com (Kenny McCormack) - 2015-04-23 09:29 +0000
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-04-23 11:52 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-25 03:03 -0700
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-04-23 10:53 +0100
Re: Spurious diagnostic messages Ben Bacarisse <ben.lists@bsb.me.uk> - 2015-04-23 11:37 +0100
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-04-23 12:12 +0100
Re: Spurious diagnostic messages Noob <root@127.0.0.1> - 2015-04-23 12:46 +0200
Re: Spurious diagnostic messages James Kuyper <jameskuyper@verizon.net> - 2015-04-23 08:47 -0400
Re: Spurious diagnostic messages Fred K <fred.l.kleinschmidt@gmail.com> - 2015-04-23 07:39 -0700
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-04-23 16:20 +0100
Re: Spurious diagnostic messages James Kuyper <jameskuyper@verizon.net> - 2015-04-23 12:43 -0400
Re: Spurious diagnostic messages James Dow Allen <jdallen2000@yahoo.com> - 2015-04-24 01:40 -0700
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-04-24 11:14 +0100
Re: Spurious diagnostic messages James Dow Allen <jdallen2000@yahoo.com> - 2015-04-24 10:02 -0700
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-04-24 18:20 +0100
Re: Spurious diagnostic messages James Dow Allen <jdallen2000@yahoo.com> - 2015-04-24 13:27 -0700
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-04-25 10:25 +0000
Re: Spurious diagnostic messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-24 23:02 +0100
Re: Spurious diagnostic messages Ben Bacarisse <ben.lists@bsb.me.uk> - 2015-04-24 11:30 +0100
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-26 08:09 -0700
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-04-26 12:26 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-28 09:52 -0700
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-04-28 11:27 -0700
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-04-28 20:09 +0100
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 07:11 -0700
Re: Spurious diagnostic messages Phil Carmody <pc+usenet@asdf.org> - 2015-05-09 13:14 +0300
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-10 08:23 -0700
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-10 11:06 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 21:52 -0700
Re: Spurious diagnostic messages James Kuyper <jameskuyper@verizon.net> - 2015-05-10 12:20 -0400
Re: Spurious diagnostic messages Richard Damon <Richard@Damon-Family.org> - 2015-05-10 13:22 -0400
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-05-10 18:44 +0100
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-10 11:12 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 21:46 -0700
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-12 10:11 -0700
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 18:26 +0100
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-12 11:29 -0700
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-05-13 09:14 +0200
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-05-13 11:55 +0100
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-05-13 14:55 +0200
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-05-13 14:35 +0100
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-13 08:24 -0700
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-13 18:47 -0500
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-05-13 21:15 +0200
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-13 19:40 +0000
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-13 21:08 +0100
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-13 20:52 +0000
Re: Spurious diagnostic messages gazelle@shell.xmission.com (Kenny McCormack) - 2015-05-13 21:06 +0000
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-13 23:28 +0000
Re: Spurious diagnostic messages gazelle@shell.xmission.com (Kenny McCormack) - 2015-05-14 00:19 +0000
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-14 04:29 +0000
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-14 09:57 +0100
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-14 04:56 -0500
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-05-14 11:34 +0100
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-14 17:24 +0000
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-16 01:21 -0500
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-05-17 10:00 +0100
Re: Spurious diagnostic messages David Thompson <dave.thompson2@verizon.net> - 2015-06-21 12:46 -0400
Re: Spurious diagnostic messages James Kuyper <jameskuyper@verizon.net> - 2015-06-21 13:20 -0400
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-14 17:22 +0000
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-16 01:59 -0500
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-16 09:51 +0000
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-16 05:36 -0500
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-16 19:32 +0000
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-14 17:13 +0000
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:13 +0000
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-13 18:54 -0500
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-14 01:31 +0100
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-13 21:05 -0500
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-14 00:48 -0500
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-14 17:27 +0000
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-16 02:00 -0500
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-14 09:41 +0100
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-14 05:02 -0500
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-14 13:44 +0100
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-14 17:32 +0000
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-14 20:18 +0100
Re: Spurious diagnostic messages Öö Tiib <ootiib@hot.ee> - 2015-05-15 05:32 -0700
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-15 13:47 -0500
Re: Spurious diagnostic messages Öö Tiib <ootiib@hot.ee> - 2015-05-16 02:51 -0700
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-16 17:13 -0500
Re: Spurious diagnostic messages Öö Tiib <ootiib@hot.ee> - 2015-05-17 22:34 -0700
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-20 08:47 -0700
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:36 +0000
Re: Spurious diagnostic messages gazelle@shell.xmission.com (Kenny McCormack) - 2015-05-17 12:26 +0000
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-17 14:13 +0100
Re: Spurious diagnostic messages gazelle@shell.xmission.com (Kenny McCormack) - 2015-05-17 13:45 +0000
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-17 15:02 +0100
Re: Spurious diagnostic messages gazelle@shell.xmission.com (Kenny McCormack) - 2015-05-17 14:20 +0000
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-17 15:51 +0100
I'm starting a new thread (Was: Spurious diagnostic messages) gazelle@shell.xmission.com (Kenny McCormack) - 2015-05-17 15:00 +0000
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-17 07:58 -0700
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-17 15:36 -0500
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-17 22:28 +0100
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-20 08:59 -0700
Re: Spurious diagnostic messages Les Cargill <lcargill99@comcast.com> - 2015-05-20 11:58 -0500
Re: Spurious diagnostic messages bart4858@gmail.com - 2015-05-20 14:00 -0700
Re: Spurious diagnostic messages Les Cargill <lcargill99@comcast.com> - 2015-05-20 18:10 -0500
Re: Spurious diagnostic messages bart4858@gmail.com - 2015-05-21 00:57 -0700
Re: Spurious diagnostic messages Les Cargill <lcargill99@comcast.com> - 2015-05-21 12:40 -0500
Re: Spurious diagnostic messages bart4858@gmail.com - 2015-05-21 13:25 -0700
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-21 14:33 -0700
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-05-22 09:11 +0200
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-22 08:15 -0700
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-22 11:47 -0500
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-22 12:11 -0700
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-05-23 07:26 +1200
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-22 14:14 -0700
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-05-23 09:28 +1200
Re: Spurious diagnostic messages Les Cargill <lcargill99@comcast.com> - 2015-05-22 21:36 -0500
Re: Spurious diagnostic messages Phil Carmody <pc+usenet@asdf.org> - 2015-05-25 11:36 +0300
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-22 14:16 +0100
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-22 08:38 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-22 18:06 +0100
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-22 13:56 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-22 23:38 +0100
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-22 18:28 -0500
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-22 16:44 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 07:44 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-24 16:52 +0100
Re: Spurious diagnostic messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-24 22:19 +0100
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-05-24 22:28 +0100
Re: Spurious diagnostic messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-25 00:00 +0100
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 10:12 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-24 23:13 +0100
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-25 11:30 +0100
Re: Spurious diagnostic messages Öö Tiib <ootiib@hot.ee> - 2015-05-25 07:41 -0700
Re: Spurious diagnostic messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-25 17:10 +0100
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-05-25 17:42 +0100
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-25 12:20 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 10:07 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-07-10 20:09 +0100
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 11:19 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-07-11 20:25 +0100
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-16 08:48 -0700
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-07-16 14:21 -0500
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 08:52 -0700
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-20 21:21 +0000
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 02:49 -0700
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-23 21:35 +0000
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-27 07:30 -0700
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-07-24 15:35 -0500
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-27 08:13 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-07-27 18:14 +0100
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-01 09:06 -0700
Re: Spurious diagnostic messages "Bartc" <bartc@freeuk.com> - 2015-08-01 18:26 +0100
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-09 08:45 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-07-23 11:48 +0100
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-27 08:50 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-07-17 11:49 +0100
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 09:06 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-07-20 18:18 +0100
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-07-20 11:52 -0700
Re: Spurious diagnostic messages Gareth Owen <gwowen@gmail.com> - 2015-07-20 20:09 +0100
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-07-20 13:18 -0700
Re: Spurious diagnostic messages James Kuyper <jameskuyper@verizon.net> - 2015-07-20 16:24 -0400
Re: Spurious diagnostic messages Gareth Owen <gwowen@gmail.com> - 2015-07-21 07:59 +0100
Re: Spurious diagnostic messages Richard Damon <Richard@Damon-Family.org> - 2015-07-21 21:07 -0400
Re: Spurious diagnostic messages Gareth Owen <gwowen@gmail.com> - 2015-07-21 07:52 +0100
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-07-20 23:17 +0100
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-07-20 15:51 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-24 13:50 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-07-24 22:45 +0100
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-07-25 18:59 +0000
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-07-25 20:49 +0100
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-07-31 13:22 +0000
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-27 08:48 -0700
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-05-25 12:04 +0200
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-05-26 09:11 +0000
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-05-26 11:26 +0200
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-05-26 22:02 +1200
Re: Spurious diagnostic messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-26 14:59 +0100
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-05-26 16:58 +0200
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-26 16:19 +0100
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-05-27 08:45 +0200
Re: Spurious diagnostic messages David Thompson <dave.thompson2@verizon.net> - 2015-06-21 12:46 -0400
Re: Spurious diagnostic messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-21 20:41 +0100
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-06-21 13:27 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 10:19 -0700
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-07-11 08:47 +1200
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 13:40 -0700
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-07-21 13:49 +0200
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 20:17 -0700
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-07-26 16:54 +1200
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-31 01:25 -0700
Re: Spurious diagnostic messages David Kleinecke <dkleinecke@gmail.com> - 2015-07-31 17:46 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 06:00 -0700
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-08-02 16:31 +0200
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-24 13:13 -0700
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-08-25 08:36 +1200
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-07-31 09:01 -0700
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-08-01 08:13 +1200
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 01:08 -0500
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-08-02 14:29 -0700
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-08-03 09:15 +1200
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-08-03 08:22 -0700
Re: Spurious diagnostic messages Rosario19 <Ros@invalid.invalid> - 2015-08-22 08:24 +0200
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-08-22 19:24 +1200
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-24 11:02 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-08-24 20:13 +0100
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-08-30 13:30 +0000
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-08-25 08:12 +1200
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 16:56 -0500
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-08-03 08:36 -0700
Re: Spurious diagnostic messages David Kleinecke <dkleinecke@gmail.com> - 2015-08-03 17:32 -0700
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-08-03 18:41 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-24 11:04 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-07-26 11:08 +0100
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-07-26 15:35 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-07-27 00:17 +0100
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-27 00:53 +0000
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-07-27 08:19 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-01 10:10 -0700
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-08-01 13:43 -0700
Re: Spurious diagnostic messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-02 00:04 +0100
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 01:16 -0500
Re: Spurious diagnostic messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-02 12:21 +0100
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-08-02 19:42 +0200
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-24 09:58 -0700
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-08-24 22:22 +0200
Re: Spurious diagnostic messages Richard Damon <Richard@Damon-Family.org> - 2015-08-01 20:20 -0400
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 18:57 -0700
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-08-02 08:21 +1200
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-08-01 14:31 -0700
Re: Spurious diagnostic messages Tonton Th <tTh@nowhere.invalid> - 2015-08-01 22:26 +0000
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 01:10 -0500
Re: Spurious diagnostic messages James Kuyper <jameskuyper@verizon.net> - 2015-08-02 09:02 -0400
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-08-02 14:23 +0100
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-08-02 15:31 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 09:01 -0700
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-08-02 16:56 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-03 10:18 -0700
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-08-03 12:10 +1200
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-24 10:52 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-08-24 20:01 +0100
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-08-25 08:16 +1200
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-08-03 14:11 +0100
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-08-04 10:56 +0000
Re: Spurious diagnostic messages David Kleinecke <dkleinecke@gmail.com> - 2015-08-01 16:52 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-08-02 12:59 +0100
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-09 13:39 -0700
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-08-02 13:37 +0200
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-08-02 13:17 +0100
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-08-02 19:45 +0200
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-08-02 15:52 -0700
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-08-03 09:34 +0200
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-08-04 11:04 +0000
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-08-04 09:07 -0700
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-08-09 13:28 +0000
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 14:00 -0500
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 11:31 -0700
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-09-06 10:47 +0200
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-09-06 13:27 -0700
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-08-02 15:53 -0700
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-08-02 15:45 -0700
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-08-03 09:40 +0200
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-24 11:41 -0700
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-08-04 11:23 +0000
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-08-04 09:12 -0700
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-08-09 13:33 +0000
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 10:59 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-09-06 22:21 +0100
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-09-07 13:44 +1200
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-20 10:44 -0700
Re: Spurious diagnostic messages bart4858@gmail.com - 2015-05-20 13:42 -0700
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-20 14:17 -0700
Re: Spurious diagnostic messages gazelle@shell.xmission.com (Kenny McCormack) - 2015-05-20 21:25 +0000
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-05-23 10:17 +0000
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-05-23 10:15 +0000
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-23 11:46 +0100
Re: Spurious diagnostic messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-23 17:22 +0100
Re: Spurious diagnostic messages Phil Carmody <pc+usenet@asdf.org> - 2015-05-25 11:49 +0300
Re: Spurious diagnostic messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-25 10:50 +0100
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-23 15:57 -0500
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-23 22:51 +0100
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-23 19:01 -0700
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-23 22:50 -0500
Re: Spurious diagnostic messages Morris Dovey <mrdovey@iedu.com> - 2015-05-23 23:41 -0500
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-24 00:40 -0500
Re: Spurious diagnostic messages asetofsymbols@gmail.com - 2015-05-24 02:57 -0700
Re: Spurious diagnostic messages Morris Dovey <mrdovey@iedu.com> - 2015-05-24 07:40 -0500
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-24 14:24 +0100
Re: Spurious diagnostic messages Morris Dovey <mrdovey@iedu.com> - 2015-05-24 09:23 -0500
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-05-24 15:36 +0100
Re: Spurious diagnostic messages James Kuyper <jameskuyper@verizon.net> - 2015-05-24 13:10 -0400
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 07:44 -0700
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-24 19:26 -0500
Re: Spurious diagnostic messages Morris Dovey <mrdovey@iedu.com> - 2015-05-25 00:51 -0500
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-25 15:48 -0500
Re: Spurious diagnostic messages Morris Dovey <mrdovey@iedu.com> - 2015-05-26 02:36 -0500
Re: Spurious diagnostic messages Morris Dovey <mrdovey@iedu.com> - 2015-05-26 13:23 -0500
Re: Spurious diagnostic messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-27 00:55 +0100
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-05-29 12:28 +0000
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-29 13:44 +0100
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-05-29 15:55 +0000
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-29 18:17 +0100
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-29 10:52 -0700
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-26 13:27 -0500
Re: Spurious diagnostic messages Morris Dovey <mrdovey@iedu.com> - 2015-05-26 21:09 -0500
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-27 00:03 -0500
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-27 00:59 -0500
Re: Spurious diagnostic messages Morris Dovey <mrdovey@iedu.com> - 2015-05-27 01:15 -0500
Re: Spurious diagnostic messages James Kuyper <jameskuyper@verizon.net> - 2015-05-27 13:34 -0400
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-27 14:07 -0500
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-27 19:53 +0000
Re: Spurious diagnostic messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-27 21:21 +0100
Re: Spurious diagnostic messages luser droog <luser.droog@gmail.com> - 2015-05-27 21:45 -0700
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-28 17:36 -0500
Re: Spurious diagnostic messages James Kuyper <jameskuyper@verizon.net> - 2015-05-27 10:36 -0400
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-05-27 16:54 +0200
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-27 16:08 +0100
Re: Spurious diagnostic messages Les Cargill <lcargill99@comcast.com> - 2015-05-27 12:18 -0500
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-27 18:39 +0100
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-05-27 22:04 +0200
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-27 21:38 +0100
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-27 19:54 -0500
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-27 19:58 -0500
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-05-28 14:24 +0200
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-27 13:51 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 11:08 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 11:05 -0700
Re: Spurious diagnostic messages gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-10 18:08 +0000
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 07:55 -0700
Re: Spurious diagnostic messages gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-11 15:02 +0000
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-07-21 14:08 +0200
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-07-21 13:27 +0100
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-07-21 15:30 +0200
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-07-22 15:04 +0000
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 10:27 -0700
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-07-21 13:55 +0200
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 14:18 -0700
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-08-02 20:16 +0200
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 09:49 -0700
Re: Spurious diagnostic messages Morris Dovey <mrdovey@iedu.com> - 2015-05-27 22:20 -0500
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-28 10:28 +0100
Re: Spurious diagnostic messages Morris Dovey <mrdovey@iedu.com> - 2015-05-28 06:00 -0500
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-27 10:22 +0100
Re: Spurious diagnostic messages Morris Dovey <mrdovey@iedu.com> - 2015-05-27 10:32 -0500
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-05-27 17:08 +0100
Re: Spurious diagnostic messages Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2015-05-28 15:49 +0200
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-05-28 15:03 +0100
Re: Spurious diagnostic messages James Kuyper <jameskuyper@verizon.net> - 2015-05-28 14:35 -0400
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-28 16:54 +0100
Re: Spurious diagnostic messages jadill33@gmail.com - 2015-05-28 10:32 -0700
Re: Spurious diagnostic messages Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2015-05-29 10:17 +0200
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-27 10:40 -0700
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-27 19:56 +0000
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-27 13:46 -0700
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-27 21:16 +0000
Re: Spurious diagnostic messages Morris Dovey <mrdovey@iedu.com> - 2015-05-27 15:47 -0500
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-27 14:08 -0700
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-05-27 22:11 +0100
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-27 20:10 -0500
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-05-28 02:21 +0100
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-28 03:21 +0000
Re: Spurious diagnostic messages luser droog <luser.droog@gmail.com> - 2015-05-27 22:17 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-27 22:22 +0100
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-05-28 14:52 +0200
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-27 18:55 +0100
Re: Spurious diagnostic messages Morris Dovey <mrdovey@iedu.com> - 2015-05-27 15:31 -0500
Re: Spurious diagnostic messages Phil Carmody <pc+usenet@asdf.org> - 2015-05-25 12:11 +0300
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-25 11:04 +0100
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-25 12:30 -0700
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-25 15:41 -0500
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-25 15:20 -0500
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-24 10:57 +0100
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-25 14:31 -0500
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-25 22:30 +0100
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-25 17:56 -0500
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-05-29 12:34 +0000
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-29 14:04 +0100
Re: Spurious diagnostic messages Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2015-05-29 15:28 +0200
Re: Spurious diagnostic messages raltbos@xs4all.nl (Richard Bos) - 2015-06-05 15:18 +0000
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-05-29 15:31 +0200
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-17 15:35 -0500
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-17 07:56 -0700
Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-05-17 16:14 +0100
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-17 12:57 -0700
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-17 15:46 +0000
Re: Spurious diagnostic messages James Kuyper <jameskuyper@verizon.net> - 2015-05-18 11:10 -0400
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-18 08:56 -0700
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-18 18:09 +0000
Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-18 18:03 +0000
Re: Spurious diagnostic messages James Kuyper <jameskuyper@verizon.net> - 2015-05-18 14:41 -0400
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-17 15:39 -0500
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-17 13:58 -0700
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-13 19:17 -0700
Re: Spurious diagnostic messages Nathan Wagner <nw@hydaspes.if.org> - 2015-05-14 09:54 +0000
Re: Spurious diagnostic messages Stephen Sprunk <stephen@sprunk.org> - 2015-05-14 08:57 -0500
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-14 08:31 -0700
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-14 08:33 -0700
Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-05-14 14:37 +1200
Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-05-14 13:13 +0200
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-15 16:26 -0500
Re: Spurious diagnostic messages Robert Wessel <robertwessel2@yahoo.com> - 2015-05-13 18:44 -0500
Re: Spurious diagnostic messages David Thompson <dave.thompson2@verizon.net> - 2015-06-21 12:46 -0400
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-22 07:37 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-12 11:23 -0700
Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-05-12 13:08 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-22 06:32 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-28 12:30 -0700
Re: Spurious diagnostic messages James Dow Allen <gmail@jamesdowallen.nospam> - 2015-04-29 04:07 +0000
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 07:48 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-25 03:32 -0700
Re: Spurious diagnostic messages Richard Heathfield <rjh@cpax.org.uk> - 2015-04-26 09:33 +0100
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-26 07:37 -0700
Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-25 04:01 -0700
Page 4 of 22 — ← Prev page 1 2 3 [4] 5 6 … 22 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-12 18:26 +0100 |
| Message-ID | <mitd1a$soh$1@dont-email.me> |
| In reply to | #61913 |
On 12/05/15 18:11, Keith Thompson wrote: <snip> > The standard integer types are _Bool and signed and unsigned char, > short, int, long, and long long. The integer types are those plus > any extended integer types. (Plain char doesn't seem to fit into > that scheme, which I find odd.) It /is/ odd, but for fairly unremarkable historical reasons. A char has to be able to store, with a non-negative value, every character in the basic execution character set. EBCDIC has some fairly important characters with code points greater than 127. On an EBCDIC system in which 8-bit char is considered desirable, implementations are more or less forced to make char unsigned. We have some choices: 1) outlaw EBCDIC; 2) force ASCII-based implementations to make char unsigned; 3) make char at least 9 bits rather than 8; 4) live with a weird char, like we do now. If we do (1), IBM will sulk. If we do (2), GNU, Microsoft, etc will sulk (and we'll introduce a different anomaly, that of char being unsigned by default whereas short, int, long, and long long, are signed by default. If we do (3), *everybody* will sulk. But if we go for (4), we don't have to change anything, which is always a popular option. -- 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-12 11:29 -0700 |
| Message-ID | <87pp65ejj1.fsf@kst-u.example.com> |
| In reply to | #61914 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 12/05/15 18:11, Keith Thompson wrote:
>
> <snip>
>
>> The standard integer types are _Bool and signed and unsigned char,
>> short, int, long, and long long. The integer types are those plus
>> any extended integer types. (Plain char doesn't seem to fit into
>> that scheme, which I find odd.)
>
> It /is/ odd, but for fairly unremarkable historical reasons. A char
> has to be able to store, with a non-negative value, every character in
> the basic execution character set. EBCDIC has some fairly important
> characters with code points greater than 127. On an EBCDIC system in
> which 8-bit char is considered desirable, implementations are more or
> less forced to make char unsigned.
>
> We have some choices:
>
> 1) outlaw EBCDIC;
> 2) force ASCII-based implementations to make char unsigned;
> 3) make char at least 9 bits rather than 8;
> 4) live with a weird char, like we do now.
>
> If we do (1), IBM will sulk.
>
> If we do (2), GNU, Microsoft, etc will sulk (and we'll introduce a
> different anomaly, that of char being unsigned by default whereas
> short, int, long, and long long, are signed by default.
>
> If we do (3), *everybody* will sulk.
>
> But if we go for (4), we don't have to change anything, which is
> always a popular option.
Sure, I understand all that, and I'm not suggesting a change. (I
wouldn't mind requiring plain char to be unsigned, but that's probably
not going to happen, and it could have performance implications for some
systems.Z)
If I had been writing section 6.2.5 of the standard, I'd include
plain "char" in the list of standard integer types. Clearly it's
standard, and integer, and a type, so excluding it seems odd.
Currently, the standard defines the *standard signed integer types*
as:
signed char
short
int
long
long long
the *standard unsigned integer types* as:
_Bool
unsigned char
unsigned short
unsigned int
unsigned long
unsigned long long
and the *standard integer types* as the standard signed integer types
and the standard unsigned integer types.
6.2.5p17 defines the category of *integer types* as the signed and
unsigned integer types, plain char, and the enumerated types. So plain
char is an *integer type* but not a *standard ineteger type*.
Furthermore, though char is an integer type and is either signed or
unsigned, it is neither a *signed integer type* nor an *unsigned integer
type*.
I don't think the standard uses these categories in a way that causes
real problems, but I find it unnecessarily confusing.
I suggest that it would have made more sense to say that plain char
is either one of the standard signed integer types or one of the
standard unsigned integer types (an implementation-defined choice)
*or* to define the *standard integer types* as the standard signed
integer types, the standard unsigned integer types, and plain char.
--
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-05-13 09:14 +0200 |
| Message-ID | <miuti5$l79$1@dont-email.me> |
| In reply to | #61921 |
On 12/05/15 20:29, Keith Thompson wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: >> On 12/05/15 18:11, Keith Thompson wrote: >> >> <snip> >> >>> The standard integer types are _Bool and signed and unsigned char, >>> short, int, long, and long long. The integer types are those plus >>> any extended integer types. (Plain char doesn't seem to fit into >>> that scheme, which I find odd.) >> >> It /is/ odd, but for fairly unremarkable historical reasons. A char >> has to be able to store, with a non-negative value, every character in >> the basic execution character set. EBCDIC has some fairly important >> characters with code points greater than 127. On an EBCDIC system in >> which 8-bit char is considered desirable, implementations are more or >> less forced to make char unsigned. >> >> We have some choices: >> >> 1) outlaw EBCDIC; >> 2) force ASCII-based implementations to make char unsigned; >> 3) make char at least 9 bits rather than 8; >> 4) live with a weird char, like we do now. >> >> If we do (1), IBM will sulk. Isn't EBCDIC only used in really old systems? I have always thought the C standard committee should make a clean break at some point and say that with C15 (for example) they get rid of the cruft and complications required to support weird and/or outdated systems. People programming dinosaurs can stick to C11 or before. Then they could drop EBCDIC support and enshrine ASCII (but keep the choice of utf-8, latin-9, etc.), mandate 8-bit char, 2's complement integers, etc. It would simplify many aspects of the language and work well with every modern system. >> >> If we do (2), GNU, Microsoft, etc will sulk (and we'll introduce a >> different anomaly, that of char being unsigned by default whereas >> short, int, long, and long long, are signed by default. gcc works fine with "-funsigned-char", and some gcc targets have unsigned plain chars by default. But of course some programmers write code that makes assumptions about the signedness of plain char - even though they are wrong to do so, it's not a good idea to change such things. >> >> If we do (3), *everybody* will sulk. /I/ certainly would! >> >> But if we go for (4), we don't have to change anything, which is >> always a popular option. And it's easy to implement :-) > > Sure, I understand all that, and I'm not suggesting a change. (I > wouldn't mind requiring plain char to be unsigned, but that's probably > not going to happen, and it could have performance implications for some > systems.Z) I would prefer plain char to be unsigned - it is on some of the targets I use, and seems much more natural to me. It just doesn't make sense to have a "negative" character (and small integers in my code use int8_t or uint8_t, not "char"). For some targets, unsigned chars can be noticeably more efficient for arithmetic than signed chars, so performance can swing both ways. > > If I had been writing section 6.2.5 of the standard, I'd include > plain "char" in the list of standard integer types. Clearly it's > standard, and integer, and a type, so excluding it seems odd. > > Currently, the standard defines the *standard signed integer types* > as: > signed char > short > int > long > long long > the *standard unsigned integer types* as: > _Bool > unsigned char > unsigned short > unsigned int > unsigned long > unsigned long long > and the *standard integer types* as the standard signed integer types > and the standard unsigned integer types. I suppose _Bool is the odd one out, there being no corresponding "signed _Bool". > > 6.2.5p17 defines the category of *integer types* as the signed and > unsigned integer types, plain char, and the enumerated types. So plain > char is an *integer type* but not a *standard ineteger type*. > Furthermore, though char is an integer type and is either signed or > unsigned, it is neither a *signed integer type* nor an *unsigned integer > type*. > > I don't think the standard uses these categories in a way that causes > real problems, but I find it unnecessarily confusing. > > I suggest that it would have made more sense to say that plain char > is either one of the standard signed integer types or one of the > standard unsigned integer types (an implementation-defined choice) > *or* to define the *standard integer types* as the standard signed > integer types, the standard unsigned integer types, and plain char. > I think it would have been better to define a category "integer types" consisting of the signed and unsigned integer types, and a category "discrete types" consisting of the "integer types", plain char, and enumerated types. Arithmetic should then only be allowed on true "integer types", while the other discrete types had a restricted set of operations (including comparisons, but not arithmetic operators). Then the distinction would make sense, and improve type safety in C programming.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-13 11:55 +0100 |
| Message-ID | <mivahn$vfj$1@dont-email.me> |
| In reply to | #61931 |
On 13/05/15 08:14, David Brown wrote: > Isn't EBCDIC only used in really old systems? Spoken like a true PC junkie. :-) Which reminds me: isn't ASCII only used in really tiny systems? -- 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-05-13 14:55 +0200 |
| Message-ID | <mivhht$o95$1@dont-email.me> |
| In reply to | #61933 |
On 13/05/15 12:55, Richard Heathfield wrote: > On 13/05/15 08:14, David Brown wrote: > >> Isn't EBCDIC only used in really old systems? > > Spoken like a true PC junkie. :-) Well, PC downwards. I don't do mainframes, minis, etc. > > Which reminds me: isn't ASCII only used in really tiny systems? > The point of ASCII is that apart from EBCDIC, everyone agrees on the first 128 characters. And those first 128 characters are sufficient for a large proportion of programs. We won't get everyone to agree about anything beyond that, so there is no point in trying.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-13 14:35 +0100 |
| Message-ID | <mivjtl$1e6$1@dont-email.me> |
| In reply to | #61934 |
On 13/05/15 13:55, David Brown wrote: > On 13/05/15 12:55, Richard Heathfield wrote: >> On 13/05/15 08:14, David Brown wrote: >> >>> Isn't EBCDIC only used in really old systems? >> >> Spoken like a true PC junkie. :-) > > Well, PC downwards. I don't do mainframes, minis, etc. > >> >> Which reminds me: isn't ASCII only used in really tiny systems? >> > > The point of ASCII is that apart from EBCDIC, everyone agrees on the > first 128 characters. So are you claiming that a 7-bit code that has been standardised is a 7-bit code that has been standardised? Outrageous! :-) The point of EBCDIC is that, like it or not, big iron runs it, *almost* without exception, so we're kinda stuck with it for now (although there are signs that IBM is slowly edging towards ASCII). > And those first 128 characters are sufficient for > a large proportion of programs. We won't get everyone to agree about > anything beyond that, so there is no point in trying. Unfortunately, EBCDIC will be with us for some time to come (decades at least, I should imagine), so if we want our C programs to run on big iron (and, believe it or not, some of us really really do), we're kind of stuck with a weird char. -- 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-13 08:24 -0700 |
| Message-ID | <878ucsec0i.fsf@kst-u.example.com> |
| In reply to | #61935 |
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> Unfortunately, EBCDIC will be with us for some time to come (decades
> at least, I should imagine), so if we want our C programs to run on
> big iron (and, believe it or not, some of us really really do), we're
> kind of stuck with a weird char.
If the next C standard were incompatible with EBCDIC (for example,
requiring 'a' + 25 == 'z', or even 'a' == 97), IBM would continue
to sell and use C-like compilers that use EBCDIC. They'd probably
just claim conformance to an earlier edition of the standard (have
they adopted C11? C99?). Or, if the new standard had other features
IBM finds useful, they'd just implement them and acknowledge the
non-conformance of the character set.
The problem is that it would fragment the language, and encourage
programmers to write "portable" C code that wouldn't work on IBM
mainframes.
In any case, I think IBM has enough influence on the C standard
committee that this isn't going to happen any time soon.
--
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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-05-13 18:47 -0500 |
| Message-ID | <5io7lal70o2bntlok0e3o070ae265qss28@4ax.com> |
| In reply to | #61940 |
On Wed, 13 May 2015 08:24:29 -0700, Keith Thompson <kst-u@mib.org> wrote: >If the next C standard were incompatible with EBCDIC (for example, >requiring 'a' + 25 == 'z', or even 'a' == 97), IBM would continue >to sell and use C-like compilers that use EBCDIC. They'd probably >just claim conformance to an earlier edition of the standard (have >they adopted C11? C99?). AFAIK, the zOS compiler is pretty complete on C99, and has partial C11 and C++11 support.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-05-13 21:15 +0200 |
| Message-ID | <mj07q7$h2p$1@dont-email.me> |
| In reply to | #61935 |
On 13/05/15 15:35, Richard Heathfield wrote: > On 13/05/15 13:55, David Brown wrote: >> On 13/05/15 12:55, Richard Heathfield wrote: >>> On 13/05/15 08:14, David Brown wrote: >>> >>>> Isn't EBCDIC only used in really old systems? >>> >>> Spoken like a true PC junkie. :-) >> >> Well, PC downwards. I don't do mainframes, minis, etc. >> >>> >>> Which reminds me: isn't ASCII only used in really tiny systems? >>> >> >> The point of ASCII is that apart from EBCDIC, everyone agrees on the >> first 128 characters. > > So are you claiming that a 7-bit code that has been standardised is a > 7-bit code that has been standardised? Outrageous! :-) > > The point of EBCDIC is that, like it or not, big iron runs it, *almost* > without exception, so we're kinda stuck with it for now (although there > are signs that IBM is slowly edging towards ASCII). > >> And those first 128 characters are sufficient for >> a large proportion of programs. We won't get everyone to agree about >> anything beyond that, so there is no point in trying. > > Unfortunately, EBCDIC will be with us for some time to come (decades at > least, I should imagine), so if we want our C programs to run on big > iron (and, believe it or not, some of us really really do), we're kind > of stuck with a weird char. > That's fine - I am not suggesting that C compilers drop support for these systems. I am just wondering if such systems need support from newer C standards - and if it would be practical to say that if a program is written to C15 (or whatever), then it the character set must be 8-bit, and the first 128 characters must be ASCII. This doesn't change C for EBCDIC computers - it merely hinders them from running C15 programs. But it would make life a little easier for everyone who /doesn't/ write code to run on those systems - as well as making the standard itself a little shorter and clearer. As another example, consider support for char's wider than 8-bit. Outside of mainframes, the most common class of systems with wider char's are DSP devices - they sometimes have 16-bit or even 32-bit chars (with a few really weird systems having 24-bit chars). But would there be any disadvantage of saying that these cannot support C15, or at least that they cannot do so efficiently? I don't think anything would be lost - few compilers for such devices support anything beyond C99 (and not all have come that far!). And of course developers would be happy to see such tools support 8-bit chars, even if it meant somewhat less efficient generated code.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-05-13 19:40 +0000 |
| Message-ID | <mj09av$4b2$1@speranza.aioe.org> |
| In reply to | #61950 |
David Brown <david.brown@hesbynett.no> wrote: (snip) > That's fine - I am not suggesting that C compilers drop support for > these systems. I am just wondering if such systems need support from > newer C standards - and if it would be practical to say that if a > program is written to C15 (or whatever), then it the character set must > be 8-bit, and the first 128 characters must be ASCII. This doesn't > change C for EBCDIC computers - it merely hinders them from running C15 > programs. But it would make life a little easier for everyone who > /doesn't/ write code to run on those systems - as well as making the > standard itself a little shorter and clearer. IBM will probably disagree. I believe they have good C support for z/OS. > As another example, consider support for char's wider than 8-bit. > Outside of mainframes, the most common class of systems with wider > char's are DSP devices - they sometimes have 16-bit or even 32-bit chars > (with a few really weird systems having 24-bit chars). But would there > be any disadvantage of saying that these cannot support C15, or at least > that they cannot do so efficiently? I don't think anything would be > lost - few compilers for such devices support anything beyond C99 (and > not all have come that far!). And of course developers would be happy > to see such tools support 8-bit chars, even if it meant somewhat less > efficient generated code. We have a C compiler on the PDP-10, but I don't know that anyone expects C15 for that. It does have 9 bit char. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-13 21:08 +0100 |
| Message-ID | <mj0at0$tuo$1@dont-email.me> |
| In reply to | #61951 |
On 13/05/2015 20:40, glen herrmannsfeldt wrote: > David Brown <david.brown@hesbynett.no> wrote: > (snip) >> That's fine - I am not suggesting that C compilers drop support for >> these systems. I am just wondering if such systems need support from >> newer C standards - and if it would be practical to say that if a >> program is written to C15 (or whatever), then it the character set must >> be 8-bit, and the first 128 characters must be ASCII. This doesn't >> change C for EBCDIC computers - it merely hinders them from running C15 >> programs. But it would make life a little easier for everyone who >> /doesn't/ write code to run on those systems - as well as making the >> standard itself a little shorter and clearer. > > IBM will probably disagree. I believe they have good C support > for z/OS. They can keep EBCDIC if they want, but why inflict it on everyone else? Especially as it was such a crazy character mapping. People can spend lifetimes programming and not come across EBCDIC, yet they are denied language features such as: case 'A'..'F', and EBCDIC is usually quoted as one of the reasons. > We have a C compiler on the PDP-10, but I don't know that anyone > expects C15 for that. It does have 9 bit char. The one I used had mainly 7-bit characters (not in C). And used ASCII. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-05-13 20:52 +0000 |
| Message-ID | <mj0diq$f3t$1@speranza.aioe.org> |
| In reply to | #61954 |
Bartc <bc@freeuk.com> wrote: >> David Brown <david.brown@hesbynett.no> wrote: >> (snip) >>> That's fine - I am not suggesting that C compilers drop support for >>> these systems. I am just wondering if such systems need support from >>> newer C standards - and if it would be practical to say that if a >>> program is written to C15 (or whatever), then it the character set must >>> be 8-bit, and the first 128 characters must be ASCII. (snip, then I wrote) >> IBM will probably disagree. I believe they have good C support >> for z/OS. > They can keep EBCDIC if they want, but why inflict it on > everyone else? Especially as it was such a crazy > character mapping. Seems that ASCII and EBCDIC are about the same age. IBM was considering ASCII-8 (which isn't ASCII-7 with an extra bit on the left.) but the standard never came. > People can spend lifetimes programming and not come across EBCDIC, > yet they are denied language features such as: case 'A'..'F', > and EBCDIC is usually quoted as one of the reasons. You can use 'A'..'F' just fine. There are some other codes between 'I' and 'J', and also between 'R' and 'S', but not many printable characters. Specifically, only '}' and '\'. >> We have a C compiler on the PDP-10, but I don't know that anyone >> expects C15 for that. It does have 9 bit char. > The one I used had mainly 7-bit characters (not in C). And used ASCII. The PDP-10 file system stores 7-bit ASCII, five to a 36 bit word. But C requires that char be at least 8 bits, and that a word (int) be an integral multiple of char. That leaves 9, 12, 18, and 36 bits as possible choices. -- glen
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2015-05-13 21:06 +0000 |
| Message-ID | <mj0eda$gof$1@news.xmission.com> |
| In reply to | #61955 |
In article <mj0diq$f3t$1@speranza.aioe.org>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
...
>> People can spend lifetimes programming and not come across EBCDIC,
>> yet they are denied language features such as: case 'A'..'F',
>> and EBCDIC is usually quoted as one of the reasons.
>
>You can use 'A'..'F' just fine. There are some other codes between
>'I' and 'J', and also between 'R' and 'S', but not many printable
>characters. Specifically, only '}' and '\'.
I think you missed Bart's point. He was (I believe) talking about
"language features", not encoding specifics.
(What follows is speculation as to what Bart was talking about; I may be
wrong, but if I am, then consider it to be tagged to me and not to him)
The problem is that because C wants to support weird character sets like
EBCDIC, so as a result we can't have nice things. Specifically, we can't
have as part of the syntax of "switch":
case 'A'..'F':
puts("Valid grade!");
I'm pretty sure other languages support this - I think Pascal does.
--
This is the GOP's problem. When you're at the beginning of the year
and you've got nine Democrats running for the nomination, maybe one or
two of them are Dennis Kucinich. When you have nine Republicans, seven
or eight of them are Michelle Bachmann.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-05-13 23:28 +0000 |
| Message-ID | <mj0mnm$4i8$1@speranza.aioe.org> |
| In reply to | #61956 |
Kenny McCormack <gazelle@shell.xmission.com> wrote:
(snip)
> I think you missed Bart's point. He was (I believe) talking about
> "language features", not encoding specifics.
> (What follows is speculation as to what Bart was talking about; I may be
> wrong, but if I am, then consider it to be tagged to me and not to him)
> The problem is that because C wants to support weird character sets like
> EBCDIC, so as a result we can't have nice things. Specifically, we can't
> have as part of the syntax of "switch":
> case 'A'..'F':
> puts("Valid grade!");
> I'm pretty sure other languages support this - I think Pascal does.
In both ASCII and EBCDIC, the characters 'A' through 'F' are contiguous,
so you could do that. (Seems to me a language design decision.)
There are some ranges that are not contiguous, and in all cases
it is up to the programmer to know how to use them.
There are plenty of programming mistakes you can make using
just ASCII characters.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2015-05-14 00:19 +0000 |
| Message-ID | <mj0pmu$nmm$1@news.xmission.com> |
| In reply to | #61957 |
In article <mj0mnm$4i8$1@speranza.aioe.org>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>Kenny McCormack <gazelle@shell.xmission.com> wrote:
>
>(snip)
>> I think you missed Bart's point. He was (I believe) talking about
>> "language features", not encoding specifics.
>
>> (What follows is speculation as to what Bart was talking about; I may be
>> wrong, but if I am, then consider it to be tagged to me and not to him)
>
>> The problem is that because C wants to support weird character sets like
>> EBCDIC, so as a result we can't have nice things. Specifically, we can't
>> have as part of the syntax of "switch":
>
>> case 'A'..'F':
>> puts("Valid grade!");
>
>> I'm pretty sure other languages support this - I think Pascal does.
>
>In both ASCII and EBCDIC, the characters 'A' through 'F' are contiguous,
>so you could do that.
If you think that what you've written is an answer to or an objection to
what I wrote, then you have completely missed the point of my post.
> (Seems to me a language design decision.)
Yes. That *is* the point. That C's syntax does not allow ranges on
switch() statements. And that, I speculate, part of the reason it doesn't
is because of wanting to support EBCDIC (and/or other weird encodings).
I'm going to quote myself here. Please read the following again, carefully:
* The problem is that because C wants to support weird character sets like
* EBCDIC, so as a result we can't have nice things.
Note that the phrase "can't have nice things" is a current cliche. A nice
turn of phrase...
--
"I heard somebody say, 'Where's Nelson Mandela?' Well,
Mandela's dead. Because Saddam killed all the Mandelas."
George W. Bush, on the former South African president who
is still very much alive, Sept. 20, 2007
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-05-14 04:29 +0000 |
| Message-ID | <mj18b0$3gt$1@speranza.aioe.org> |
| In reply to | #61961 |
Kenny McCormack <gazelle@shell.xmission.com> wrote:
(snip)
>>> The problem is that because C wants to support weird character sets like
>>> EBCDIC, so as a result we can't have nice things. Specifically, we can't
>>> have as part of the syntax of "switch":
>>> case 'A'..'F':
>>> puts("Valid grade!");
>>> I'm pretty sure other languages support this - I think Pascal does.
(snip)
>>In both ASCII and EBCDIC, the characters 'A' through 'F' are contiguous,
>>so you could do that.
> If you think that what you've written is an answer to or an objection
> to what I wrote, then you have completely missed the point of my post.
That is possible, but I am not convinced. Do you have any reference
for the decision? Since a large fraction of switch/case use non-char
operands, this reason wouldn't apply.
Well, also, when I first learned switch/case I considered it the C
version of the Fortran computed GOTO, commonly implemented as a
branch table. Branch tables are a more obvious solution with a smaller
number of choices.
>> (Seems to me a language design decision.)
> Yes. That *is* the point. That C's syntax does not allow ranges on
> switch() statements. And that, I speculate, part of the reason it doesn't
> is because of wanting to support EBCDIC (and/or other weird encodings).
You can speculate that if you want, I speculate that it isn't that.
> I'm going to quote myself here. Please read the following again, carefully:
> * The problem is that because C wants to support weird character
> sets like EBCDIC, so as a result we can't have nice things.
> Note that the phrase "can't have nice things" is a current cliche.
> A nice turn of phrase...
There is a long list of features that other languages have and C
doesn't. We can speculate all we want, but the most important reason
is that C was meant to be a fairly simple language.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-14 09:57 +0100 |
| Message-ID | <mj1o0c$56o$1@dont-email.me> |
| In reply to | #61957 |
On 14/05/2015 00:28, glen herrmannsfeldt wrote:
> Kenny McCormack <gazelle@shell.xmission.com> wrote:
>
> (snip)
>> I think you missed Bart's point. He was (I believe) talking about
>> "language features", not encoding specifics.
>
>> (What follows is speculation as to what Bart was talking about; I may be
>> wrong, but if I am, then consider it to be tagged to me and not to him)
>
>> The problem is that because C wants to support weird character sets like
>> EBCDIC, so as a result we can't have nice things. Specifically, we can't
>> have as part of the syntax of "switch":
>
>> case 'A'..'F':
>> puts("Valid grade!");
>
>> I'm pretty sure other languages support this - I think Pascal does.
>
> In both ASCII and EBCDIC, the characters 'A' through 'F' are contiguous,
> so you could do that. (Seems to me a language design decision.)
You keep saying that. Perhaps I should have chosen a different example!
(I had no idea where the breaks in the EBCDIC set were.) The point is
that because of those breaks in the sequence - wherever they happen to
be - you can't use case letter1 .. letter2: in general.
But it does make you wonder why they bothered making some subsets of the
alphabet have consecutive codes at all, rather than just make them all
arbitrary and help keep everyone on their toes.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-05-14 04:56 -0500 |
| Message-ID | <r1r8lapa7v65jqm74tmbbhgj6jaa6ko25b@4ax.com> |
| In reply to | #61978 |
On Thu, 14 May 2015 09:57:49 +0100, Bartc <bc@freeuk.com> wrote:
>On 14/05/2015 00:28, glen herrmannsfeldt wrote:
>> Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>
>> (snip)
>>> I think you missed Bart's point. He was (I believe) talking about
>>> "language features", not encoding specifics.
>>
>>> (What follows is speculation as to what Bart was talking about; I may be
>>> wrong, but if I am, then consider it to be tagged to me and not to him)
>>
>>> The problem is that because C wants to support weird character sets like
>>> EBCDIC, so as a result we can't have nice things. Specifically, we can't
>>> have as part of the syntax of "switch":
>>
>>> case 'A'..'F':
>>> puts("Valid grade!");
>>
>>> I'm pretty sure other languages support this - I think Pascal does.
>>
>> In both ASCII and EBCDIC, the characters 'A' through 'F' are contiguous,
>> so you could do that. (Seems to me a language design decision.)
>
>You keep saying that. Perhaps I should have chosen a different example!
>(I had no idea where the breaks in the EBCDIC set were.) The point is
>that because of those breaks in the sequence - wherever they happen to
>be - you can't use case letter1 .. letter2: in general.
>
>But it does make you wonder why they bothered making some subsets of the
>alphabet have consecutive codes at all, rather than just make them all
>arbitrary and help keep everyone on their toes.
EBCDIC derives from earlier codes (all with "BCD" somewhere in the
name) and punch card usage.
The three groups of uppercase letters on IBM standard punch cards use
a 12/11/0 punch, plus a 1-9 punch. That first punch effectively
represents the high nibble of the EBCDIC code (0xc0/0xd0/0xe0) for the
characters, and second punch becomes the low nibble of the code. The
excess code point, oxe1, is used for a slash. The digits are just
single 0-9 punches.
704 BCD followed a similar pattern, despite having 6-bit characters,
and the digits and three groups of alphabetic characters were in the
0x00/0x10/0x20/0x30 ranges.
In the 704 days relating the internal representation to the punch card
format made some sense. As mentioned elsewhere IBM had intended an
ASCII variant for S/360, but both the standard and the ASCII
peripherals were late (many of the card devices and printers - "unit
record" gear - were enhanced/adapted versions of devices from
pre-S/360 systems), so the OS and everything else got written with the
updated BCD code, and despite having an ASCII mode, S/360 never used
it.
ASCII has some odd choices too, but it's clearly a much cleaner
organization.
But if you want discontiguous (and disordered!) letters, Baudot and
it's various descendents will do the trick.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-14 11:34 +0100 |
| Message-ID | <mj1tko$p3n$1@dont-email.me> |
| In reply to | #61980 |
On 14/05/15 10:56, Robert Wessel wrote:
<snip>
> But if you want discontiguous (and disordered!) letters, Baudot and
> it's various descendents will do the trick.
The designers of the latest version of the DeathStation 9000, in a rare
spirit of generosity and amity towards their customers, decided that
their character set (which is of course 100% conforming) would have the
following layout:
Code Point 0: null (obviously), followed by no fewer than 81
DeathStation-specific code points which I won't go into here.
Then come Esc f1-f12 (in that order) PrtScr ScrollLock Break ESC F1-F12
PRTSCR SCROLLLOCK Pause
¬ ! " £ $ % ^ & * ( ) _ + Backspace Insert Home PageUp
`
(At this point, there is a note in the design document along the lines
of "growf!", as they realise they're going to have to break the logical
pattern at this point in order to remain conforming)
0 1 2 3 4 5 6 7 8 9 - = BACKSPACE INSERT HOME PAGEUP
Tab q w e r t y u i o p [ ] Newline Delete End PageDown
TAB Q W E R T Y U I O P { } Carriage DELETE END PAGEDOWN
CapsLock a s d f g h j k l ; ' #
CAPSLOCK A S D F G H J K L : @ ~
LeftShift \ z x c v b n m , . / RightShift UpArrow
LEFTSHIFT | Z X C V B N M < > ? RIGHTSHIFT UPARROW
LeftCtrl Meta Alt Space Metameta Metametameta RightCtrl LeftArrow
DownArrow RightArrow
LEFTCTRL META ALT SPACE METAMETA METAMETAMETA RIGHTCTRL LEFTARROW
DOWNARROW RIGHTARROW
In case you're curious, the DS9000 keyboard hardware distinguishes
between LEFTSHIFT (upper case left shift) and RIGHTSHIFT by remembering
which shift key was pressed first. Left first, you get RIGHTSHIFT. Right
first, you get LEFTSHIFT. But you have to be quick, or you just get
leftshift or rightshift instead.
You can order the very latest DS9000 by writing to:
The Purchasing Department
Armed Response Technologi%^t"\%Qaa^(`v9}NO CARRIER
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-05-14 17:24 +0000 |
| Message-ID | <mj2lnj$eem$2@speranza.aioe.org> |
| In reply to | #61985 |
Richard Heathfield <rjh@cpax.org.uk> wrote: (snip) > The designers of the latest version of the DeathStation 9000, in a rare > spirit of generosity and amity towards their customers, decided that > their character set (which is of course 100% conforming) would have the > following layout: (snip) > ¬ ! " £ $ % ^ & * ( ) _ + Backspace Insert Home PageUp and the real problem with ASCII, no ¬ sign. Very inconvenient for PL/I programming. -- glen
[toc] | [prev] | [next] | [standalone]
Page 4 of 22 — ← Prev page 1 2 3 [4] 5 6 … 22 Next page →
Back to top | Article view | comp.lang.c
csiph-web