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 5 of 22 — ← Prev page 1 … 3 4 [5] 6 7 … 22 Next page →
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-05-16 01:21 -0500 |
| Message-ID | <pdodladfbillqh250m0b0r63tk9ssma2mu@4ax.com> |
| In reply to | #61985 |
On Thu, 14 May 2015 11:34:02 +0100, Richard Heathfield
<rjh@cpax.org.uk> wrote:
>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
Is the collating sequence different on DS9000's manufactured for sale
in France?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-17 10:00 +0100 |
| Message-ID | <mj9l8s$70j$1@dont-email.me> |
| In reply to | #62095 |
On 16/05/15 07:21, Robert Wessel wrote: <snip> > Is the collating sequence different on DS9000's manufactured for sale > in France? Yes, and a different one still for Germany, and yet another for Russia (and yes, worryingly, DS9Ks are very popular in Russia for some reason). -- 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 Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2015-06-21 12:46 -0400 |
| Message-ID | <gvv7oatv748prbhr8umit2c64vle8avjba@4ax.com> |
| In reply to | #62139 |
On Sun, 17 May 2015 10:00:16 +0100, Richard Heathfield <rjh@cpax.org.uk> wrote: > On 16/05/15 07:21, Robert Wessel wrote: > > <snip> > > > Is the collating sequence different on DS9000's manufactured for sale > > in France? > > Yes, and a different one still for Germany, and yet another for Russia > (and yes, worryingly, DS9Ks are very popular in Russia for some reason). Why is this a factory option? Even IBM back in the 60s managed to do field mods, especially the widely rumored one to upgrade a lower-speed card sorter to a higher-rental higher-speed sorter by removing the speed reduction circuit. For that matter, DS9k ought to be able to detect its position by GPS and *automatically* set itself to the correct locale -- with the possible exception of cases where boundaries 'magically' move without warning, like Crimea. <G??>
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-21 13:20 -0400 |
| Message-ID | <mm6rmp$7e0$1@dont-email.me> |
| In reply to | #63725 |
On 06/21/2015 12:46 PM, David Thompson wrote: > On Sun, 17 May 2015 10:00:16 +0100, Richard Heathfield > <rjh@cpax.org.uk> wrote: > >> On 16/05/15 07:21, Robert Wessel wrote: >> >> <snip> >> >>> Is the collating sequence different on DS9000's manufactured for sale >>> in France? >> >> Yes, and a different one still for Germany, and yet another for Russia >> (and yes, worryingly, DS9Ks are very popular in Russia for some reason). > > Why is this a factory option? Even IBM back in the 60s managed to do > field mods, especially the widely rumored one to upgrade a lower-speed > card sorter to a higher-rental higher-speed sorter by removing the > speed reduction circuit. For that matter, DS9k ought to be able to > detect its position by GPS and *automatically* set itself to the > correct locale -- with the possible exception of cases where > boundaries 'magically' move without warning, like Crimea. <G??> The makers of the DS9000 are always looking for new ways to surprise their users - I'm sure that they will be quite interested in your suggestion. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-05-14 17:22 +0000 |
| Message-ID | <mj2lju$eem$1@speranza.aioe.org> |
| In reply to | #61980 |
Robert Wessel <robertwessel2@yahoo.com> wrote: (snip) > 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 six bit code days, there were multiple characters for some of the codes, with commercial and scientific systems using different ones. I believe the 026 keypunch came both ways, but otherwise you would learn what to type to get the character you wanted. > 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. Well, the ASCII-8 standard never came, still hasn't. Note that the 704 has to convert the input punches into BCD code in software. The hardware just reads in the punch positions. (Cards are read top to bottom, each punch row into two 36 bit words.) The 360 peripherals, and smaller 360 systems, convert punch codes to EBCDIC in microcode. That is, no look-up table. (EBCDIC punch codes allow only zero or one punch in rows 1 though 7, which allows for eight possibilities. That, along with the other five punch rows, gives 256 codes. Not all match so nicely to internal values, though.) > 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. Specifically, the codes used by Teletype corporation before the ASR33. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-05-16 01:59 -0500 |
| Message-ID | <mkodlap03b51tnecgprudnb4u6vf670b47@4ax.com> |
| In reply to | #62003 |
On Thu, 14 May 2015 17:22:07 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >Robert Wessel <robertwessel2@yahoo.com> wrote: > >(snip) >> 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 six bit code days, there were multiple characters for some >of the codes, with commercial and scientific systems using different >ones. I believe the 026 keypunch came both ways, but otherwise >you would learn what to type to get the character you wanted. > >> 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. > >Well, the ASCII-8 standard never came, still hasn't. I've never been clear on whether ASCII-8 was actually supposed to be an X3/ASA/USASI/ANSI standard, or it was just an IBM thing. While X2 considered eight bits as a possibility, I don't think it ever went anywhere. AS defined by IBM, ASCII-8 was ASCII(-7)*, with the high two bits shifted left one position, with the high bit duplicated into the vacated position. *With a few variations, especially in the control characters, from what the final ASCII was. Which may just be because ASCII(-7) was late.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-05-16 09:51 +0000 |
| Message-ID | <mj73vu$dbr$1@speranza.aioe.org> |
| In reply to | #62099 |
Robert Wessel <robertwessel2@yahoo.com> wrote: (snip, I wrote) >>In the six bit code days, there were multiple characters for some >>of the codes, with commercial and scientific systems using different >>ones. I believe the 026 keypunch came both ways, but otherwise >>you would learn what to type to get the character you wanted. (after someone else wrote) >>> 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. >>Well, the ASCII-8 standard never came, still hasn't. > I've never been clear on whether ASCII-8 was actually supposed to be > an X3/ASA/USASI/ANSI standard, or it was just an IBM thing. While X2 > considered eight bits as a possibility, I don't think it ever went > anywhere. AS defined by IBM, ASCII-8 was ASCII(-7)*, with the high > two bits shifted left one position, with the high bit duplicated into > the vacated position. As I understand it, if ASCII-8 was accepted, then OS/360 would have used it instead of EBCDIC. It wasn't, and it didn't. It would have been a challenge to get the card readers and such to use it, but that was about the time that 256 byte translation tables became affordable. It might have cost a little more, but not a lot more. But also, translation tables allowed for ease of conversion when needed. OS/360 can read and write AL tapes, and, not so much later, the 3705 can talk to ASCII terminals. > *With a few variations, especially in the control characters, from > what the final ASCII was. Which may just be because ASCII(-7) was > late. In addition to ^ and _ replacing up and back arrow. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-05-16 05:36 -0500 |
| Message-ID | <3k6elalmiqa49j22khkj9vimfuphjbj95h@4ax.com> |
| In reply to | #62108 |
On Sat, 16 May 2015 09:51:58 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >Robert Wessel <robertwessel2@yahoo.com> wrote: > >(snip, I wrote) >>>In the six bit code days, there were multiple characters for some >>>of the codes, with commercial and scientific systems using different >>>ones. I believe the 026 keypunch came both ways, but otherwise >>>you would learn what to type to get the character you wanted. > >(after someone else wrote) >>>> 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. > >>>Well, the ASCII-8 standard never came, still hasn't. > >> I've never been clear on whether ASCII-8 was actually supposed to be >> an X3/ASA/USASI/ANSI standard, or it was just an IBM thing. While X2 >> considered eight bits as a possibility, I don't think it ever went >> anywhere. AS defined by IBM, ASCII-8 was ASCII(-7)*, with the high >> two bits shifted left one position, with the high bit duplicated into >> the vacated position. > >As I understand it, if ASCII-8 was accepted, then OS/360 would >have used it instead of EBCDIC. It wasn't, and it didn't. I'm not sure I see the timing work out. While ASCII was planned for the S/360, and the standardization was underway, the S/360 project really got running at the end of 1961 (there were a couple of years of discussion on unification prior to that, much focusing on a proposed "8000" machine, which was never built). The first (partial) version of ASCII, missing the lower case letters and then some, wasn't published until early 1963. A more complete version was published later that year. It seems inconceivable that there would have been enough time to convert OS/360 to ASCII between then and 1964 (or even April 1965 when the first non-beta machines shipped to customers), especially since OS/360 was already a software development disaster by then. Even ignoring the issue of peripherals. Again, I've never seen a reference to "ASCII-8" outside of IBM. Even if that had been something X3 was considering, and it had been standardized on the same day the seven-bit code was standardized, I still don't see how it could have ended up in OS/360. ASCII in any form just wasn't there in time for it to be a realistic option for S/360.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-05-16 19:32 +0000 |
| Message-ID | <mj8603$9c2$1@speranza.aioe.org> |
| In reply to | #62109 |
Robert Wessel <robertwessel2@yahoo.com> wrote: (snip, I previously wrote) >>>>Well, the ASCII-8 standard never came, still hasn't. >>> I've never been clear on whether ASCII-8 was actually supposed to be >>> an X3/ASA/USASI/ANSI standard, or it was just an IBM thing. While X2 >>> considered eight bits as a possibility, I don't think it ever went >>> anywhere. AS defined by IBM, ASCII-8 was ASCII(-7)*, with the high >>> two bits shifted left one position, with the high bit duplicated into >>> the vacated position. >>As I understand it, if ASCII-8 was accepted, then OS/360 would >>have used it instead of EBCDIC. It wasn't, and it didn't. > I'm not sure I see the timing work out. While ASCII was planned for > the S/360, and the standardization was underway, the S/360 project > really got running at the end of 1961 (there were a couple of years of > discussion on unification prior to that, much focusing on a proposed > "8000" machine, which was never built). I recommend reading "Computer Architecture Concepts and Evolution" by Blaauw and Brooks. For one, it has many details on many different computers built over the years, but is especially detailed on the design of S/360 and OS/360. There is a lot of detail on different character sets, who did what, when, and why. Note that much of the development of OS/360 was done on 7090s. There weren't yet 360s to run it on. They at least thought about this problem in writing the PL/I (F) compiler and library. Routines have comments indicating that either they are independent of the character set used, or that they adopt the character set that they are assembled in. That is, that character set specific values are only used in character constants, and vice versa. If done right, the only changed needed is to convert the source and assemble with the new assembler! > The first (partial) version > of ASCII, missing the lower case letters and then some, wasn't > published until early 1963. A more complete version was published > later that year. It seems inconceivable that there would have been > enough time to convert OS/360 to ASCII between then and 1964 (or even > April 1965 when the first non-beta machines shipped to customers), > especially since OS/360 was already a software development disaster by > then. Even ignoring the issue of peripherals. If OS/360 development was done on the 7090, in BCDIC, it had to be converted somewhere along the line. It doesn't make so much difference which way it goes. > Again, I've never seen a reference to "ASCII-8" outside of IBM. Even > if that had been something X3 was considering, and it had been > standardized on the same day the seven-bit code was standardized, I > still don't see how it could have ended up in OS/360. Consider that the printer usually used with S/360, the 1403, is the printer that came from the 1401 series. (They didn't even renumber it.) To print, there is a mapping from the characters to the position on the print train, but note that position isn't any easier to find in EBCDIC than ASCII. (They are not, for example, in consecutive EBCDIC codes.) It is a little easier to translate card punch codes to EBCDIC, but not all that much harder to ASCII. It might take a little more microcode to do it. > ASCII in any form just wasn't there in time for it to be a realistic > option for S/360. Blaauw and Brooks description sounds like ASCII specifically wanted to be as incompatible with BCDIC as they could be. Now, the problem for IBM was to make current customers happy. That was easier converting to EBCDIC, not so different from BCDIC as ASCII-7 or ASCII-8. -- glen
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-05-14 17:13 +0000 |
| Message-ID | <mj2l3b$d54$1@speranza.aioe.org> |
| In reply to | #61978 |
Bartc <bc@freeuk.com> wrote: (snip, I wrote) >> 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. As noted earlier, EBCDIC and ASCII are about the same time, but EBCDIC traces back through BCDIC (most often just called BCD) to the punched card codes from years earlier. Even before anyone thought about computers. The codes match up with the punch codes on the cards, each letter having two punches. EBCDIC makes somewhat more sense than the BCDIC code, though. In any case, I am not convinced that this had anything to do with the development of C. If you find a reliable source that knows more, I would be interested to hear about it. -- glen
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-05-17 10:13 +0000 |
| Message-ID | <555869ae.4417359@news.xs4all.nl> |
| In reply to | #61957 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Kenny McCormack <gazelle@shell.xmission.com> wrote:
>
> > 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.
For example, assuming that all letters are within the original ASCII
range. This hasn't been true in Europe for decades.
Richard
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-05-13 18:54 -0500 |
| Message-ID | <fmo7lah5ifqk5kek15gk4l52ldfjpkvujs@4ax.com> |
| In reply to | #61956 |
On Wed, 13 May 2015 21:06:50 +0000 (UTC), gazelle@shell.xmission.com
(Kenny McCormack) wrote:
>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.
We *could* have that in C, but what it would mean, when using
character constants, would be quite implementation defined. Is
avoiding the inevitable unexpected performance of 'a'..'z' worth not
having the feature? You'd have exactly the same problem coding a
range like that in a if statement.
OTOH, I'm having trouble thinking of a time I wanted a character
range, but I've wanted a numeric range quite a few times (not that
those two cases are distinct in C).
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-14 01:31 +0100 |
| Message-ID | <mj0qba$nnp$1@dont-email.me> |
| In reply to | #61960 |
On 14/05/2015 00:54, Robert Wessel wrote:
> On Wed, 13 May 2015 21:06:50 +0000 (UTC), gazelle@shell.xmission.com
> (Kenny McCormack) wrote:
>> (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)
(You're spot on)
>> 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.
>
>
> We *could* have that in C, but what it would mean, when using
> character constants, would be quite implementation defined.
Why? Within the ASCII range of 32 to 127, and especially for digits and
letters, it would be well-defined.
Is
> avoiding the inevitable unexpected performance of 'a'..'z' worth not
> having the feature? You'd have exactly the same problem coding a
> range like that in a if statement.
Yes, and the same advantage. But there's a particular advantage in
having it available in a switch statement:
> OTOH, I'm having trouble thinking of a time I wanted a character
> range, but I've wanted a numeric range quite a few times (not that
> those two cases are distinct in C).
I use character ranges all the time. The following example is typical,
but I can only do this outside C because C doesn't allow it (one reason
for this is the business with EBCDIC):
int c
switch c
when 'A'..'Z','a'..'z','0'..'9','_','$' then
end switch
If I get my compiler to turn this into C, it produces this:
int c;
switch (c)
{
case 65:
case 66:
case 67:
case 68:
case 69:
case 70:
case 71:
case 72:
case 73:
case 74:
case 75:
case 76:
case 77:
case 78:
case 79:
case 80:
case 81:
case 82:
case 83:
case 84:
case 85:
case 86:
case 87:
case 88:
case 89:
case 90:
case 97:
case 98:
case 99:
case 100:
case 101:
case 102:
case 103:
case 104:
case 105:
case 106:
case 107:
case 108:
case 109:
case 110:
case 111:
case 112:
case 113:
case 114:
case 115:
case 116:
case 117:
case 118:
case 119:
case 120:
case 121:
case 122:
case 48:
case 49:
case 50:
case 51:
case 52:
case 53:
case 54:
case 55:
case 56:
case 57:
case 95:
case 36:
break;
default:;
}
OK, actual C will have 'A' instead of 65, and there might be several
cases per line to keep it more compact. But it's still a lot of typing!
BTW those 'A'..'Z' ranges are part of working code and they work
properly. But it need not be just because it assumes ASCII. If my
translator generated 'A' constants instead of 65, then the same C output
would compile in an EBCDIC system with the same 'A'..Z' range in the
input source, and work correctly!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-13 21:05 -0500 |
| Message-ID | <mj0vqi$srg$1@dont-email.me> |
| In reply to | #61962 |
On 13-May-15 19:31, Bartc wrote:
> On 14/05/2015 00:54, Robert Wessel wrote:
>> gazelle@shell.xmission.com (Kenny McCormack) wrote:
>>> case 'A'..'F': puts("Valid grade!");
>>>
>>> I'm pretty sure other languages support this - I think Pascal
>>> does.
>>
>> We *could* have that in C, but what it would mean, when using
>> character constants, would be quite implementation defined.
>
> Why? Within the ASCII range of 32 to 127, and especially for digits
> and letters, it would be well-defined.
Sadly, not all character sets agree 100% within that range, even if you
ignore the oddballs like EBCDIC where you expect problems. Various ISO
character sets (and most of them still in common use) replace some of
punctuation characters--and not even the same ones from set to set!
Above 127, of course, it's a complete free-for-all.
> BTW those 'A'..'Z' ranges are part of working code and they work
> properly. But it need not be just because it assumes ASCII. If my
> translator generated 'A' constants instead of 65, then the same C
> output would compile in an EBCDIC system with the same 'A'..Z' range
> in the input source, and work correctly!
The problem is that, in C, 'A'..'Z' may include things that are _not_
upper case letters if the character set in use isn't one of the ASCII
compatible ones, e.g. EBCDIC. That's why we can't have nice things.
For numeric ranges, the justification is a lot weaker, but since C
doesn't see a real difference between integers and characters, if we
have a problem with characters, we also have a problem with integers, so
again, we can't have nice things.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-05-14 00:48 -0500 |
| Message-ID | <qbd8la1pigoj5jfdpgfjnkl166sg42t6qs@4ax.com> |
| In reply to | #61964 |
On Wed, 13 May 2015 21:05:08 -0500, Stephen Sprunk
<stephen@sprunk.org> wrote:
>On 13-May-15 19:31, Bartc wrote:
>> On 14/05/2015 00:54, Robert Wessel wrote:
>>> gazelle@shell.xmission.com (Kenny McCormack) wrote:
>>>> case 'A'..'F': puts("Valid grade!");
>>>>
>>>> I'm pretty sure other languages support this - I think Pascal
>>>> does.
>>>
>>> We *could* have that in C, but what it would mean, when using
>>> character constants, would be quite implementation defined.
>>
>> Why? Within the ASCII range of 32 to 127, and especially for digits
>> and letters, it would be well-defined.
>
>Sadly, not all character sets agree 100% within that range, even if you
>ignore the oddballs like EBCDIC where you expect problems. Various ISO
>character sets (and most of them still in common use) replace some of
>punctuation characters--and not even the same ones from set to set!
>
>Above 127, of course, it's a complete free-for-all.
>
>> BTW those 'A'..'Z' ranges are part of working code and they work
>> properly. But it need not be just because it assumes ASCII. If my
>> translator generated 'A' constants instead of 65, then the same C
>> output would compile in an EBCDIC system with the same 'A'..Z' range
>> in the input source, and work correctly!
>
>The problem is that, in C, 'A'..'Z' may include things that are _not_
>upper case letters if the character set in use isn't one of the ASCII
>compatible ones, e.g. EBCDIC. That's why we can't have nice things.
I think BartC is suggesting that case 'H'..'K' generate (the
equivalent of):
case 'H':
case 'I':
case 'J':
case 'K':
or the numeric equivalents, and *not*, for EBCDIC, the equivalent of:
case: 0xc8:
case: 0xc9:
case: 0xca:
case: 0xcb:
case: 0xcc:
case: 0xcd:
case: 0xce:
case: 0xcf:
case: 0xd0:
case: 0xd1:
case: 0xd2:
Of course defining that behavior for the language presents an
interesting challenge. The behavior is fairly obvious so long as the
range is entirely within *one* of the sets of digits, uppercase
characters, or lowercase characters. That would also have some
interesting implications for the syntax of a case label.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-05-14 17:27 +0000 |
| Message-ID | <mj2ltl$f80$1@speranza.aioe.org> |
| In reply to | #61970 |
Robert Wessel <robertwessel2@yahoo.com> wrote: (snip, someone wrote) >>The problem is that, in C, 'A'..'Z' may include things that are _not_ >>upper case letters if the character set in use isn't one of the ASCII >>compatible ones, e.g. EBCDIC. That's why we can't have nice things. > I think BartC is suggesting that case 'H'..'K' generate (the > equivalent of): > case 'H': > case 'I': > case 'J': > case 'K': (snip) > Of course defining that behavior for the language presents an > interesting challenge. The behavior is fairly obvious so long as the > range is entirely within *one* of the sets of digits, uppercase > characters, or lowercase characters. That would also have some > interesting implications for the syntax of a case label. regexp compilers know how to do it. It would also be interesting to allow: case upper(x): (Yes I know that C doesn't allow non-constant expressions in case, but verilog does. But there is probably another way to add it to C.) -- glen
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-05-16 02:00 -0500 |
| Message-ID | <5nqdlat0k0p9fhf01hbq42e1hopsodkd4n@4ax.com> |
| In reply to | #62006 |
On Thu, 14 May 2015 17:27:18 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >Robert Wessel <robertwessel2@yahoo.com> wrote: > >(snip, someone wrote) >>>The problem is that, in C, 'A'..'Z' may include things that are _not_ >>>upper case letters if the character set in use isn't one of the ASCII >>>compatible ones, e.g. EBCDIC. That's why we can't have nice things. > >> I think BartC is suggesting that case 'H'..'K' generate (the >> equivalent of): > >> case 'H': >> case 'I': >> case 'J': >> case 'K': > >(snip) > >> Of course defining that behavior for the language presents an >> interesting challenge. The behavior is fairly obvious so long as the >> range is entirely within *one* of the sets of digits, uppercase >> characters, or lowercase characters. That would also have some >> interesting implications for the syntax of a case label. > >regexp compilers know how to do it. It would also be interesting >to allow: > >case upper(x): > >(Yes I know that C doesn't allow non-constant expressions in case, >but verilog does. But there is probably another way to add it >to C.) A more sophisticated selection statement, akin to Cobol "evaluate", is possible.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-14 09:41 +0100 |
| Message-ID | <mj1n23$24o$1@dont-email.me> |
| In reply to | #61964 |
On 14/05/2015 03:05, Stephen Sprunk wrote: > On 13-May-15 19:31, Bartc wrote: >> BTW those 'A'..'Z' ranges are part of working code and they work >> properly. But it need not be just because it assumes ASCII. If my >> translator generated 'A' constants instead of 65, then the same C >> output would compile in an EBCDIC system with the same 'A'..Z' range >> in the input source, and work correctly! > > The problem is that, in C, 'A'..'Z' may include things that are _not_ > upper case letters if the character set in use isn't one of the ASCII > compatible ones, e.g. EBCDIC. That's why we can't have nice things. Strange then that when a programmer thinks "A to Z", they then proceed to write out: 'A','B','C','D','E','F','G','H','I','J','K','L','M', 'N','O','P','Q','R','S','T','U','V','W','X','Y','Z' without any non-upper-case letters polluting the sequence. So,at least for someone thinking in English (and you might notice C has English keywords and many English-based function names), it's not because A to Z has an implicit ASCII coding, it's because it's a natural sequence. Since computers are supposed to stop us wasting time writing out stuff such as the above (which was actually machine-generated), why is it that C requires people to do things the long way? All it needs is a rule that when two character constants are separated by a symbol such "..", then an alphabetical sequence is generated: all intervening values are generated without non-alphabeticals: case 'H'..'O': becomes: case 'H','I','J','K','L','M','N','O': (making use of another trivial enhancement where you don't need to repeat 'case'). > For numeric ranges, the justification is a lot weaker When it's been discussed in this group before, the 'A'..'Z' argument is always trotted out. I agree it would cause problems if people were to write: c>='A' && c<='Z', but that's another matter. That would break under EBCDIC but that's what warnings are for. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-05-14 05:02 -0500 |
| Message-ID | <gcs8la1e0ib00pooveg82av8q10sc6a2v6@4ax.com> |
| In reply to | #61977 |
On Thu, 14 May 2015 09:41:41 +0100, Bartc <bc@freeuk.com> wrote: >On 14/05/2015 03:05, Stephen Sprunk wrote: >> On 13-May-15 19:31, Bartc wrote: > >>> BTW those 'A'..'Z' ranges are part of working code and they work >>> properly. But it need not be just because it assumes ASCII. If my >>> translator generated 'A' constants instead of 65, then the same C >>> output would compile in an EBCDIC system with the same 'A'..Z' range >>> in the input source, and work correctly! >> >> The problem is that, in C, 'A'..'Z' may include things that are _not_ >> upper case letters if the character set in use isn't one of the ASCII >> compatible ones, e.g. EBCDIC. That's why we can't have nice things. > >Strange then that when a programmer thinks "A to Z", they then proceed >to write out: > >'A','B','C','D','E','F','G','H','I','J','K','L','M', >'N','O','P','Q','R','S','T','U','V','W','X','Y','Z' > >without any non-upper-case letters polluting the sequence. So,at least >for someone thinking in English (and you might notice C has English >keywords and many English-based function names), it's not because A to Z >has an implicit ASCII coding, it's because it's a natural sequence. Those 26 aren't the only alphabetic characters. And given that you have to retrofit this into C, what forms are you going to allow? What should the following generate: case 1..9: case 'A'+2..'J'+2: case 'A'..'b': case '['..']': >Since computers are supposed to stop us wasting time writing out stuff >such as the above (which was actually machine-generated), why is it that >C requires people to do things the long way? > >All it needs is a rule that when two character constants are separated >by a symbol such "..", then an alphabetical sequence is generated: all >intervening values are generated without non-alphabeticals: > > case 'H'..'O': > >becomes: > > case 'H','I','J','K','L','M','N','O': > >(making use of another trivial enhancement where you don't need to >repeat 'case'). So what happens when someone specifies 'A'..'b'? >> For numeric ranges, the justification is a lot weaker > >When it's been discussed in this group before, the 'A'..'Z' argument is >always trotted out. > >I agree it would cause problems if people were to write: c>='A' && >c<='Z', but that's another matter. That would break under EBCDIC but >that's what warnings are for.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-14 13:44 +0100 |
| Message-ID | <mj2594$l82$1@dont-email.me> |
| In reply to | #61981 |
On 14/05/2015 11:02, Robert Wessel wrote: > On Thu, 14 May 2015 09:41:41 +0100, Bartc <bc@freeuk.com> wrote: >> Strange then that when a programmer thinks "A to Z", they then proceed >> to write out: >> >> 'A','B','C','D','E','F','G','H','I','J','K','L','M', >> 'N','O','P','Q','R','S','T','U','V','W','X','Y','Z' >> >> without any non-upper-case letters polluting the sequence. So,at least >> for someone thinking in English (and you might notice C has English >> keywords and many English-based function names), it's not because A to Z >> has an implicit ASCII coding, it's because it's a natural sequence. > > > Those 26 aren't the only alphabetic characters. The 26-letter A-Z range is special. While many languages (without even getting into other alphabets) can have extra letters, with a coding outside the ASCII range, and others have fewer letters (Italian used to get by with only 21 letters), the 26-letter A-Z (and a-z) range remains important enough to be given special treatment. (For example, they are the only letters that C allows in identifiers. In fact, on the first web page I looked at on the subject, it says that identifiers consist of a-z and A-Z (as well as 0-9 and underscore). It doesn't go into details as to what letters a-z or A-Z might include. Presumably it's obvious! Which is my point.) > And given that you > have to retrofit this into C, what forms are you going to allow? What > should the following generate: > > case 1..9: > case 'A'+2..'J'+2: > case 'A'..'b': > case '['..']': Doing it properly in a language, where you want to be able to assume that letters have a contiguous encoding, though your target might have an arbitrary one, is difficult. And that's when you have the freedom to do anything. With C, anything retrofitted is going to be clunky enough and ugly enough that no one would use it. The simplest is to just allow everything in your examples, but give a warning when the char encoding doesn't have contiguous letters in the special set. (What /can/ be retrofitted easily is to simply allow a list after 'case', so that if a range does have to be enumerated one by one, it is a bit less painful.) > case 1..9: This one is just the set 1,2,3,4,5,6,7,8,9 > case 'A'..'b': > case '['..']': These two are bad practice anyway. Suppose someone was to talk about, in any context including real life, the sequence from capital A to small b, what would it mean? So they would be ambiguous. > case 'A'+2..'J'+2: While expressions such as these are already allowed in C. They may or may not be the equivalent of 'C' and 'L'. But no-none is suggesting they oughtn't be allowed because they might give different results under EBCDIC. -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 5 of 22 — ← Prev page 1 … 3 4 [5] 6 7 … 22 Next page →
Back to top | Article view | comp.lang.c
csiph-web