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 17 of 22 — ← Prev page 1 … 15 16 [17] 18 19 … 22 Next page →
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-29 18:17 +0100 |
| Message-ID | <mka6t7$u1i$1@dont-email.me> |
| In reply to | #62794 |
On 29/05/2015 16:55, Richard Bos wrote: > Bartc <bc@freeuk.com> wrote: > >> On 29/05/2015 13:28, Richard Bos wrote: > >>> Once you start being creative with your desired additions to the >>> language, there is no end to the complications. >> >> Not really, if you know when to stop, and know what is suitable for the >> language. > > Yeah, and _if_ my aunt had as many bollocks as are talked in this > thread, she'd be my uncle. Well, some of us have implemented many of the possible features that have been discussed in the group, not just in the thread. So we have a good idea of what's easy, what's difficult, and what isn't appropriate. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-29 10:52 -0700 |
| Message-ID | <871thzl192.fsf@kst-u.example.com> |
| In reply to | #62787 |
Bartc <bc@freeuk.com> writes:
[...]
> (What /does/ suit C more is something like:
>
> int permutation;
>
> switch (permutation) {
> case 'ABC':
> case 'ACB':
> etc.
>
> Except that such char literals are probably badly defined, and with
> Unicode becoming popular, that introduces problems.)
'ABC' is already a valid character constant. It has type int and an
implementation-defined value. (With gcc on my system, its value is
('A'<< 16) + ('B' << 8) + 'C').
It's a feature that I've seen used incorrectly far more often than
it's been used correctly -- and it pretty much *can't* be used
correctly in portable code.
--
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 | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-26 13:27 -0500 |
| Message-ID | <mk2drp$9qi$1@dont-email.me> |
| In reply to | #62628 |
On 26-May-15 02:36, Morris Dovey wrote:
> On 5/25/15 3:48 PM, Stephen Sprunk wrote:
>> On 25-May-15 00:51, Morris Dovey wrote:
>>> On 5/24/15 7:26 PM, Stephen Sprunk wrote:
>>>> static inline int coll(char c) {
>>>> return strchr("0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ", c);
>>>> }
>>>> ...
>>>> switch (coll(c)) {
>>>> case coll('A')..coll('F'):
>>>> ...
>>>>
>>>> That requires two significant changes to C's switch syntax, but
>>>> it solves all of the objections I've seen in this thread so
>>>> far, and it wouldn't be difficult to implement at all.
>>>>
>>>> With some implementation-specific hackery, you could also tap
>>>> into the Standard Library's collation tables so that it
>>>> automatically adapted to the user's locale, and it'd only
>>>> require a tiny bit of work to handle UTF-8 strings as well.
>>>
>>> I'd prefer to allow user-specified character sets and collation
>>> orders for each switch statement. That would increase usefulness
>>> with not too much additional compiler design complexity.
>>
>> The two changes required to make the above example work are:
>>
>> 1. Allowing all compile-time constants for cases, not just
>> "integer constant expressions". C++ already has this.
>
> "All compile-time constants" could be pretty squirrely. How close do
> floating point values need to be to a range bound to be classified
> as 'in' the range?
Hmm; I was assuming integers, but if you wanted to add floating point as
well, which becomes a lot more useful with ranges, then I suppose you
could define it in terms of the relative comparison operators.
> What non-C languages support is irrelevant. If C++ already has what
> you need, then your problem is already solved and by insisting on a
> C solution, you’re rejecting the very solution you’re proposing. :-P
My point was that we have an example that is easily copied, just as C
has copied many other things from C++ (and vice versa, of course).
>> 2. Add support for numeric ranges. GCC already has this.
>
> Goody for gcc – but it’s just one C compiler package out of a whole
> pile of C compilers, and Gnu lacks imperial authority.
Again, my point was that we have an example that is easily copied, and
many "new" features in C started as compiler (often GCC) extensions.
>> Note that my example does _not_ require any character-specific
>> hackery in the language itself. It'd be nice if the Standard
>> Library provided a function to access collation ordinals (in
>> addition to strcoll() and wcscoll(), which only compare two
>> characters' ordinals), but that is completely optional.
>
> You’re wanting to do pointer comparisons and I still prefer integer
> comparisons. I’m probably not going to change my mind on this one
> without seeing compelling reasons.
Huh? My example was all integer comparisons.
> I think you’re missing an important point - that while the character
> set for program code can be nailed down for a language language,
> programmers can reasonably be expected to deal with textual data in
> a multitude of languages - in Canada, for example, with both English
> and French character sets and collating sequences - or in Greece
> with Greek, Latin, Turkish, Arabic, and Macedonian textual data. For
> those reasons I would argue that if we’re going to allow character
> ranges, the programmer should be able to specify the character set
> and associated collating sequence.
That's why my example had a caller-provided collating sequence and, as
an exercise for the reader, I suggested tapping into the existing
collation tables that are automatically selected by user locale.
> One of the reasons I picked Greek for my example, by the way, is
> that a range of 'A'..'Z' only includes the first six letters of the
> Greek alphabet.
Does it? I can't tell if that's U+0391 .. U+0396 or U+0041 .. U+005A.
> The sharp programmer will probably notice that the character set
> specified for a switch statement need only include those characters
> used in the range specifications, and that by so limiting the
> character set there are speed and memory advantages over hackish
> tricks with the locale. :-D
If you don't include the entire range explicitly, then you're back to
being dependent on the particular character encoding used by the
specific implementation you're running on, e.g. it works on ASCII
systems but breaks on EBCDIC ones.
>>> What I have NOT accounted for is nested switch statements - nor
>>> did I even try to deal with nested switch statements using
>>> different character sets and/or collating orders. I think I know
>>> what kind of code structure that might entail, but it's too
>>> late/early and I'm just not up to dealing with that tonight. :-)
>>
>> If that's truly necessary, then by leaning on the existing
>> collation functions, you could accommodate it by having each level
>> change locale, without any other changes to the language itself.
>> That'd be slow, but I suspect it's a rare enough use case to not
>> matter.
>
> It is truly necessary - the standard allows nested switch
> statements.
True, but that doesn't mean you _must_ allow different collation orders
at each level of nesting.
> There was an unanswered request for possible syntax suggestions. I
> meant to respond but got sidetracked. I can suggest
>
> switch (x) using ("ABCDEF")
> { case 'A'..'F':
> /* case code */
> case 'G':
> /* case code */
> default:
> /* case code */
> }
Do you really want to have to specify the collation sequence for every
switch, even though for the vast majority of code it'll be fixed, either
at compile time or by selecting a single locale at run-time?
Also, that syntax change makes this a very specific core language
feature; my example was designed to leverage two simpler, more general
language features that have _already_ been proposed numerous times and
have working examples in the wild.
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 | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-05-26 21:09 -0500 |
| Message-ID | <mk3901$3hb$1@speranza.aioe.org> |
| In reply to | #62656 |
On 5/26/15 1:27 PM, Stephen Sprunk wrote:
> On 26-May-15 02:36, Morris Dovey wrote:
>> On 5/25/15 3:48 PM, Stephen Sprunk wrote:
>>> The two changes required to make the above example work are:
>>>
>>> 1. Allowing all compile-time constants for cases, not just
>>> "integer constant expressions". C++ already has this.
>>
>> "All compile-time constants" could be pretty squirrely. How close do
>> floating point values need to be to a range bound to be classified
>> as 'in' the range?
>
> Hmm; I was assuming integers, but if you wanted to add floating point as
> well, which becomes a lot more useful with ranges, then I suppose you
> could define it in terms of the relative comparison operators.
'Scuse me, but I'm not the one wanting to add anything - I'm joining in
the discussion to explore the possibility that you might have a useful
idea. "All compile-time constants" seemed fairly unambiguous, so I took
it literally.
case 0.1-1E-10..sqrt(2.)+1E-12: /* Like this? */
>> What non-C languages support is irrelevant. If C++ already has what
>> you need, then your problem is already solved and by insisting on a
>> C solution, you’re rejecting the very solution you’re proposing. :-P
>
> My point was that we have an example that is easily copied, just as C
> has copied many other things from C++ (and vice versa, of course).
How interesting.
>>> 2. Add support for numeric ranges. GCC already has this.
>>
>> Goody for gcc – but it’s just one C compiler package out of a whole
>> pile of C compilers, and Gnu lacks imperial authority.
>
> Again, my point was that we have an example that is easily copied, and
> many "new" features in C started as compiler (often GCC) extensions.
Hmm. If I were in a contentious mood, I would invite your complete
enumeration of those that originated in the gcc compiler group... :-)
>>> Note that my example does _not_ require any character-specific
>>> hackery in the language itself. It'd be nice if the Standard
>>> Library provided a function to access collation ordinals (in
>>> addition to strcoll() and wcscoll(), which only compare two
>>> characters' ordinals), but that is completely optional.
>>
>> You’re wanting to do pointer comparisons and I still prefer integer
>> comparisons. I’m probably not going to change my mind on this one
>> without seeing compelling reasons.
>
> Huh? My example was all integer comparisons.
Err - yesterday you wrote "Why not just use strchr() as in my example?"
>> I think you’re missing an important point - that while the character
>> set for program code can be nailed down for a language language,
>> programmers can reasonably be expected to deal with textual data in
>> a multitude of languages - in Canada, for example, with both English
>> and French character sets and collating sequences - or in Greece
>> with Greek, Latin, Turkish, Arabic, and Macedonian textual data. For
>> those reasons I would argue that if we’re going to allow character
>> ranges, the programmer should be able to specify the character set
>> and associated collating sequence.
>
> That's why my example had a caller-provided collating sequence and, as
> an exercise for the reader, I suggested tapping into the existing
> collation tables that are automatically selected by user locale.
You did, and I'm still interested in how that would work in situations
where multiple locales would be needed.
>> One of the reasons I picked Greek for my example, by the way, is
>> that a range of 'A'..'Z' only includes the first six letters of the
>> Greek alphabet.
>
> Does it? I can't tell if that's U+0391 .. U+0396 or U+0041 .. U+005A.
You shouldn’t need to. "ΑΒΓΔΕΖ" should be sufficient.
>> The sharp programmer will probably notice that the character set
>> specified for a switch statement need only include those characters
>> used in the range specifications, and that by so limiting the
>> character set there are speed and memory advantages over hackish
>> tricks with the locale. :-D
>
> If you don't include the entire range explicitly, then you're back to
> being dependent on the particular character encoding used by the
> specific implementation you're running on, e.g. it works on ASCII
> systems but breaks on EBCDIC ones.
Switch statements are inherently data-dependent, and the programmer is
responsible for knowing those details.
Interestingly, one could build context strings for both ASCII and EBCDIC
and specify
switch (x)
{ case 'A'..'E' using (ascii_context_string):
/* case code */
break;
case 'A'..'E' using (ebcdic_context_string);
/* case code */
default:
/* case code */
}
to handle both encodings in the same switch.
>>>> What I have NOT accounted for is nested switch statements - nor
>>>> did I even try to deal with nested switch statements using
>>>> different character sets and/or collating orders. I think I know
>>>> what kind of code structure that might entail, but it's too
>>>> late/early and I'm just not up to dealing with that tonight. :-)
>>>
>>> If that's truly necessary, then by leaning on the existing
>>> collation functions, you could accommodate it by having each level
>>> change locale, without any other changes to the language itself.
>>> That'd be slow, but I suspect it's a rare enough use case to not
>>> matter.
>>
>> It is truly necessary - the standard allows nested switch
>> statements.
>
> True, but that doesn't mean you _must_ allow different collation orders
> at each level of nesting.
That's true - but if we're going to consider adding a feature to the
language, let's aim to add as much power as possible at the lowest
possible cost. At present C doesn't support ranges at all, and if we're
to consider adding them to the standard a larger benefit probably means
a higher probability of adoption.
>> There was an unanswered request for possible syntax suggestions. I
>> meant to respond but got sidetracked. I can suggest
>>
>> switch (x) using ("ABCDEF")
>> { case 'A'..'F':
>> /* case code */
>> case 'G':
>> /* case code */
>> default:
>> /* case code */
>> }
Quoting my "rethink":
>> After sleeping on that, I like better:
>>
>> switch (x)
>> { case 'A'..'F' using ("ABCDEF"):
>> /* case code */
>> case 'G':
>> /* case code */
>> default:
>> /* case code */
>> }
Which would allow (but not require) specification of a different
collation sequence for each range case.
> Do you really want to have to specify the collation sequence for every
> switch, even though for the vast majority of code it'll be fixed, either
> at compile time or by selecting a single locale at run-time?
Nope. The only time an explicit collation sequence specification should
be needed is when the programmer wants to use other than that which is
the default at compilation time, and then only for character range cases.
> Also, that syntax change makes this a very specific core language
> feature; my example was designed to leverage two simpler, more general
> language features that have _already_ been proposed numerous times and
> have working examples in the wild.
Range cases may indeed have been proposed numerous times – which means
that they've been deemed to offer insufficient benefit all those
numerous times.
Paraphrasing: The definition of "insanity" may be proposing the same
change repeatedly, each time expecting a different response, while
always getting the same response.
--
Morris Dovey
http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-27 00:03 -0500 |
| Message-ID | <mk3j4c$5jn$1@dont-email.me> |
| In reply to | #62665 |
On 26-May-15 21:09, Morris Dovey wrote: > On 5/26/15 1:27 PM, Stephen Sprunk wrote: >> On 26-May-15 02:36, Morris Dovey wrote: >>> "All compile-time constants" could be pretty squirrely. How close >>> do floating point values need to be to a range bound to be >>> classified as 'in' the range? >> >> Hmm; I was assuming integers, but if you wanted to add floating >> point as well, which becomes a lot more useful with ranges, then I >> suppose you could define it in terms of the relative comparison >> operators. > > 'Scuse me, but I'm not the one wanting to add anything - I'm joining > in the discussion to explore the possibility that you might have a > useful idea. "All compile-time constants" seemed fairly unambiguous, > so I took it literally. > > case 0.1-1E-10..sqrt(2.)+1E-12: /* Like this? */ I just realized that makes jump tables impossible, so that probably isn't a good idea; I'd keep it limited to integers. Good question. >>>> Note that my example does _not_ require any character-specific >>>> hackery in the language itself. It'd be nice if the Standard >>>> Library provided a function to access collation ordinals (in >>>> addition to strcoll() and wcscoll(), which only compare two >>>> characters' ordinals), but that is completely optional. >>> >>> You’re wanting to do pointer comparisons and I still prefer >>> integer comparisons. I’m probably not going to change my mind on >>> this one without seeing compelling reasons. >> >> Huh? My example was all integer comparisons. > > Err - yesterday you wrote "Why not just use strchr() as in my > example?" My example used strchr() to find the collation ordinal of a given character, and then compared those; it never compared pointers. >> That's why my example had a caller-provided collating sequence and, >> as an exercise for the reader, I suggested tapping into the >> existing collation tables that are automatically selected by user >> locale. > > You did, and I'm still interested in how that would work in > situations where multiple locales would be needed. The only way I can see the latter working is to require changing locales for each level of nesting. As I said, that'd be slow, but it should also be rare. >>> One of the reasons I picked Greek for my example, by the way, is >>> that a range of 'A'..'Z' only includes the first six letters of >>> the Greek alphabet. >> >> Does it? I can't tell if that's U+0391 .. U+0396 or U+0041 .. >> U+005A. > > You shouldn’t need to. "ΑΒΓΔΕΖ" should be sufficient. Then we're back to specifying the entire collation sequence rather than just a range. And once you step outside the basic ASCII set, those collation sequences can be _massive_, and the average programmer is almost certain to get them wrong, which is why I suggested using the library's set, since it already has to have those for its own collation functions. >> Do you really want to have to specify the collation sequence for >> every switch, even though for the vast majority of code it'll be >> fixed, either at compile time or by selecting a single locale at >> run-time? > > Nope. The only time an explicit collation sequence specification > should be needed is when the programmer wants to use other than that > which is the default at compilation time, and then only for character > range cases. What is default at compilation time is almost certainly incorrect, at least for any program with even halfway decent localization. >> Also, that syntax change makes this a very specific core language >> feature; my example was designed to leverage two simpler, more >> general language features that have _already_ been proposed >> numerous times and have working examples in the wild. > > Range cases may indeed have been proposed numerous times – which > means that they've been deemed to offer insufficient benefit all > those numerous times. > > Paraphrasing: The definition of "insanity" may be proposing the same > change repeatedly, each time expecting a different response, while > always getting the same response. Fair enough, or perhaps nobody so far has provided sufficient justification for their inclusion. I don't know the history, so I don't know exactly why past attempts failed. If I were submitting a formal proposal, I'd do the necessary research and find a better approach. 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-27 00:59 -0500 |
| Message-ID | <85nama57dbv3kc5467h4ns2t2tum8kdc0c@4ax.com> |
| In reply to | #62667 |
On Wed, 27 May 2015 00:03:14 -0500, Stephen Sprunk <stephen@sprunk.org> wrote: >On 26-May-15 21:09, Morris Dovey wrote: >> On 5/26/15 1:27 PM, Stephen Sprunk wrote: >>> On 26-May-15 02:36, Morris Dovey wrote: >>>> "All compile-time constants" could be pretty squirrely. How close >>>> do floating point values need to be to a range bound to be >>>> classified as 'in' the range? >>> >>> Hmm; I was assuming integers, but if you wanted to add floating >>> point as well, which becomes a lot more useful with ranges, then I >>> suppose you could define it in terms of the relative comparison >>> operators. >> >> 'Scuse me, but I'm not the one wanting to add anything - I'm joining >> in the discussion to explore the possibility that you might have a >> useful idea. "All compile-time constants" seemed fairly unambiguous, >> so I took it literally. >> >> case 0.1-1E-10..sqrt(2.)+1E-12: /* Like this? */ > >I just realized that makes jump tables impossible, so that probably >isn't a good idea; I'd keep it limited to integers. Good question. Only if you assume a 1970s compiler. If all the cases are integers, optimize as you do now. If not, then jump tables may not be applicable.
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-05-27 01:15 -0500 |
| Message-ID | <mk3nd3$uhi$1@speranza.aioe.org> |
| In reply to | #62667 |
On 5/27/15 12:03 AM, Stephen Sprunk wrote:
> On 26-May-15 21:09, Morris Dovey wrote:
>> On 5/26/15 1:27 PM, Stephen Sprunk wrote:
>>> On 26-May-15 02:36, Morris Dovey wrote:
>>>> "All compile-time constants" could be pretty squirrely. How close
>>>> do floating point values need to be to a range bound to be
>>>> classified as 'in' the range?
>>>
>>> Hmm; I was assuming integers, but if you wanted to add floating
>>> point as well, which becomes a lot more useful with ranges, then I
>>> suppose you could define it in terms of the relative comparison
>>> operators.
>>
>> 'Scuse me, but I'm not the one wanting to add anything - I'm joining
>> in the discussion to explore the possibility that you might have a
>> useful idea. "All compile-time constants" seemed fairly unambiguous,
>> so I took it literally.
>>
>> case 0.1-1E-10..sqrt(2.)+1E-12: /* Like this? */
>
> I just realized that makes jump tables impossible, so that probably
> isn't a good idea; I'd keep it limited to integers. Good question.
Thanks. I'm not sure that it wouldn't be useful, but am sure that FP
could offer some challenges. It might look 'friendlier' if I wrote
case 0.1-EPSILON..sqrt(2)+EPSILON:
or it might even be possible for the compiler to automagically provide a
target-dependent EPSILON so we could get away with writing
case 0.1..sqrt(2):
but that would take more analysis than I want to do tonight.
>>>>> Note that my example does _not_ require any character-specific
>>>>> hackery in the language itself. It'd be nice if the Standard
>>>>> Library provided a function to access collation ordinals (in
>>>>> addition to strcoll() and wcscoll(), which only compare two
>>>>> characters' ordinals), but that is completely optional.
>>>>
>>>> You’re wanting to do pointer comparisons and I still prefer
>>>> integer comparisons. I’m probably not going to change my mind on
>>>> this one without seeing compelling reasons.
>>>
>>> Huh? My example was all integer comparisons.
>>
>> Err - yesterday you wrote "Why not just use strchr() as in my
>> example?"
>
> My example used strchr() to find the collation ordinal of a given
> character, and then compared those; it never compared pointers.
Yabbut what you get from strchr() is a pointer (to char)...
>>> That's why my example had a caller-provided collating sequence and,
>>> as an exercise for the reader, I suggested tapping into the
>>> existing collation tables that are automatically selected by user
>>> locale.
>>
>> You did, and I'm still interested in how that would work in
>> situations where multiple locales would be needed.
>
> The only way I can see the latter working is to require changing locales
> for each level of nesting. As I said, that'd be slow, but it should
> also be rare.
>
>>>> One of the reasons I picked Greek for my example, by the way, is
>>>> that a range of 'A'..'Z' only includes the first six letters of
>>>> the Greek alphabet.
>>>
>>> Does it? I can't tell if that's U+0391 .. U+0396 or U+0041 ..
>>> U+005A.
>>
>> You shouldn’t need to. "ΑΒΓΔΕΖ" should be sufficient.
>
> Then we're back to specifying the entire collation sequence rather than
> just a range.
No - only enough of the sequence to determine whether the switch value
is within the specified sequence! Consider:
switch (x)
{ case 'A'..'Y' using ("AEIOUY"):
/* case code for processing a vowel */
break;
/* other cases */
}
> And once you step outside the basic ASCII set, those collation sequences
> can be _massive_, and the average programmer is almost certain to get
> them wrong, which is why I suggested using the library's set, since it
> already has to have those for its own collation functions.
>
>>> Do you really want to have to specify the collation sequence for
>>> every switch, even though for the vast majority of code it'll be
>>> fixed, either at compile time or by selecting a single locale at
>>> run-time?
>>
>> Nope. The only time an explicit collation sequence specification
>> should be needed is when the programmer wants to use other than that
>> which is the default at compilation time, and then only for character
>> range cases.
>
> What is default at compilation time is almost certainly incorrect, at
> least for any program with even halfway decent localization.
Yes. Add this to the list of issues to be resolved prior to making a
proposal to the standards committee.
>>> Also, that syntax change makes this a very specific core language
>>> feature; my example was designed to leverage two simpler, more
>>> general language features that have _already_ been proposed
>>> numerous times and have working examples in the wild.
>>
>> Range cases may indeed have been proposed numerous times – which
>> means that they've been deemed to offer insufficient benefit all
>> those numerous times.
>>
>> Paraphrasing: The definition of "insanity" may be proposing the same
>> change repeatedly, each time expecting a different response, while
>> always getting the same response.
>
> Fair enough, or perhaps nobody so far has provided sufficient
> justification for their inclusion. I don't know the history, so I don't
> know exactly why past attempts failed. If I were submitting a formal
> proposal, I'd do the necessary research and find a better approach.
First class! An excellent plan. :-)
--
Morris Dovey
http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-27 13:34 -0400 |
| Message-ID | <55660041.9010909@verizon.net> |
| In reply to | #62669 |
On 05/27/2015 02:15 AM, Morris Dovey wrote:
...
> Thanks. I'm not sure that it wouldn't be useful, but am sure that FP
> could offer some challenges. It might look 'friendlier' if I wrote
>
> case 0.1-EPSILON..sqrt(2)+EPSILON:
>
> or it might even be possible for the compiler to automagically provide a
> target-dependent EPSILON so we could get away with writing
Were such a change made to the language, the following code would more
accurately reflect what I would want to do:
case nextafter(0.1,0.0)..nextafter(sqrt(2.0), 2.0):
In the more general case, I would use either -DBL_MAX or DBL_MAX as the
second argument to the nexafter() calls.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-27 14:07 -0500 |
| Message-ID | <mk54ja$rss$1@dont-email.me> |
| In reply to | #62669 |
On 27-May-15 01:15, Morris Dovey wrote:
> On 5/27/15 12:03 AM, Stephen Sprunk wrote:
>> On 26-May-15 21:09, Morris Dovey wrote:
>>>> Huh? My example was all integer comparisons.
>>>
>>> Err - yesterday you wrote "Why not just use strchr() as in my
>>> example?"
>>
>> My example used strchr() to find the collation ordinal of a given
>> character, and then compared those; it never compared pointers.
>
> Yabbut what you get from strchr() is a pointer (to char)...
D'oh! That's what I get for not testing my code. Notice that I had
"return strchr(...);" in a function returning int.
That should have been:
static const char seq[] = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
return strchr(seq, c) - seq;
It's still lacking any error-handling code; that's left as an exercise
for the reader, as is making the sequence caller-supplied.
>>>>> One of the reasons I picked Greek for my example, by the way,
>>>>> is that a range of 'A'..'Z' only includes the first six
>>>>> letters of the Greek alphabet.
>>>>
>>>> Does it? I can't tell if that's U+0391 .. U+0396 or U+0041 ..
>>>> U+005A.
>>>
>>> You shouldn’t need to. "ΑΒΓΔΕΖ" should be sufficient.
>>
>> Then we're back to specifying the entire collation sequence rather
>> than just a range.
>
> No - only enough of the sequence to determine whether the switch
> value is within the specified sequence! Consider:
>
> switch (x)
> { case 'A'..'Y' using ("AEIOUY"):
That's still the entire collation sequence, just a rather short one.
> /* case code for processing a vowel */
> break;
> /* other cases */
> }
I still don't see why you want your "using" clause on every case, which
obviously opens up the opportunity of having multiple cases match,
rather than putting it on the switch.
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-05-27 19:53 +0000 |
| Message-ID | <mk57b6$moc$1@speranza.aioe.org> |
| In reply to | #62692 |
Stephen Sprunk <stephen@sprunk.org> wrote: (snip) > D'oh! That's what I get for not testing my code. Notice that I had > "return strchr(...);" in a function returning int. > That should have been: > static const char seq[] = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"; > return strchr(seq, c) - seq; Reminds me of my first program using strstr. Being used to PL/I, where INDEX return an integer, I had: j=strstr(s,t)-s; then later, when I needed to test it: if(j==NULL-s) ... > It's still lacking any error-handling code; that's left as an exercise > for the reader, as is making the sequence caller-supplied. especially when strchr() returns null. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-05-27 21:21 +0100 |
| Message-ID | <87twuxojpo.fsf@bsb.me.uk> |
| In reply to | #62692 |
Stephen Sprunk <stephen@sprunk.org> writes:
> On 27-May-15 01:15, Morris Dovey wrote:
>> On 5/27/15 12:03 AM, Stephen Sprunk wrote:
<snip>
>>> My example used strchr() to find the collation ordinal of a given
>>> character, and then compared those;
<snip>
> static const char seq[] = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
> return strchr(seq, c) - seq;
>
> It's still lacking any error-handling code; that's left as an exercise
> for the reader, as is making the sequence caller-supplied.
You might consider using
strcspn(seq, (char []){c, 0})
for that. You get some kind of error handling free, in that all
characters not in the collating sequence are given the same high (yet
valid) index.
The strspn and strcspn functions are much overlooked. For example,
membership of the can be detected with
strspn((char []){c, 0}, seq)
This might be what's needed for some of these switch examples (sorry,
I've lost tack of the actual point of the discussion!).
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2015-05-27 21:45 -0700 |
| Message-ID | <d427ed23-bfe1-4128-98d7-958ab62d7e19@googlegroups.com> |
| In reply to | #62696 |
On Wednesday, May 27, 2015 at 3:21:15 PM UTC-5, Ben Bacarisse wrote:
> Stephen Sprunk <stephen@sprunk.org> writes:
>
> > On 27-May-15 01:15, Morris Dovey wrote:
> >> On 5/27/15 12:03 AM, Stephen Sprunk wrote:
> <snip>
> >>> My example used strchr() to find the collation ordinal of a given
> >>> character, and then compared those;
> <snip>
> > static const char seq[] = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
> > return strchr(seq, c) - seq;
> >
> > It's still lacking any error-handling code; that's left as an exercise
> > for the reader, as is making the sequence caller-supplied.
>
> You might consider using
>
> strcspn(seq, (char []){c, 0})
>
> for that. You get some kind of error handling free, in that all
> characters not in the collating sequence are given the same high (yet
> valid) index.
>
> The strspn and strcspn functions are much overlooked. For example,
> membership of the can be detected with
>
> strspn((char []){c, 0}, seq)
>
> This might be what's needed for some of these switch examples (sorry,
> I've lost tack of the actual point of the discussion!).
>
> <snip>
That is awesome! I love you, dude!
--
+500 bounty
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-28 17:36 -0500 |
| Message-ID | <mk857v$aus$1@dont-email.me> |
| In reply to | #62696 |
On 27-May-15 15:21, Ben Bacarisse wrote:
> Stephen Sprunk <stephen@sprunk.org> writes:
>> static const char seq[] = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
>> return strchr(seq, c) - seq;
>>
>> It's still lacking any error-handling code; that's left as an exercise
>> for the reader, as is making the sequence caller-supplied.
>
> You might consider using
>
> strcspn(seq, (char []){c, 0})
>
> for that. You get some kind of error handling free, in that all
> characters not in the collating sequence are given the same high (yet
> valid) index.
>
> The strspn and strcspn functions are much overlooked.
Indeed; I don't think I've ever used either, probably because when I
first (last?) encountered them, no uses came to mind, so your example is
quite helpful.
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-27 10:36 -0400 |
| Message-ID | <mk4ko2$oe1$1@dont-email.me> |
| In reply to | #62667 |
On 05/27/2015 01:03 AM, Stephen Sprunk wrote: > On 26-May-15 21:09, Morris Dovey wrote: >> On 5/26/15 1:27 PM, Stephen Sprunk wrote: >>> On 26-May-15 02:36, Morris Dovey wrote: >>>> "All compile-time constants" could be pretty squirrely. How close >>>> do floating point values need to be to a range bound to be >>>> classified as 'in' the range? >>> >>> Hmm; I was assuming integers, but if you wanted to add floating >>> point as well, which becomes a lot more useful with ranges, then I >>> suppose you could define it in terms of the relative comparison >>> operators. >> >> 'Scuse me, but I'm not the one wanting to add anything - I'm joining >> in the discussion to explore the possibility that you might have a >> useful idea. "All compile-time constants" seemed fairly unambiguous, >> so I took it literally. >> >> case 0.1-1E-10..sqrt(2.)+1E-12: /* Like this? */ > > I just realized that makes jump tables impossible, so that probably > isn't a good idea; I'd keep it limited to integers. Good question. Any decent compiler should decide whether or not to use a jump table only after considering the values of the corresponding case labels, to determine whether it's a reasonable strategy. This change would only add additional cases where jump tables are not reasonable; it doesn't prevent the use of jump tables when they are reasonable. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-05-27 16:54 +0200 |
| Message-ID | <mk4los$sl6$1@dont-email.me> |
| In reply to | #62672 |
On 27/05/15 16:36, James Kuyper wrote: > On 05/27/2015 01:03 AM, Stephen Sprunk wrote: >> On 26-May-15 21:09, Morris Dovey wrote: >>> On 5/26/15 1:27 PM, Stephen Sprunk wrote: >>>> On 26-May-15 02:36, Morris Dovey wrote: >>>>> "All compile-time constants" could be pretty squirrely. How close >>>>> do floating point values need to be to a range bound to be >>>>> classified as 'in' the range? >>>> >>>> Hmm; I was assuming integers, but if you wanted to add floating >>>> point as well, which becomes a lot more useful with ranges, then I >>>> suppose you could define it in terms of the relative comparison >>>> operators. >>> >>> 'Scuse me, but I'm not the one wanting to add anything - I'm joining >>> in the discussion to explore the possibility that you might have a >>> useful idea. "All compile-time constants" seemed fairly unambiguous, >>> so I took it literally. >>> >>> case 0.1-1E-10..sqrt(2.)+1E-12: /* Like this? */ >> >> I just realized that makes jump tables impossible, so that probably >> isn't a good idea; I'd keep it limited to integers. Good question. > > Any decent compiler should decide whether or not to use a jump table > only after considering the values of the corresponding case labels, to > determine whether it's a reasonable strategy. This change would only add > additional cases where jump tables are not reasonable; it doesn't > prevent the use of jump tables when they are reasonable. > Indeed - no (decent!) compiler will generate a jump table for switch labels 1000000, 2000000, 3000000, which are perfectly legal to use in current C. I might object to allowing floating point constants as cases unless you are using ranges, because it is generally a bad idea to test floating point values for equality.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-27 16:08 +0100 |
| Message-ID | <mk4mij$vpm$1@dont-email.me> |
| In reply to | #62673 |
On 27/05/2015 15:54, David Brown wrote: > I might object to allowing floating point constants as cases unless you > are using ranges, because it is generally a bad idea to test floating > point values for equality. If == is allowed between floating point values, there you can't really object to comparing floats anywhere else. The switch might simply be used as a more organised way of doing lots of ifs and else-ifs. (And there are a huge number of values for which floating point equality can be tested without problem, including all the 4 billion values of a 32-bit int.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-05-27 12:18 -0500 |
| Message-ID | <mk4tqh$sqj$1@dont-email.me> |
| In reply to | #62674 |
Bartc wrote: > On 27/05/2015 15:54, David Brown wrote: > >> I might object to allowing floating point constants as cases unless you >> are using ranges, because it is generally a bad idea to test floating >> point values for equality. > > If == is allowed between floating point values, there you can't really > object to comparing floats anywhere else. > There is a long list of caveats in just comparing floating point numbers. > The switch might simply be used as a more organised way of doing lots of > ifs and else-ifs. > Not so much. A switch is a (sparse) "array of code blocks". > (And there are a huge number of values for which floating point equality > can be tested without problem, including all the 4 billion values of a > 32-bit int.) > That is so implementation dependent than if I were part of the governance for the language, I'd suggest avoiding it. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-27 18:39 +0100 |
| Message-ID | <mk4ve0$5ci$1@dont-email.me> |
| In reply to | #62681 |
On 27/05/2015 18:18, Les Cargill wrote: > Bartc wrote: >> (And there are a huge number of values for which floating point equality >> can be tested without problem, including all the 4 billion values of a >> 32-bit int.) >> > > That is so implementation dependent than if I were part of > the governance for the language, I'd suggest avoiding it. Which implementations would return false for 1.0 == 1? (or 1.0 == 1.0?) How about this: double a,b=1.0; a = b; Are there any implementations where a == b is false? (Assume b contains a valid value.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-05-27 22:04 +0200 |
| Message-ID | <mk57tv$arq$1@dont-email.me> |
| In reply to | #62684 |
On 27/05/15 19:39, Bartc wrote: > On 27/05/2015 18:18, Les Cargill wrote: >> Bartc wrote: > >>> (And there are a huge number of values for which floating point equality >>> can be tested without problem, including all the 4 billion values of a >>> 32-bit int.) >>> >> >> That is so implementation dependent than if I were part of >> the governance for the language, I'd suggest avoiding it. > > Which implementations would return false for 1.0 == 1? (or 1.0 == 1.0?) > > How about this: > > double a,b=1.0; > > a = b; > > Are there any implementations where a == b is false? (Assume b contains > a valid value.) > I believe it is perfectly possible for the comparison to be false (perhaps not with 1.0, since that has a nice easy representation in IEEE formats). In particular, compilers on x86 systems might use 80-bit registers to store values temporarily, even if they are 32-bit or 64-bit in memory - and equality comparisons may fail. It is also possible, I think, for some types of NaN (which may count as "valid value", depending on your definitions) to always fail comparisons. In such cases, neither "a == b" nor "a != b" will be true. I cannot say for sure what the standards allow, and I haven't seen such problems personally, but I have heard enough war stories from real code to know that one should never compare floating point values for equality.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-27 21:38 +0100 |
| Message-ID | <mk59t7$j01$1@dont-email.me> |
| In reply to | #62695 |
On 27/05/2015 21:04, David Brown wrote: > On 27/05/15 19:39, Bartc wrote: >> On 27/05/2015 18:18, Les Cargill wrote: >>> Bartc wrote: >> Which implementations would return false for 1.0 == 1? (or 1.0 == 1.0?) > I believe it is perfectly possible for the comparison to be false > (perhaps not with 1.0, since that has a nice easy representation in IEEE > formats). In particular, compilers on x86 systems might use 80-bit > registers to store values temporarily, even if they are 32-bit or 64-bit > in memory - and equality comparisons may fail. > > It is also possible, I think, for some types of NaN (which may count as > "valid value", depending on your definitions) to always fail > comparisons. In such cases, neither "a == b" nor "a != b" will be true. What about a <= b, a < b, a > b or a >= b when either operand is a NaN? > I cannot say for sure what the standards allow, and I haven't seen such > problems personally, but I have heard enough war stories from real code > to know that one should never compare floating point values for equality. From badly designed code no doubt. It should be fine if you know what you're doing. But since the language doesn't actually ban testing for floating point equality, I can't see that being a reason for not allowing it anywhere else. (Looking at my own code, there are plenty of comparisons against 0.0, most likely of values which might have been specifically set to zero rather than the approximate result of a calculation, when some tolerance would need be taken into account.) -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 17 of 22 — ← Prev page 1 … 15 16 [17] 18 19 … 22 Next page →
Back to top | Article view | comp.lang.c
csiph-web