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 9 of 22 — ← Prev page 1 … 7 8 [9] 10 11 … 22 Next page →
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-07-16 14:21 -0500 |
| Message-ID | <9k0gqatf30mdpc1hqev6o5k64pl9s0i3lg@4ax.com> |
| In reply to | #65708 |
On Thu, 16 Jul 2015 08:48:45 -0700, Tim Rentsch <txr@alumni.caltech.edu> wrote: >Bartc <bc@freeuk.com> writes: > >> On 11/07/2015 19:19, Tim Rentsch wrote: >>> Bartc <bc@freeuk.com> writes: >>> >>>> What are those costs? As I can't see they impact library >>>> functions at all. >>> >>> Really? Are you familiar with the functions in <stdlib.h> >>> and <stdio.h>? >> >> Many of them, yes. One or two might be affected if it becomes >> necessary to support binary input and output. But binary is most >> useful when it's possible to write binary constants within the >> source code. I/O can be done with user functions. In that case, >> which library functions are affected? > >Obviously the C language designers have chosen to reflect the >presence (or absence) of certain constant format in various >library functions. There is no reason to assume binary >constants either should or would be treated any differently. >I'm sure you are capable of looking through the Standard >and discovering which functions fall into this category. > >>>> I am in the fortunate position of being able to write or adapt >>>> languages so that I can do what I like. But I feel sorry for those >>>> deprived of a simple, handy feature such as this, or are forced to >>>> resort to hairy-looking macros. >>> >>> Okay, but my comments here are made in the context of whether >>> something should be added to C. >> >> As I said, many people /would/ benefit, but others are deciding >> they shouldn't have it, something so fundamental that it is >> extraordinary that it isn't in already. > >A needlessly bombastic comment. I know your opinion; my point >is your opinion is not what counts in such cases. > >>> I have no opinion on what >>> should go into your pet language. >> >> My pet language [snip] > >I also have no interest in discussing your pet language while >in comp.lang.c. > >>>> I found it amusing once to list all the things that C programs didn't >>>> really need because it was possible to fall back on something >>>> else. Believe me, there wasn't much of the language left! >>> >>> I've looked through that list, or at least what I think you're >>> referring to. I didn't find it to be of much value, since >>> basically all it reflects is your own opinions; >> >> That's probably not the list. (If you're talking about the list >> of 100 Things', then quite a few people agreed with many of them. >> But I'm not surprised that you don't!) > >I think you misunderstood the point of my comment. I expect I >agreed with some of the items on your list and didn't agree with >others, but the point of my comment had nothing to do with >whether I agreed or not. > >> No, it's features that are not absolutely essential, like control >> structures, structs, or even most variables. You wouldn't want to >> program in such a language, but when using C as a target, then >> using such a stripped down language is feasible. > >AFAICT that has no bearing on the current discussion. Given what >has been under discussion, I don't know why you would bring it >up. > >> Binary constants are just another of those things that can make >> life a bit easier. > >I'm sure there are cases when having binary constants in C would >make some particular coding task easier. But the key questions >are how much easier, how rarely do those situations occur, and >what are the costs that would be borne if C added such constants. >You keep ignoring these questions; doing that makes any argument >you give be not convincing. FWIW, binary literals did get added in C++14.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-20 08:52 -0700 |
| Message-ID | <kfnmvyqomhg.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65713 |
Robert Wessel <robertwessel2@yahoo.com> writes: > On Thu, 16 Jul 2015 08:48:45 -0700, Tim Rentsch > <txr@alumni.caltech.edu> wrote: > >> I'm sure there are cases when having binary constants in C would >> make some particular coding task easier. But the key questions >> are how much easier, how rarely do those situations occur, and >> what are the costs that would be borne if C added such constants. >> You keep ignoring these questions; doing that makes any argument >> you give be not convincing. > > FWIW, binary literals did get added in C++14. Yes, one of those ideas that seems inevitable even if not really desirable. An unfortunate consequence of the "it can be done, therefore it should be done" mentality, which I am sorry to say is all too common. I prefer Dijkstra's comment: "Don't think something is convenient just because it is conventional."
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-20 21:21 +0000 |
| Message-ID | <mojop5$ajb$1@speranza.aioe.org> |
| In reply to | #66007 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > Robert Wessel <robertwessel2@yahoo.com> writes: (snip) >> FWIW, binary literals did get added in C++14. > Yes, one of those ideas that seems inevitable even if not > really desirable. An unfortunate consequence of the "it > can be done, therefore it should be done" mentality, which > I am sorry to say is all too common. I prefer Dijkstra's > comment: "Don't think something is convenient just because > it is conventional." IBM OS/360 and successor assemblers allow for binary (B) and hex (X) constants, but not octal. B constants are nice when describing bit masks, along with the appropriate comments. Personally, I don't have much trouble reading hex bit masks. Fortran allows BOZ (Binary, Octal, and for historical reasons, hexadecimal with a Z, constants.) It seems reasonably to add them to C. Most likely, they won't get overused. I rarely, if ever, use B constants in assembly code. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-23 02:49 -0700 |
| Message-ID | <kfny4i7i4pc.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66064 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Robert Wessel <robertwessel2@yahoo.com> writes:
>
> (snip)
>
>>> FWIW, binary literals did get added in C++14.
>>
>> Yes, one of those ideas that seems inevitable even if not
>> really desirable. An unfortunate consequence of the "it
>> can be done, therefore it should be done" mentality, which
>> I am sorry to say is all too common. I prefer Dijkstra's
>> comment: "Don't think something is convenient just because
>> it is conventional."
>
> IBM OS/360 and successor assemblers allow for binary (B) and
> hex (X) constants, but not octal. B constants are nice when
> describing bit masks, along with the appropriate comments.
IMO octal (or hex, depending) is better in most cases for bit
masks, for reasons illustrated by this quote:
"Can you do Addition?" the White Queen asked. "What's one
and one and one and one and one and one and one and one and
one and one?"
"I don't know," said Alice. "I lost count."
"She can't do Addition."
> Personally, I don't have much trouble reading hex bit masks.
>
> Fortran allows BOZ (Binary, Octal, and for historical reasons,
> hexadecimal with a Z, constants.)
>
> It seems reasonably to add them to C. Most likely, they won't get
> overused. I rarely, if ever, use B constants in assembly code.
The important question is not whether binary constants would be
used inappropriately, I'm sure they would be (as are all other
forms of constants). The question is Would they provide enough
additional utility to justify the cost of adding them to the
language. So far all of the comments I've seen don't give any
serious attention to the second half of that question.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-23 21:35 +0000 |
| Message-ID | <mormmo$2av$1@speranza.aioe.org> |
| In reply to | #66237 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: (snip, I wrote) >> IBM OS/360 and successor assemblers allow for binary (B) and >> hex (X) constants, but not octal. B constants are nice when >> describing bit masks, along with the appropriate comments. (snip) > The important question is not whether binary constants would be > used inappropriately, I'm sure they would be (as are all other > forms of constants). The question is Would they provide enough > additional utility to justify the cost of adding them to the > language. So far all of the comments I've seen don't give any > serious attention to the second half of that question. I believe this is the hard question for any proposed change. It is hard to know in advance the cost of the change, and also hard to know the added utility. If you are already making changes, adding some others might have a reduced cost. That is why they tend to come in big batches, instead of new features every year. And, like most other things related to software, people tend to underestimate the cost. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-27 07:30 -0700 |
| Message-ID | <kfnlhe1ekq4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66268 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > > (snip, I wrote) >>> IBM OS/360 and successor assemblers allow for binary (B) and >>> hex (X) constants, but not octal. B constants are nice when >>> describing bit masks, along with the appropriate comments. > > (snip) > >> The important question is not whether binary constants would be >> used inappropriately, I'm sure they would be (as are all other >> forms of constants). The question is Would they provide enough >> additional utility to justify the cost of adding them to the >> language. So far all of the comments I've seen don't give any >> serious attention to the second half of that question. > > I believe this is the hard question for any proposed change. > > It is hard to know in advance the cost of the change, and also > hard to know the added utility. I agree it isn't easy. But it's an important ingredient of any serious proposal to change a language as widespread as C, and the onus of making an effort to provide it clearly falls on those who would advocate such a change. > If you are already making changes, adding some others might have > a reduced cost. That is why they tend to come in big batches, > instead of new features every year. First, remember that changing the Standard means changing not just one compiler but many compilers. (How many? I don't have even a binary order of magnitude estimate for that.) Second, in this particular case the cost of code in the compiler is rather low down on the cost totem pole - it is the collateral costs that dominate (like that talk pointed out - thank you again for that link), and those costs do not benefit so much from batching. > And, like most other things related to software, people tend > to underestimate the cost. Yes, and I think that is especially true in this case, either through ignorance or wishful thinking.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-07-24 15:35 -0500 |
| Message-ID | <6885rah8q191q0k36sorfc9nuevcf7qder@4ax.com> |
| In reply to | #66237 |
On Thu, 23 Jul 2015 02:49:35 -0700, Tim Rentsch <txr@alumni.caltech.edu> wrote: >glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > >> Tim Rentsch <txr@alumni.caltech.edu> wrote: >>> Robert Wessel <robertwessel2@yahoo.com> writes: >> >> (snip) >> >>>> FWIW, binary literals did get added in C++14. >>> >>> Yes, one of those ideas that seems inevitable even if not >>> really desirable. An unfortunate consequence of the "it >>> can be done, therefore it should be done" mentality, which >>> I am sorry to say is all too common. I prefer Dijkstra's >>> comment: "Don't think something is convenient just because >>> it is conventional." >> >> IBM OS/360 and successor assemblers allow for binary (B) and >> hex (X) constants, but not octal. B constants are nice when >> describing bit masks, along with the appropriate comments. > >IMO octal (or hex, depending) is better in most cases for bit >masks, for reasons illustrated by this quote: > > "Can you do Addition?" the White Queen asked. "What's one > and one and one and one and one and one and one and one and > one and one?" > > "I don't know," said Alice. "I lost count." > > "She can't do Addition." > >> Personally, I don't have much trouble reading hex bit masks. >> >> Fortran allows BOZ (Binary, Octal, and for historical reasons, >> hexadecimal with a Z, constants.) >> >> It seems reasonably to add them to C. Most likely, they won't get >> overused. I rarely, if ever, use B constants in assembly code. > >The important question is not whether binary constants would be >used inappropriately, I'm sure they would be (as are all other >forms of constants). The question is Would they provide enough >additional utility to justify the cost of adding them to the >language. So far all of the comments I've seen don't give any >serious attention to the second half of that question. I think several people have suggested that the impact on the language of adding binary literals would be trivial. I find it difficult to image otherwise. On the flip side, a minority of people have stated that there would be a fair bit of practical value for them. I get that you don't agree.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-27 08:13 -0700 |
| Message-ID | <kfnh9opeiqr.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66311 |
Robert Wessel <robertwessel2@yahoo.com> writes: > On Thu, 23 Jul 2015 02:49:35 -0700, Tim Rentsch > <txr@alumni.caltech.edu> wrote: > >> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: >> >>> Tim Rentsch <txr@alumni.caltech.edu> wrote: >>>> Robert Wessel <robertwessel2@yahoo.com> writes: >>> >>> (snip) >>> >>>>> FWIW, binary literals did get added in C++14. >>>> >>>> Yes, one of those ideas that seems inevitable even if not >>>> really desirable. An unfortunate consequence of the "it >>>> can be done, therefore it should be done" mentality, which >>>> I am sorry to say is all too common. I prefer Dijkstra's >>>> comment: "Don't think something is convenient just because >>>> it is conventional." >>> >>> IBM OS/360 and successor assemblers allow for binary (B) and >>> hex (X) constants, but not octal. B constants are nice when >>> describing bit masks, along with the appropriate comments. >> >> IMO octal (or hex, depending) is better in most cases for bit >> masks, for reasons illustrated by this quote: >> >> "Can you do Addition?" the White Queen asked. "What's one >> and one and one and one and one and one and one and one and >> one and one?" >> >> "I don't know," said Alice. "I lost count." >> >> "She can't do Addition." >> >>> Personally, I don't have much trouble reading hex bit masks. >>> >>> Fortran allows BOZ (Binary, Octal, and for historical reasons, >>> hexadecimal with a Z, constants.) >>> >>> It seems reasonably to add them to C. Most likely, they won't get >>> overused. I rarely, if ever, use B constants in assembly code. >> >> The important question is not whether binary constants would be >> used inappropriately, I'm sure they would be (as are all other >> forms of constants). The question is Would they provide enough >> additional utility to justify the cost of adding them to the >> language. So far all of the comments I've seen don't give any >> serious attention to the second half of that question. > > I think several people have suggested that the impact on the > language of adding binary literals would be trivial. I find it > difficult to image otherwise. For the sake of discussion let's suppose that the cost of changing all existing C compilers to accept binary constants is effectively zero. I don't think it really is, but let's suppose that it is. Now let's look at what the collateral costs are or might be. First, to be consistent, I imagine WG14 would want to review functions in the standard library to see if they need parallel changes. An obvious example is the *printf() functions. I think a case could be made (and IMO it should prevail) that format specifiers should be added corresponding to the new format of constants accepted. On another axis, the change is one that would go into a later version of C, not the currently existing one. So compilers that support several different versions of the standard (and I assume many or most do) would have to check which version they are running to determine whether binary constants should be accepted or a warning/error generated. That might imply adding a compiler option to allow binary constants (with an appropriate diagnostic) in C90, C99 and C11 compilers. Another form of cost comes from a desire to have warning-free code even when compiled under different versions of C. That could mean code that makes use of macros and/or pre-processing directives so those environments wouldn't produce diagnostics. There is a cost associated with writing the descriptions for how such constants behave, of reading those new descriptions, and educating new students about them. The latter costs are individually small but multiplied by a pretty large number of students. Also there are costs associated with dealing with different people using different compilers in such situations. Another aspect of library functions is functions that do input rather than output. The strto*l() functions, for example, accept hexadecimal and octal constants. If the language is changed to allow binary constants, should strto*l() be updated to accept them as well? (Personally I think it should, for the sake of consistency.) However, if it is changed, that means different behavior on some inputs to those functions. Do this mean that standard libraries will need some sort of version selection mechanism, so different programs can get the old behavior or the new behavior? What about those libraries that don't provide an option (and I expect some would not). As it is often true that libraries are decoupled from which compiler is (or was) used, some programs would break in some circumstances. What if that behavior were used as an attack vector by a clever computer virus? What is the cost of that? Last but not least, a cost to consider is opportunity cost. The attention of WG14 is a finite resource, and any time they spend evaluating or adopting binary constants is time they will not spend on something else. Again for the sake of discussion let's suppose that binary constants have positive value. Even if that's true they are _way_ down the priority scale as far as I'm concerned. For example, if forced to make a choice, I would much rather have underscore separators allowed in numbers than binary constants. It is not enough that the benefit/cost ratio be greater than one - it should also be large enough that it makes the cut when considered in the context of what all else is vying for WG14's attention. > On the flip side, a minority of people have stated that there > would be a fair bit of practical value for them. I get that you > don't agree. What I think is more significant is not that the values are different but that they appear to occupy different type spaces. I think of "value" as being a real-valued scalar quantity, given in some sort of recognizable units. The people who are advocating adding binary constants seem to think of this value as being of type boolean. It's hard to make sense of a cost/benefit analysis when the cost value and the benefit value are both expressed as booleans.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-27 18:14 +0100 |
| Message-ID | <mp5orc$1bb$1@dont-email.me> |
| In reply to | #66443 |
On 27/07/2015 16:13, Tim Rentsch wrote: > Robert Wessel <robertwessel2@yahoo.com> writes: > There is a cost associated with writing the descriptions for how > such constants behave, of reading those new descriptions, and > educating new students about them. The latter costs are > individually small but multiplied by a pretty large number of > students. I think that's a new one in this group: deciding not to go for a new proposal because it might be necessary for someone to write it up, and for someone else to read it! (If you're really worried the costs of educating people, think about having to teach them about C's inside-out type specifiers.) > Again for the sake of discussion let's > suppose that binary constants have positive value. Even if > that's true they are _way_ down the priority scale as far as I'm > concerned. For example, if forced to make a choice, I would much > rather have underscore separators allowed in numbers than binary > constants. OK, so we have both, and in fact binary literals need separators more. It's not as though the committee is going to bring out a new 2015 C version that only has a single change - binary literials - and then we have to wait until all implementations have caught up. These updates are done every few years, and binary literals would be one of many changes done at the same time. But, hang on, don't we need to first put together a steering committee so that we can conduct proper time and efficiency assessments before separators can go in? And at the same time appoint a set of accountants to work out whether the cost of writing the half a page of documentation, and the cost of having to read it, is going to be offset enough by increases in programmer productivity. Or can we give all that a miss this time because it happens to be a feature you like? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-01 09:06 -0700 |
| Message-ID | <kfnfv43at8v.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66449 |
Bartc <bc@freeuk.com> writes: > On 27/07/2015 16:13, Tim Rentsch wrote: >> Robert Wessel <robertwessel2@yahoo.com> writes: >> >> There is a cost associated with writing the descriptions for how >> such constants behave, of reading those new descriptions, and >> educating new students about them. The latter costs are >> individually small but multiplied by a pretty large number of >> students. > > I think that's a new one in this group: deciding not to go for a > new proposal because it might be necessary for someone to write it > up, and for someone else to read it! That isn't what I'm talking about. Presumably someone like you would be writing the initial proposal, and given they are wanting to do that I'm happy to assign a cost of zero to that part of it. What I am talking about is all the paperwork that happens after the proposal is submitted, which is done on WG14's time, not yours. > (If you're really worried the costs of educating people, think > about having to teach them about C's inside-out type specifiers.) That's a done deal. The proposed addition of binary constants is not. >> Again for the sake of discussion let's >> suppose that binary constants have positive value. Even if >> that's true they are _way_ down the priority scale as far as I'm >> concerned. For example, if forced to make a choice, I would much >> rather have underscore separators allowed in numbers than binary >> constants. > > OK, so we have both, and in fact binary literals need separators > more. What part of the phrase "finite resource" do you not understand? The list is a lot longer than just those two items; as always in engineering situations the question is what do you choose when you can't have everything. > It's not as though the committee is going to bring out a new 2015 > C version that only has a single change - binary literials - and > then we have to wait until all implementations have caught up. > These updates are done every few years, and binary literals would > be one of many changes done at the same time. They could be, but that doesn't change my point - any time spent considering binary constants will be time spent not considering something else, almost all of which are more important than binary constants. > But, hang on, don't we need to first put together a steering > committee so that we can conduct proper time and efficiency > assessments before separators can go in? And at the same time > appoint a set of accountants to work out whether the cost of > writing the half a page of documentation, and the cost of having > to read it, is going to be offset enough by increases in > programmer productivity. I assume you're being sarcastic because you don't have any sort of reasoned response to my comments. > Or can we give all that a miss this time because it happens to > be a feature you like? No, I think WG14 should go through their usual vetting process (as I believe they are required by ISO to do) for all proposed changes and/or additions, regardless of whether I favor some particular new feature or not.
[toc] | [prev] | [next] | [standalone]
| From | "Bartc" <bartc@freeuk.com> |
|---|---|
| Date | 2015-08-01 18:26 +0100 |
| Message-ID | <mpivg3$1up$1@dont-email.me> |
| In reply to | #66639 |
"Tim Rentsch" <txr@alumni.caltech.edu> wrote in message news:kfnfv43at8v.fsf@x-alumni2.alumni.caltech.edu... > Bartc <bc@freeuk.com> writes: > >> On 27/07/2015 16:13, Tim Rentsch wrote: >> (If you're really worried the costs of educating people, think >> about having to teach them about C's inside-out type specifiers.) > > That's a done deal. The proposed addition of binary constants > is not. Educating people about some of C's quirky features is always on-going. I've proposed before ways of superimposing a left-to-right type declaration scheme, but that is more difficult to implement and really has zero chance of being part of a future standard. People will just have to keep using utlities such as Cdecl. Think of the increases in productivity however. (I mainly use my own syntax now even if I need to end up with C code, so I'm less interested in such features for my own benefit. I just feel sorry for everyone else!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-09 08:45 -0700 |
| Message-ID | <kfn614o79ei.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66643 |
"Bartc" <bartc@freeuk.com> writes: > "Tim Rentsch" <txr@alumni.caltech.edu> wrote in message > news:kfnfv43at8v.fsf@x-alumni2.alumni.caltech.edu... >> Bartc <bc@freeuk.com> writes: >> >>> On 27/07/2015 16:13, Tim Rentsch wrote: >>> >>> (If you're really worried the costs of educating people, think >>> about having to teach them about C's inside-out type specifiers.) >> >> That's a done deal. The proposed addition of binary constants >> is not. > > Educating people about some of C's quirky features is always > on-going. That's not an argument to add to the burden. If anything it's an argument /not/ to add to the burden. > I've proposed before ways of superimposing a left-to-right type > declaration scheme, but that is more difficult to implement and > really has zero chance of being part of a future standard. > [snip elaboration] What you're suggesting is a non-starter, because legacy code will still use the old style. Having two styles is worse than having one suboptimal one. > Think of the increases in productivity however. I know you think there would be increases in productivity. But I still haven't seen any evidence that supports the claim that they would even be significant, let alone large, for either change.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-23 11:48 +0100 |
| Message-ID | <moqgmg$3qb$1@dont-email.me> |
| In reply to | #66064 |
On 20/07/2015 22:21, glen herrmannsfeldt wrote: > Tim Rentsch <txr@alumni.caltech.edu> wrote: >> Robert Wessel <robertwessel2@yahoo.com> writes: > > (snip) > >>> FWIW, binary literals did get added in C++14. > >> Yes, one of those ideas that seems inevitable even if not >> really desirable. An unfortunate consequence of the "it >> can be done, therefore it should be done" mentality, which >> I am sorry to say is all too common. I prefer Dijkstra's >> comment: "Don't think something is convenient just because >> it is conventional." > > IBM OS/360 and successor assemblers allow for binary (B) and > hex (X) constants, but not octal. B constants are nice when > describing bit masks, along with the appropriate comments. > > Personally, I don't have much trouble reading hex bit masks. But it /is/ a little more trouble. I couldn't immediately tell that 0x358 ix 0x1AC shifted left one place for example. It's a bit easier in binary: 0B110101100 and 0B1101011000, especially if separators are used to highlight that, or if they're simply lined up: 0B110101100, 0B1101011000, Nor can I easily tell that 0x61 is a bit-reversed version of 0x43 (0B1100001 and 0B1000011). Every so often, something like this comes up and it's just an extra tool that can be used. (Now someone will come along and say that Emacs can be configured to instantly display any constant in a dozen different bases. Fine, then we can scrap octal and hex too!) (Another actual example was when setting several adjacent single-bit flags in one go. Each flag is 0 or 1. If I'm setting 3 or them, it is clearer to me to use 101B (or 0B101 in C), instead of just 5. The 5 would be meaningless here. The 101 just means (1,0,1) or (T,F,T). But obviously, a lot of people have already made up their minds they don't want binary literals.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-27 08:50 -0700 |
| Message-ID | <kfn8ua1eh1q.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66246 |
Bartc <bc@freeuk.com> writes: > [snip] > > But obviously, a lot of people have already made up their minds > they don't want binary literals.) This bothers you only because it's different from how you have already made up your mind. Stop being such a baby.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-17 11:49 +0100 |
| Message-ID | <moamgm$hti$1@dont-email.me> |
| In reply to | #65708 |
On 16/07/2015 16:48, Tim Rentsch wrote: > Bartc <bc@freeuk.com> writes: >> My pet language [snip] > > I also have no interest in discussing your pet language while > in comp.lang.c. If we're discussing whether a feature X is worth adding to C, then I think how well the feature worked in language Y or how easy or hard it was to implement can be relevant. Whether Y is someone's 'pet language' or not (which was /your/ somewhat belittling term), is not that important. >> Binary constants are just another of those things that can make >> life a bit easier. > > I'm sure there are cases when having binary constants in C would > make some particular coding task easier. But the key questions > are how much easier, how rarely do those situations occur, and > what are the costs that would be borne if C added such constants. > You keep ignoring these questions; doing that makes any argument > you give be not convincing. Binary constants are a no-brainer; that's what /you/ keep ignoring. A few C compilers in fact already implement them as extensions. With gcc, they are written as 0b10101. However, no one is holding a gun to your head; you don't have to use them. And they will have virtually zero effect on your code other than it will not pick up '0b10101' as a syntax error if you were to type it by mistake. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-20 09:06 -0700 |
| Message-ID | <kfnio9eolth.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65766 |
Bartc <bc@freeuk.com> writes: > On 16/07/2015 16:48, Tim Rentsch wrote: >> Bartc <bc@freeuk.com> writes: >> >>> My pet language [snip] >> >> I also have no interest in discussing your pet language while >> in comp.lang.c. > > If we're discussing whether a feature X is worth adding to C, then I > think how well the feature worked in language Y or how easy or hard it > was to implement can be relevant. That may be relevant, but even if it is, whatever relevance there is is closer to being a low order bit than a high order bit. > Whether Y is someone's 'pet language' or not (which was /your/ > somewhat belittling term), is not that important. I'm sorry it came across that way, that was not what I intended. My point is that the other language mentioned is substantially different from C along a variety of axes, not the least of which is that it addresses a much smaller audience of developers. >>> Binary constants are just another of those things that can make >>> life a bit easier. >> >> I'm sure there are cases when having binary constants in C would >> make some particular coding task easier. But the key questions >> are how much easier, how rarely do those situations occur, and >> what are the costs that would be borne if C added such constants. >> You keep ignoring these questions; doing that makes any argument >> you give be not convincing. > > Binary constants are a no-brainer; that's what /you/ keep ignoring. Any time someone suggests I turn off rational thought processes I'm suspicious that there is something they don't want me to think about. I understand that /you/ think the question is a no-brainer. I think it's important for you to realize that other people use different thought processes to reach their conclusions. > A few C compilers in fact already implement them as extensions. With > gcc, they are written as 0b10101. However, no one is holding a gun to > your head; you don't have to use them. And they will have virtually > zero effect on your code other than it will not pick up '0b10101' as a > syntax error if you were to type it by mistake. You keep focusing on implementation. To me implementation is at best a secondary consideration here. I object on principle to the kitchen-sink mentality of adding any easy feature anyone can think of, just because it's easy. Whether you like it or not, when it comes to C, your opinion counts for almost nothing. It would be nice if you would recognize that fact and start phrasing your statements keeping that in mind. Otherwise it is just very tiresome to keep hearing.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-20 18:18 +0100 |
| Message-ID | <mojadi$6g3$1@dont-email.me> |
| In reply to | #66009 |
On 20/07/2015 17:06, Tim Rentsch wrote: > Bartc <bc@freeuk.com> writes: [Binary literals] >> A few C compilers in fact already implement them as extensions. With >> gcc, they are written as 0b10101. > You keep focusing on implementation. To me implementation is at > best a secondary consideration here. I object on principle to > the kitchen-sink mentality of adding any easy feature anyone can > think of, just because it's easy. Whether you like it or not, > when it comes to C, your opinion counts for almost nothing. Just mine, or everyone's? With these things opinions is what we have to work with. Because any binary number can be transformed into a decimal or hexadecimal one, that can always be used as an argument for never needing such a feature. Then, it can only a matter of opinion whether adding this feature is going to be worthwhile or not. *IMO*, if people ever have to waste time converting numbers because binary is not supported, or need to waste more time devising esoteric macros if it's important that significant bit patterns stay visible and easily maintained (so you can't just have them as a comment), then that is plenty of reason to have it. It > would be nice if you would recognize that fact and start phrasing > your statements keeping that in mind. Otherwise it is just very > tiresome to keep hearing. > I get tired of putting forward the same arguments too! Take the old debate about format codes in printf() calls. I keep saying that having to embed %llU etc in format strings is wrong; people keep disagreeing. Yet just a couple of days ago I was debugging something and I need to print out HWND and UINT values, when I had to pause; were they 32-bits or 64-bits? I had to take a guess and hope it worked. *IMO* it's wrong that it works that way. But apparently my opinion is worth nothing; it's me that's wrong, and C that is right by forcing people to pot-shots at likely format specifiers when confronted with a LONG or a HBITMAP or an LRESULT. And if everyone's opinion is equally worthless, then it's a miracle that anything ever evolves! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-20 11:52 -0700 |
| Message-ID | <lnk2tufyq4.fsf@kst-u.example.com> |
| In reply to | #66024 |
Bartc <bc@freeuk.com> writes:
[...]
> Take the old debate about format codes in printf() calls. I keep saying
> that having to embed %llU etc in format strings is wrong; people keep
> disagreeing.
I don't think "wrong" is the best word. I do agree that having to
specify the type of an object when printing its value is annoying. The
problem is that avoiding that annoyance would require changes to the
language, and it's not clear that the benefits of such changes would be
worth the cost.
printf format strings are a hack; their main virtue is that they work.
> Yet just a couple of days ago I was debugging something and I need to
> print out HWND and UINT values, when I had to pause; were they 32-bits
> or 64-bits? I had to take a guess and hope it worked.
You didn't *have* to guess. You could have converted to a 64-bit type
and printed that value.
HWND is a pointer type; I think it's safe to assume that UINT is an
unsigned integer type.
HWND h = ...;
UINT u = ...;
printf("h = %p, u = %lu\n", (void*)h, (unsigned long)u);
This assumes C90; in C99 or later I'd use "%ju" and uintmax_t.
(And if UINT is simply unsigned int, I'd use unsigned int in the first
place and wonder why someone felt the need to invent another name for
it.0
> *IMO* it's wrong that it works that way. But apparently my opinion is
> worth nothing; it's me that's wrong, and C that is right by forcing
> people to pot-shots at likely format specifiers when confronted with a
> LONG or a HBITMAP or an LRESULT.
>
> And if everyone's opinion is equally worthless, then it's a miracle that
> anything ever evolves!
Don't confuse explanations of how C is defined with advocacy.
--
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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2015-07-20 20:09 +0100 |
| Message-ID | <87615e4pf3.fsf@gmail.com> |
| In reply to | #66043 |
Keith Thompson <kst-u@mib.org> writes: > I don't think "wrong" is the best word. I do agree that having to > specify the type of an object when printing its value is annoying. > The problem is that avoiding that annoyance would require changes to > the language, and it's not clear that the benefits of such changes > would be worth the cost. It'd be relatively easy to co-opt an unused format specifier as an optional externsion (I'd pick "%?") to mean "The compiler chooses based on the types of the varargs" That'd be backwards compatible relatively easy to implement in compilers that already do format-string <-> type checking.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-20 13:18 -0700 |
| Message-ID | <ln4mkyfur2.fsf@kst-u.example.com> |
| In reply to | #66044 |
Gareth Owen <gwowen@gmail.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> I don't think "wrong" is the best word. I do agree that having to
>> specify the type of an object when printing its value is annoying.
>> The problem is that avoiding that annoyance would require changes to
>> the language, and it's not clear that the benefits of such changes
>> would be worth the cost.
>
> It'd be relatively easy to co-opt an unused format specifier as an
> optional externsion (I'd pick "%?") to mean
>
> "The compiler chooses based on the types of the varargs"
>
> That'd be backwards compatible relatively easy to implement in compilers
> that already do format-string <-> type checking.
Assuming that printf() is implemented in C, how would it retrieve the
value of the corresponding argument?
If printf() sees a "%d" specifier, it knows it needs to invoke
va_arg(ap, int);
If it sees "%?", what does it do?
Or would the compiler translate
printf("%?", 42)
to
printf("%d", 42)
? Does that imply that it would only work if the format string is a
literal, or at least known at compile time?
--
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 9 of 22 — ← Prev page 1 … 7 8 [9] 10 11 … 22 Next page →
Back to top | Article view | comp.lang.c
csiph-web