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 14 of 22 — ← Prev page 1 … 12 13 [14] 15 16 … 22 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-08-25 08:16 +1200 |
| Message-ID | <d41cceFmnsqU2@mid.individual.net> |
| In reply to | #68248 |
Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> I'm also suggesting these changes went a long way to >> preventing C99 gaining wide acceptance. > > Really? You think <tgmath.h>, and other math functions, account > for the slow uptake of C99? I see no reason to think that's > true in the absence of any sort of corroborating evidence. The reluctance of embedded tool chain developers to support a standard that offered little to their users was pretty clear. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-08-03 14:11 +0100 |
| Message-ID | <mpnp7c$ci1$1@dont-email.me> |
| In reply to | #66651 |
On 01/08/15 21:21, Ian Collins wrote: <snip> > I would be interested to see the results of a poll of C programmers asking > > "what would you rather have in C, binary literals or <tgmath.h>?" Neither, please. :-) -- 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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-08-04 10:56 +0000 |
| Message-ID | <55c09a26.6667640@news.xs4all.nl> |
| In reply to | #66651 |
Ian Collins <ian-news@hotmail.com> wrote: > I would be interested to see the results of a poll of C programmers asking > > "what would you rather have in C, binary literals or <tgmath.h>?" Binary literals _and_ i/o, hands down. I've never been unsure enough about my own types to want <tgmath.h>. Richard
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-01 16:52 -0700 |
| Message-ID | <c1d06b87-03af-4848-a26c-7191e4ab8dce@googlegroups.com> |
| In reply to | #66642 |
On Saturday, August 1, 2015 at 10:10:52 AM UTC-7, Tim Rentsch wrote: > I did download a .pdf that seems to be an 8086 datasheet, with > 30 pages, the last four of which look like instruction or opcode > listings. Those listings did use 0's and 1's (not really binary > constants as such, but close enough), for the opcode fields, with > lengths of eight bits or less. As I see it the 8086 instruction set, leaving out all the details. was clearly 5+3 bits. It was possible to substructure the 5 bits but not so clearly. But I guess Intel had it's own ideas.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-02 12:59 +0100 |
| Message-ID | <mpl0jv$89u$1@dont-email.me> |
| In reply to | #66642 |
On 01/08/2015 18:10, Tim Rentsch wrote:
> Bartc <bc@freeuk.com> writes:
>> (Google for something like '8086 datasheet' or for '80188 data
>> sheet' (actual links were too long to include), eg. the original
>> data sheets of 30 or so pages. Look at the instruction set
>> summaries starting on page 26 or 27. They are full of binary!
>
> I did download a .pdf that seems to be an 8086 datasheet, with
> 30 pages, the last four of which look like instruction or opcode
> listings. Those listings did use 0's and 1's (not really binary
> constants as such, but close enough), for the opcode fields, with
> lengths of eight bits or less.
>
> If I were writing a C program that needed to include these values,
> I expect I would write it something like this:
>
> enum I808_opcodes {
> I8086_AAS = B2( 00111111 ), /* ASCII Adjust for Subtract */
> I8086_DAS = B2( 00101111 ), /* Decimal Adjust for Subtract */
> /* ... etc ... */
> I8086_limit = B2( 11111111 )
> };
>
> where B2() is a macro for producing a constant expressed in
> binary. Writing this macro took about ten minutes. (The code
> shown above is actual code, compiling cleanly in C90 and C99 (and
> presumably C11, although I didn't test that).) IMO this is a
> better solution than using a new form of integer constant, both
> because it works now and because it works with older versions
> of C that don't support binary constants.
This is what constantly comes up whenever anyone proposes a nifty new
language feature or bit of new syntax: someone will always come up with
tacky-looking macro that half-does the job.
(For example, this probably doesn't deal with separators, that ought to
be part and parcel of a binary literal feature. x86 opcodes tend to be
grouped into 2:3:3 groups of bits.)
But no matter how well such a macro might work or how clever it is, the
biggest problem is that it is not part of the standard.
Imagine if you had to assemble source code from several different
sources, then you might have multiple different ways of denoting binary
literals, all with their corresponding macros that now have to be
dragged in too.
And if you wanted such a macro standardised, you now have the same
problems in getting the standards committee to devote time to it.
> Writing this macro took about ten minutes.
Multiply that thousands of different programmers all writing their own
macros, some of whom would take more than ten minutes, while others
would make mistakes. And then add the tens of thousands who will have to
read the code but might have to stop doing so, to look up what B2 might
happen to be when it's at home. (And if there is a problem with the
code, B2 would have to be one of the suspects, which would not happen
with built-in literals.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-09 13:39 -0700 |
| Message-ID | <kfn1tfc6vsu.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66684 |
Bartc <bc@freeuk.com> writes:
> On 01/08/2015 18:10, Tim Rentsch wrote:
>> Bartc <bc@freeuk.com> writes:
>>
>>> (Google for something like '8086 datasheet' or for '80188 data
>>> sheet' (actual links were too long to include), eg. the original
>>> data sheets of 30 or so pages. Look at the instruction set
>>> summaries starting on page 26 or 27. They are full of binary!
>>
>> I did download a .pdf that seems to be an 8086 datasheet, with
>> 30 pages, the last four of which look like instruction or opcode
>> listings. Those listings did use 0's and 1's (not really binary
>> constants as such, but close enough), for the opcode fields, with
>> lengths of eight bits or less.
>>
>> If I were writing a C program that needed to include these values,
>> I expect I would write it something like this:
>>
>> enum I808_opcodes {
>> I8086_AAS = B2( 00111111 ), /* ASCII Adjust for Subtract */
>> I8086_DAS = B2( 00101111 ), /* Decimal Adjust for Subtract */
>> /* ... etc ... */
>> I8086_limit = B2( 11111111 )
>> };
>>
>> where B2() is a macro for producing a constant expressed in
>> binary. Writing this macro took about ten minutes. (The code
>> shown above is actual code, compiling cleanly in C90 and C99 (and
>> presumably C11, although I didn't test that).) IMO this is a
>> better solution than using a new form of integer constant, both
>> because it works now and because it works with older versions
>> of C that don't support binary constants.
>
> This is what constantly comes up whenever anyone proposes a nifty
> new language feature or bit of new syntax: someone will always
> come up with tacky-looking macro that half-does the job.
The macro use shown here doesn't look tacky. The macros in
<stdint.h> for constants having a specified type look pretty much
the same, although their purpose is somewhat different. As for
the job, AFAIK the B2() macro handles all the contemplated uses
for binary constants. Furthermore a macro solution is available
now and also usable in C90, C99, and C11 - it doesn't have to
wait five to ten years before being usable, and then only in some
implementations.
> (For example, this probably doesn't deal with separators, that
> ought to be part and parcel of a binary literal feature. x86
> opcodes tend to be grouped into 2:3:3 groups of bits.)
A specious objection. C in its current form doesn't have
separators for numbers. If a future version of C provides
a numeric separator, they would also be allowed in arguments
to the B2() macro, which are just numbers. It has nothing
to do with whether C has binary constants or not.
> But no matter how well such a macro might work or how clever it
> is, the biggest problem is that it is not part of the standard.
That is a problem only if you think putting something into the
Standard is necessarily good. That idea is wrongheaded. In some
cases adding something to the Standard is worthwhile; in others
it isn't. Which of these two is the case is the very question we
are trying to resolve.
> Imagine if you had to assemble source code from several different
> sources, then you might have multiple different ways of denoting
> binary literals, all with their corresponding macros that now have
> to be dragged in too.
Presumably the macro definitions would be part of the various
other header files and come along as part and parcel of using
the other projects. No additional dragging in is needed.
> And if you wanted such a macro standardised, you now have the same
> problems in getting the standards committee to devote time to it.
I don't need this macro standardized. I don't want this macro
standardized. It is possible to imagine, in some hypothetical
future, that so many developers on so many projects found such
a macro useful that some form of it would be almost ubiquitous,
in which case it would be worth considering whether adding a
common form to the Standard would be worthwhile. If and when
that happens is the appropriate time to put in the effort to
do that. And even then the balance of different factors may
ultimately decide in favor of not changing the Standard.
>> Writing this macro took about ten minutes.
>
> Multiply that thousands of different programmers all writing their
> own macros, some of whom would take more than ten minutes, while
> others would make mistakes. And then add the tens of thousands
> who will have to read the code but might have to stop doing so, to
> look up what B2 might happen to be when it's at home. (And if
> there is a problem with the code, B2 would have to be one of the
> suspects, which would not happen with built-in literals.)
Well at least you are finally making a sort of an economic
argument. Unfortunately it shares an important problem with your
earlier arguments, viz., it is based purely on speculation and
not on any facts or objective evidence. The whole point of what
I've been saying is to try to be quantitative and objective.
The numbers you suggest here are unrealistic, for the obvious
reason that once one or two definitions have been seen, those
will be copied rather than created independently. Furthermore
the people paying the costs will be mostly the same people are
getting the benefits, which is qualitatively different from
what would happen if something were standardized. So let's
have some realistic estimates of the costs and benefits
involved in both cases, so that the alternatives can be
compared objectively rather than just based on speculation.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-02 13:37 +0200 |
| Message-ID | <mpkvb8$4aj$1@dont-email.me> |
| In reply to | #66391 |
(I've been on holiday for a week or so - my apologies if anything I write here covers points already raised by others, which I haven't yet read.) On 26/07/15 05:17, Tim Rentsch wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 10/07/15 19:19, Tim Rentsch wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> On 24/05/15 16:44, Tim Rentsch wrote: >>>> >>>>> I see no reason to make any of these changes. A binary base >>>>> isn't useful because the lengths involved make it hard to >>>>> see just what the value is (and is error prone to write). >>>> >>>> Binary constants of the format 0b0110 made it into C compilers and the >>>> C++ standards because they are very useful, >>> >>> C++ has made lots of decisions which are IMO bad ones. So I guess >>> I'm not surprised to see another one. >> >> That sounds as though you are saying that because binary constants >> were added to C++, they must be a bad idea (in your humble opinion, >> of course). > > I don't know why you would think that. It isn't what I said. > Certainly it is not what I meant. I can agree that you did not /write/ exactly that - but you /imply/ that you see C++'s introduction of 0b literals as a good reason to be sceptical to including them in C, simply because (in your eyes) C++ has record for introducing bad ideas. (Arguably the fact that C++ supports them makes them less necessary in C - people who really need binary constants can drop C and go to C++ instead.) > >> We have 0b00110 constants in C++ and as en extension on many C >> compilers precisely because it was useful to /users/. The history >> of implementation is easy to follow: >> >> avr-gcc developers added it because the users and the AVR gcc >> library developers wanted it. (The AVR is an 8-bit microcontroller, >> with a gcc port.). It got wider adoption into mainline gcc, and was >> copied by clang. The C++ standards committee were asked to include >> it for the benefit of embedded developers - they saw that it was >> already implemented in mainstream tools, it is useful and is used in >> practice, and causes no harm to include it. So they added it to >> their standards. >> >> A number of other embedded compilers also support it - either before >> or after its support in gcc. > > I understand that people wanted it, and some compilers put it in > because it's easy if all you have to think about is taking the > constants in program source. That isn't the same thing as saying > it's useful, or that the benefits are worth the cost. First, people wanted them because they /are/ useful to embedded developers. The people who asked for them were people who write code for embedded systems, and who had to use hex or decimal literals where binary literals would be neater and clearer. There were also people who had found similar features useful on other compilers, or used headers full of macros like "#define B00000001 0x01". No one is claiming that binary literals are essential, nor that they are used a lot - but sometimes they can be very useful in writing clearer and neater code. So please let us put this one to rest - they /are/ a useful feature, people want them, and people use them (since they are already implemented in many embedded compilers). And there can be no doubt that it would be better for the people that use binary literals, and the compilers that support them, for them to be made part of newer C standards as they are in newer C++ standards. Given how small a change this is to the language, it would not be difficult to add support for 0b binary literals to existing C compilers (Bart said it took merely a few minutes for him - even with documentation, test cases, etc., it is not a big change). Most serious C compilers these days are part of a compiler suite supporting C++ as well - sooner or later they will have binary literal support anyway. Ian gave a link showing the C++ proposal for adding 0b binary literals, which shows the minor changes needed to the C++ standards to support them. There is no reason to expect that changes to the C standards would be any more dramatic. No one is asking for support for binary literals in printf, scanf, or any other library functions (conversion to binary for output is simply enough to do "manually" when needed). There would be no conflict with any existing code. Thus I think it is pretty clear that the costs are minimal. It is hard to imagine a change to the language with lower costs. So even if the change only benefits a fraction of C programmers, it is useful to them, cost-free to other users, and minimal cost to compiler writers and the C standards committee. That sounds to me like benefits that are worth the cost. (And remember that the C++ committee agree on that score, and I presume they did a better cost/benefit analysis than either you or I.) > >> Of course, since /you/ think it is a bad idea, everyone else is >> clearly wrong. > > There's no reason to be sarcastic. If we have a difference of > opinion, we can explore that difference in a civilized way. I have yet to hear anything concrete from you other than that you think binary literals are a bad idea. You have offered no justification for claims that they are not useful, nor any justification for claims that they would be costly. I am not asking for any references or statistics - a short reasoning would be enough to get started. > >>>> particularly in embedded programming where we live in a world of >>>> bits for device registers, IO ports, and so on. [snip >>>> elaboration] >>> >>> I don't find this motivation convincing. ISTM that in such >>> cases one would want to define symbolic names for the various >>> masks, etc, and use those rather than putting binary constants >>> everywhere, in which cases the exact form of the constant >>> used is of much less importance. (Surely you don't mean to >>> suggest that embedded programmers are guilty of bad programming >>> practices?) Moreover I think it's likely that the documentation >>> that describes such fields gives their values in octal, decimal, >>> or hex rather than binary, excepting perhaps for masks which >>> are better described in terms of width and position than using >>> a long binary constant. >> >> I think that like many programmers (including me), you believe >> your own niche to be the most important, and extrapolate from it >> to other areas of programming. You are not an embedded systems >> developer, and in particular you don't work with small >> microcontrollers. You don't read datasheets, you don't work with >> these small systems, you don't write libraries or headers for >> them, and you don't live in a world of bits and bytes. So please >> don't try to make sweeping statements about when binary constants >> may or may not be useful to embedded programmers. > > An ad hominem argument. It's insulting and presumptuous of you > to tell me what my background and experience is. Furthermore > it's irrelevant to the discussion at hand, unless you are more > interested in scoring debate points than in understanding the > truth of the matter. I have been programming small embedded systems for over 20 years, in C, assembly, and a little C++. I have read (as in close to "cover to cover") many hundreds of datasheets. I have worked seriously with perhaps a dozen different microcontroller and cpu architectures. It is certainly possible that you have worked with embedded systems - as you say, I don't know your background and experiences, and "embedded" is a very wide field. (For example, Ian also works with embedded systems - yet I think there is quite a difference in the sorts of systems we usually work with, and the types of development we usually do.) But I am fed up with /you/ telling /me/ about small systems embedded development, and how small systems developers want to write their code, and how our datasheets and documents are written. /I/ am telling /you/ that datasheets use binary regularly, and they almost never use octal. I am telling you that embedded programmers like to be able to write binary literals on occasion, and many find them useful in writing clearer code. If another experienced embedded programmer (such as Ian) contradicts this, it is worth listening to him. But with all due respect for your knowledge and experience of programming, you cannot speak for small systems embedded developers. > >> The reality is that datasheets will use binary, decimal or >> hexadecimal as appropriate - with register fields being usually >> either binary or hexadecimal. (Octal is almost never used. I can >> only remember seeing it in the context of an ASCII character set >> on a small display, and that was a decade or two ago.) > > If you have facts and evidence to present, by all means present > them. Sweeping generalizations are meaningless. You want me to provide links for datasheets that use binary? Here's a couple of random microcontroller reference manuals. <http://www.atmel.com/Images/doc8077.pdf> <http://cache.freescale.com/files/32bit/doc/ref_manual/KL03P24M48SF0RM.pdf> Or do you want me to prove that octal is almost never used? > >> And the reality is that programmers will sometimes want to use >> hexadecimal constants in their code, and sometimes decimal, and >> sometimes binary, and sometimes using a shift notation such as (1u >> << 4). And sometimes they will want to give the constants a name >> or enum value in a header file or at the start of the C file, and >> sometimes they will want to use the constant directly in the code. >> Sometimes that might be "bad" programming practice - but sometimes >> it might be good practice. > > Even assuming all that is true, and I'm not sure it is, that > doesn't excuse not looking at the costs or comparing the costs > against the marginal utility gained. Have you, or has anyone > for that matter, even made an effort to estimate the marginal > utility in programmer time or program development cost? If the > argument is that it's valuable then we should try to find out > what the value is, in objective terms. Please tell us your experience in this area, and how often you have worked with low-level and bare-metal programming on small microcontrollers. That will help us judge the value of your gut feelings about how useful binary literals may or may not be to programmers in this area. As for the supposed costs for implementing 0b binary literals, I can only point out /again/ that they are already implemented on many major compilers, either as an extension in C or as a standards requirement in C++, and that the costs for standardisation in C++ were minimal. I am fully in agreement with you that any change requires a consideration and balance between the usefulness of the change and its costs. The disagreement is that you /imagine/ binary literals to be of little real use, while I /know/ they are used in the real world of embedded programming, and that you /imagine/ them to have high costs, while I /know/ they are already implemented at low cost. Trying to turn all this into an objective, quantifiable cost/benefit analysis with statistics of man-hours saved or cost is a worthy goal in theory - but in practice it is a waste of time in this case. It would take far longer merely to specify such a study properly than it would to simply add the required few lines to the next C standards draft. Remember, the equivalent C++ proposal document was 3 pages - the C proposal would be similar. > > Related to that, it is my pleasure to pass along a link from a > posting by Glen Herrmannsfeldt, to a talk about these kinds of > questions. You might find it interesting; I certainly did. > > https://www.cs.washington.edu/events/colloquia/search/details?id=2594 I haven't watched it yet, but I will do so. > >> So please just accept the reality that 0b binary constants are a >> useful feature, and would be a worthwhile addition to the C >> standards that would be welcomed by many embedded programmers, and >> happily ignored by most non-embedded programmers. > > If it's so important to you for binary constants to be added to > C, why don't you put in the effort of doing a serious > costs/benefits investigation, considering all the ramifications, > rather than just huffing and puffing? When considering new > language features to be added to C, the burden of proof is > generally understood to be on those proposing the change. And > that is as it should be. > It is not important for embedded programmers that these are added to the C standards - embedded programmers already have 0b binary literals in their compilers. It is important for the C standards committee - they have to follow what happens in the real world, or face increasing irrelevance. If we were to ask about 0b binary literals in comp.arch.embedded, where there are a great deal more practical-minded embedded developers, we would see several answers. There would be those people that use them, because they are useful and they work with their toolchains. There would be people who would want to use them, but unfortunately their toolchains don't support them. There would be people who had never thought about them, but now will start to use them. There would be people who would like to use them, but their coding standard mandates strict ANSI C (or whatever). And there will be people who think they are a nice idea even though they don't use them personally. I think it would be very unlikely to find people who thought they were a bad idea, or who would only use them if they get added to the C standards. It is the C standards committee that should be worried that people are using the "gnu11" standard rather than C11 standard.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-02 13:17 +0100 |
| Message-ID | <mpl1m9$bqc$1@dont-email.me> |
| In reply to | #66683 |
On 02/08/2015 12:37, David Brown wrote: > On 26/07/15 05:17, Tim Rentsch wrote: > Given how small a change this is to the language, it would not be > difficult to add support for 0b binary literals to existing C compilers > (Bart said it took merely a few minutes for him - even with > documentation, test cases, etc., it is not a big change). Well, I took a short cut by just duplicating the hex handling code, and modifying that - by removing support for 2-9, A-F and a-f. And it was for a small lexer project. It might take a bit longer for an actual compiler, and will need extra tests defined. But it is a very easy, well-understood modification. I can't see it taking beyond one day for someone familiar with a compiler. Adding support for separators is a little more fiddly, and the specification isn't so straightforward: should 0xA__B_ be legal or not? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-02 19:45 +0200 |
| Message-ID | <mplkst$g9p$2@dont-email.me> |
| In reply to | #66685 |
On 02/08/15 14:17, Bartc wrote: > On 02/08/2015 12:37, David Brown wrote: > >> On 26/07/15 05:17, Tim Rentsch wrote: > >> Given how small a change this is to the language, it would not be >> difficult to add support for 0b binary literals to existing C compilers >> (Bart said it took merely a few minutes for him - even with >> documentation, test cases, etc., it is not a big change). > > Well, I took a short cut by just duplicating the hex handling code, and > modifying that - by removing support for 2-9, A-F and a-f. > > And it was for a small lexer project. It might take a bit longer for an > actual compiler, and will need extra tests defined. But it is a very > easy, well-understood modification. I can't see it taking beyond one day > for someone familiar with a compiler. > > Adding support for separators is a little more fiddly, and the > specification isn't so straightforward: should 0xA__B_ be legal or not? > Separators would be a nice addition (for decimal and hex literals as well as for binary ones). C++14 settled on ' as a separator - apparently they worried that _ could lead to ambiguity (is "_123" a decimal literal with a separator, or is it an identifier?) or confusion in the code. IMHO, _ would be a better choice than ', but ' is better than no separator at all.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-02 15:52 -0700 |
| Message-ID | <lnoaipi9rg.fsf@kst-u.example.com> |
| In reply to | #66713 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Separators would be a nice addition (for decimal and hex literals as
> well as for binary ones). C++14 settled on ' as a separator -
> apparently they worried that _ could lead to ambiguity (is "_123" a
> decimal literal with a separator, or is it an identifier?) or confusion
> in the code. IMHO, _ would be a better choice than ', but ' is better
> than no separator at all.
_123 is unambiguously an identifier. Separators can only appear between
digits, not at the beginning or end of a constant.
C++ didn't use _ because it's used for user-defined literals.
I agree that _ would have been a better choice; there's ample precedent
for it other languages.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-03 09:34 +0200 |
| Message-ID | <mpn5ee$8lg$1@dont-email.me> |
| In reply to | #66755 |
On 03/08/15 00:52, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> Separators would be a nice addition (for decimal and hex literals as >> well as for binary ones). C++14 settled on ' as a separator - >> apparently they worried that _ could lead to ambiguity (is "_123" a >> decimal literal with a separator, or is it an identifier?) or confusion >> in the code. IMHO, _ would be a better choice than ', but ' is better >> than no separator at all. > > _123 is unambiguously an identifier. Separators can only appear between > digits, not at the beginning or end of a constant. Unambiguous to the standards and the compiler, but perhaps ambiguous to the casual reader who visually interprets _ as a separator. I think that is what the C++ committee were concerned about there. > > C++ didn't use _ because it's used for user-defined literals. I can see how that could be a significant problem. > > I agree that _ would have been a better choice; there's ample precedent > for it other languages. >
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-08-04 11:04 +0000 |
| Message-ID | <55c09a53.6713187@news.xs4all.nl> |
| In reply to | #66755 |
Keith Thompson <kst-u@mib.org> wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] > > Separators would be a nice addition (for decimal and hex literals as > > well as for binary ones). C++14 settled on ' as a separator - > > apparently they worried that _ could lead to ambiguity (is "_123" a > > decimal literal with a separator, or is it an identifier?) or confusion > > in the code. IMHO, _ would be a better choice than ', but ' is better > > than no separator at all. > > _123 is unambiguously an identifier. Separators can only appear between > digits, not at the beginning or end of a constant. > > C++ didn't use _ because it's used for user-defined literals. > > I agree that _ would have been a better choice; there's ample precedent > for it other languages. Then again, there is more precedent in everyday notation of numbers for using small punctuation in the form of a stop. Using pen and paper, we ourselves write 2,100,394,834.12 (or if we're continental, 2.100.394.834,12), or sometimes 2 100 394 834.12 with half-spaces (hard to do in a fixed-with Usenet font!), and historically have even used mid-line points; I have never seen anyone _write_ 2_100_394_834.12 in any natural language. Apparently there are even languages which already use the apostrophe as a thousands separator. I've never seen these myself. Regardless, though, it's clear that the apostrophe is a more legible, natural-language- similar choice than the underline, and therefore IMO superior. Richard
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-04 09:07 -0700 |
| Message-ID | <ln8u9rghqb.fsf@kst-u.example.com> |
| In reply to | #66844 |
raltbos@xs4all.nl (Richard Bos) writes:
> Keith Thompson <kst-u@mib.org> wrote:
[...]
>> I agree that _ would have been a better choice; there's ample precedent
>> for it other languages.
>
> Then again, there is more precedent in everyday notation of numbers for
> using small punctuation in the form of a stop. Using pen and paper, we
> ourselves write 2,100,394,834.12 (or if we're continental,
> 2.100.394.834,12), or sometimes 2 100 394 834.12 with half-spaces (hard
> to do in a fixed-with Usenet font!), and historically have even used
> mid-line points; I have never seen anyone _write_ 2_100_394_834.12 in
> any natural language.
> Apparently there are even languages which already use the apostrophe as
> a thousands separator. I've never seen these myself. Regardless, though,
> it's clear that the apostrophe is a more legible, natural-language-
> similar choice than the underline, and therefore IMO superior.
Currently in C this:
1'2'3
tokenizes as an integer constant 1, followed by a character constant
'2', followed by an integer constant 3 -- which causes an immediate
parse error. With the apostrophe used as a digit separator, it's a
single integer constant equivalent to 123.
I'm only about 95% sure that such a change wouldn't break any existing
valid code.
(I don't think I'll raise the question of whether I/O should handle
apostophes in numbers.)
--
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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-08-09 13:28 +0000 |
| Message-ID | <55c754ac.15472468@news.xs4all.nl> |
| In reply to | #66865 |
Keith Thompson <kst-u@mib.org> wrote: > raltbos@xs4all.nl (Richard Bos) writes: > > Apparently there are even languages which already use the apostrophe as > > a thousands separator. I've never seen these myself. Regardless, though, > > it's clear that the apostrophe is a more legible, natural-language- > > similar choice than the underline, and therefore IMO superior. > > Currently in C this: > > 1'2'3 > > tokenizes as an integer constant 1, followed by a character constant > '2', followed by an integer constant 3 -- which causes an immediate > parse error. With the apostrophe used as a digit separator, it's a > single integer constant equivalent to 123. > > I'm only about 95% sure that such a change wouldn't break any existing > valid code. That's a good point. I wouldn't stake my house on it, either. > (I don't think I'll raise the question of whether I/O should handle > apostophes in numbers.) Also a good point. Probably it needn't, though I think ' as a format format flag is currently just as free as _. Richard
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-08-02 14:00 -0500 |
| Message-ID | <nvpsrat1bscje2gil802q18vo9oavhoqo7@4ax.com> |
| In reply to | #66685 |
On Sun, 02 Aug 2015 13:17:43 +0100, Bartc <bc@freeuk.com> wrote: >On 02/08/2015 12:37, David Brown wrote: > >> On 26/07/15 05:17, Tim Rentsch wrote: > >> Given how small a change this is to the language, it would not be >> difficult to add support for 0b binary literals to existing C compilers >> (Bart said it took merely a few minutes for him - even with >> documentation, test cases, etc., it is not a big change). > >Well, I took a short cut by just duplicating the hex handling code, and >modifying that - by removing support for 2-9, A-F and a-f. > >And it was for a small lexer project. It might take a bit longer for an >actual compiler, and will need extra tests defined. But it is a very >easy, well-understood modification. I can't see it taking beyond one day >for someone familiar with a compiler. > >Adding support for separators is a little more fiddly, and the >specification isn't so straightforward: should 0xA__B_ be legal or not? I don't know why you wouldn't just follow the C++14 choices on this: Apostrophes, and repeated ones are not allowed. I think I'd have liked underscores a bit better, but I've no problems with the apostrophes (and those avoid some ambiguities).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-05 11:31 -0700 |
| Message-ID | <kfnvbbowwdj.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66721 |
Robert Wessel <robertwessel2@yahoo.com> writes: > On Sun, 02 Aug 2015 13:17:43 +0100, Bartc <bc@freeuk.com> wrote: > >> On 02/08/2015 12:37, David Brown wrote: >> >>> On 26/07/15 05:17, Tim Rentsch wrote: >>> >>> Given how small a change this is to the language, it would not be >>> difficult to add support for 0b binary literals to existing C compilers >>> (Bart said it took merely a few minutes for him - even with >>> documentation, test cases, etc., it is not a big change). >> >> Well, I took a short cut by just duplicating the hex handling code, and >> modifying that - by removing support for 2-9, A-F and a-f. >> >> And it was for a small lexer project. It might take a bit longer for an >> actual compiler, and will need extra tests defined. But it is a very >> easy, well-understood modification. I can't see it taking beyond one day >> for someone familiar with a compiler. >> >> Adding support for separators is a little more fiddly, and the >> specification isn't so straightforward: should 0xA__B_ be legal or not? > > I don't know why you wouldn't just follow the C++14 choices on this: > Apostrophes, and repeated ones are not allowed. I think I'd have > liked underscores a bit better, but I've no problems with the > apostrophes (and those avoid some ambiguities). It's a ghastly decision. We can only hope that the C++ choice doesn't come back around and get rammed down the throats of the C community. Bleah. Reflecting further on the above... I think the time has come for C to grant C++ a divorce. An amicable divorce if possible, but a divorce whether it is amicable or not.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-06 10:47 +0200 |
| Message-ID | <msguft$dr6$1@dont-email.me> |
| In reply to | #69512 |
On 05/09/15 20:31, Tim Rentsch wrote: > Robert Wessel <robertwessel2@yahoo.com> writes: > >> On Sun, 02 Aug 2015 13:17:43 +0100, Bartc <bc@freeuk.com> wrote: >> >>> On 02/08/2015 12:37, David Brown wrote: >>> >>>> On 26/07/15 05:17, Tim Rentsch wrote: >>>> >>>> Given how small a change this is to the language, it would not be >>>> difficult to add support for 0b binary literals to existing C compilers >>>> (Bart said it took merely a few minutes for him - even with >>>> documentation, test cases, etc., it is not a big change). >>> >>> Well, I took a short cut by just duplicating the hex handling code, and >>> modifying that - by removing support for 2-9, A-F and a-f. >>> >>> And it was for a small lexer project. It might take a bit longer for an >>> actual compiler, and will need extra tests defined. But it is a very >>> easy, well-understood modification. I can't see it taking beyond one day >>> for someone familiar with a compiler. >>> >>> Adding support for separators is a little more fiddly, and the >>> specification isn't so straightforward: should 0xA__B_ be legal or not? >> >> I don't know why you wouldn't just follow the C++14 choices on this: >> Apostrophes, and repeated ones are not allowed. I think I'd have >> liked underscores a bit better, but I've no problems with the >> apostrophes (and those avoid some ambiguities). > > It's a ghastly decision. We can only hope that the C++ > choice doesn't come back around and get rammed down the > throats of the C community. Bleah. Without any justification, that's just your personal opinion. You regularly complain (with reason, I admit) that /I/ give opinions as though they were indisputable facts. Here you see how easy it is to do so! The apostrophe was chosen not because it was the nicest character to use, but because it was the nicest character that would not cause ambiguity or conflicts with existing code. If the digit separator had been introduced to C++ before user-defined suffixes, then _ could be used - but it's hard to change history. > > Reflecting further on the above... I think the time has > come for C to grant C++ a divorce. An amicable divorce > if possible, but a divorce whether it is amicable or not. > C and C++ "divorced" a long time ago. But that does not, and should not, stop the two languages learning from each other and cooperating where appropriate. If the C committee decides that C could benefit from a digit separator, then it would be idiocy in the extreme to pick something other than C++14's apostrophe - even though I suspect that an underscore could work for C. Remember that while /you/ may live entirely in a world of C, a great many people do not. Many programmers who work mostly with C also have to deal with C++, and it is common to write C in a way that is compatible with C++ (or at least with header files that are C++ compatible). And almost every tool that works with C /or/ C++, also works with C /and/ C++ - unnecessary syntactic differences are a pain for compiler and editor developers. It would be better simply not to have a digit separator in C than to have one that is different from C++.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-06 13:27 -0700 |
| Message-ID | <ln1tebuwdn.fsf@kst-u.example.com> |
| In reply to | #69512 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Robert Wessel <robertwessel2@yahoo.com> writes:
[...]
>> I don't know why you wouldn't just follow the C++14 choices on this:
>> Apostrophes, and repeated ones are not allowed. I think I'd have
>> liked underscores a bit better, but I've no problems with the
>> apostrophes (and those avoid some ambiguities).
>
> It's a ghastly decision. We can only hope that the C++
> choice doesn't come back around and get rammed down the
> throats of the C community. Bleah.
There is real-world precedent for using the apostrophe, or something
that looks like it, as a digit separator.
See https://en.wikipedia.org/wiki/Decimal_mark#Digit_grouping
Apparently it's common in Italy and Switzerland, and the Unicode
DECIMAL SEPARATOR KEY SYMBOL U+2396 resembles an apostrophe.
(My own preference is the underscore, but that conflicts with an
existing C++ feature.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-02 15:53 -0700 |
| Message-ID | <lnk2tdi9ow.fsf@kst-u.example.com> |
| In reply to | #66685 |
Bartc <bc@freeuk.com> writes:
> On 02/08/2015 12:37, David Brown wrote:
>> On 26/07/15 05:17, Tim Rentsch wrote:
>> Given how small a change this is to the language, it would not be
>> difficult to add support for 0b binary literals to existing C compilers
>> (Bart said it took merely a few minutes for him - even with
>> documentation, test cases, etc., it is not a big change).
>
> Well, I took a short cut by just duplicating the hex handling code, and
> modifying that - by removing support for 2-9, A-F and a-f.
And, I trust, by multiplying by 2 rather than by 16. 8-)}
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-02 15:45 -0700 |
| Message-ID | <lnsi81ia2m.fsf@kst-u.example.com> |
| In reply to | #66683 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> No one is asking for support for binary literals in printf, scanf, or
> any other library functions (conversion to binary for output is simply
> enough to do "manually" when needed).
Well, I am. I favor adding 0b integer constants to the language *and*
adding corresponding support to the library.
--
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]
Page 14 of 22 — ← Prev page 1 … 12 13 [14] 15 16 … 22 Next page →
Back to top | Article view | comp.lang.c
csiph-web