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 11 of 22 — ← Prev page 1 … 9 10 [11] 12 13 … 22 Next page →
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2015-06-21 12:46 -0400 |
| Message-ID | <d908oa188g999ekmtqpbba5su4061ic81h@4ax.com> |
| In reply to | #62635 |
On Tue, 26 May 2015 14:59:41 +0100, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > David Brown <david.brown@hesbynett.no> writes: > <snip> > > (Octal literals other than 0, on the other hand, are practically > > non-existent in embedded code, and banned by many coding standards as > > confusing, hard to read, and error prone. When you work with data > > sizes of 8, 16 and 32 bits, a notation for 3 bit sizes is useless.) > > If the data are arbitrary, I agree, but octal is useful for some kinds > of data. The most common data you entered via the switches on the front > panel of a PDP-11 were instructions, and it's no accident that the > switches are grouped in threes as the instruction format is full of > octal-significant patterns. If you are doing low-level PDP-11 > programming you will use octal a lot, despite it being a 16-bit machine > with 8-bit bytes. The use of octal in the PDP-11 probably comes the > 36-bit PDP-10 range. > PDP-6 and -10 software did mostly use octal, but it wasn't a great fit; instrucations had a mixture including 4-bit and 5-bit fields, and software mostly used 7-bits for characters. The 12-bit PDP-5,8,12 and IIRC also 18-bit PDP-7,9 were more conveniently octal. And on LSI-11 models without switches (or blinkenlights, sadly) the serial-console 'virtual front panel' was a firmware form of the software debugger ODT, where O means what you can guess. > It's tempting to think the octal got into C because of the octal-heavy > DEC heritage, but octal constants where in B in exactly the same form (a > leading 0 indicating base 8) so I think they were probably just copied > into C in an environment where octal was used enough that there would be > no motivation to "tidy up" B by dropping them. > > B was developed on Honeywell 6000 machines (re-badged GE machines) which > also make heavy use of octal. Addresses are 18 bits and alphanumeric > data are composed of either 6 or 9 bit bytes. The opcodes are 9 bits > and some 3-bit portions denote variations. Octal was used almost > exclusively. Are you sure? Ritchie's HOPL2 paper on C says B was developed on the PDP-7 and moved to the (new) PDP-11 along with very early Unix, where it quickly 'evolved' into C, and *also* was ported to and used on H6070. By then it was too late to influence C. Ritchie's home page still(!) at https://www.bell-labs.com/usr/dmr/www/ has a 'User's Reference to B' dated Jan. 7 1972 for the PDP-11 version, and 'Computing Science Technical Report #8' in 2 parts (and 3 forms) dated Jan. 1973 for the GCOS version. Both say leading 0 means octal but DIGITS 8 AND 9 ARE STILL ALLOWED; the former gives an example that 09 is the same as 011! At least C fixed that.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-21 20:41 +0100 |
| Message-ID | <87pp4okfwl.fsf@bsb.me.uk> |
| In reply to | #63726 |
David Thompson <dave.thompson2@verizon.net> writes: > On Tue, 26 May 2015 14:59:41 +0100, Ben Bacarisse > <ben.usenet@bsb.me.uk> wrote: <snip> >> B was developed on Honeywell 6000 machines (re-badged GE machines) which >> also make heavy use of octal. Addresses are 18 bits and alphanumeric >> data are composed of either 6 or 9 bit bytes. The opcodes are 9 bits >> and some 3-bit portions denote variations. Octal was used almost >> exclusively. > > Are you sure? Ritchie's HOPL2 paper on C says B was developed on the > PDP-7 and moved to the (new) PDP-11 along with very early Unix, where > it quickly 'evolved' into C, and *also* was ported to and used on > H6070. By then it was too late to influence C. No, nor sure at all. I first used B on a Honeywell (at Aberdeen University of all places) which, I think, contributed to this notion, and the only document I've ever seen about it is "A TUTORIAL INTRODUCTION TO THE LANGUAGE B" by Kernighan (along with an associated language reference manual). Both refer only to the GCOS version but that is quite possibly because they were wrotten only for a GCOS audience. Both are undated but they probably come from Ritchie's site. I think the wording probably also lead me astray in a subliminal way: "B is a new computer language designed and implemented at Murray Hill. It runs and is actively supported and documented on the H6070 TSS system at Murray Hill." "The original design and implementation are the work of K. L. Thompson and D. M. Ritchie; their original 6070 version has been substantially improved by S. C. Johnson, who also wrote the runtime library." despite it not actually saying that the Honeywell version was the original one! <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-21 13:27 -0700 |
| Message-ID | <lnsi9kerht.fsf@nuthaus.mib.org> |
| In reply to | #63726 |
David Thompson <dave.thompson2@verizon.net> writes:
[...]
> Ritchie's home page still(!) at https://www.bell-labs.com/usr/dmr/www/
[...]
Ah, that's good news!
I had been accessing dmr's home page (and the documents linked
from it) via http://cm.bell-labs.com/cm/cs/who/dmr/, which has been
incommunicado for some time. I was afraid it had all been removed.
I'm glad to see that it still exists.
And in fact http://cm.bell-labs.com/ links to
http://www.bell-labs.com/; I hadn't thought to check for that.
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-10 10:19 -0700 |
| Message-ID | <kfnfv4w53r5.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #62591 |
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. > 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.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-11 08:47 +1200 |
| Message-ID | <d0apanFegarU2@mid.individual.net> |
| In reply to | #65143 |
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. Your opinions appear to be at odds with the majority of C++ programmers. Features get added because us programmers want them. >> 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. The documentation that describes such fields tends to be tables of bits, or a diagrammatic representation of registers. I for one have typed many a binary pattern into a calculator to generate a hex constant, at least I now have the option not to. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-11 13:40 -0700 |
| Message-ID | <kfn380uwhpp.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65186 |
Ian Collins <ian-news@hotmail.com> writes: > 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. > > Your opinions appear to be at odds with the majority of C++ > programmers. Features get added because us programmers want them. Surely you don't mean to suggest that most C++ programmers agree with every single design decision made for C++? That would be very surprising if true. >>> 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. > > The documentation that describes such fields tends to be tables of > bits, or a diagrammatic representation of registers. That doesn't match my experience, but for the sake of discussion let's assume that it is so. > I for one have > typed many a binary pattern into a calculator to generate a hex > constant, at least I now have the option not to. I expect you could easily come up with a better idea than that if you put your mind to it, eg, using constexpr. I knocked up a macro in C which I think could be used instead of a calculator and hex constants; it took about 10 minutes. For that matter the constants could be entered easily in octal; hex is a little bit funky, but converting binary to octal is basically just drawing a little line in every three bits. Probably it is also less error prone then putting in the binary directly.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-07-21 13:49 +0200 |
| Message-ID | <molbhc$jss$1@dont-email.me> |
| In reply to | #65143 |
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). 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. Of course, since /you/ think it is a bad idea, everyone else is clearly wrong. > >> 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. 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.) 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-25 20:17 -0700 |
| Message-ID | <kfnfv4bfw05.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66101 |
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. > 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. > 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. >>> 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. > 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. > 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. 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 > 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.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-26 16:54 +1200 |
| Message-ID | <d1j7ghFkmugU3@mid.individual.net> |
| In reply to | #66391 |
Tim Rentsch wrote: > David Brown <david.brown@hesbynett.no> writes: > >> 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. If it wasn't useful to embedded developers, they wouldn't have asked for it, would they? Surely standardising existing practice is one of the language committee's roles in life. If a feature has been requested and implemented by a number of compilers, it is both useful and existing practice. As for the cost, where would this arise? There's the link to the C++ proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-31 01:25 -0700 |
| Message-ID | <kfnk2tgbuow.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66393 |
Ian Collins <ian-news@hotmail.com> writes: > Tim Rentsch wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> 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. > > If it wasn't useful to embedded developers, they wouldn't have > asked for it, would they? I do think it would not have been asked for if some embedded developers didn't /think/ it would be useful (presumably, for them). Whether it is actually objectively useful, and how useful, and to what audience, are seprate questions. > Surely standardising existing practice is one of the language > committee's roles in life. That depends on what audience considers said language feature to be important. In 1999 ISO C added complex arithmetic types, presumably so Fortran code that uses such types could be (re-)written in C. But in 2011 this decision was partially reversed, and complex types were made an optional feature of standard C. Even though complex types are used by some members of the C development community, they aren't used widely enough to be required in standard C. Similarly just because some people think binary constants are useful doesn't make a compelling argument that every C implementation should be forced to provide them. > If a feature has been requested and > implemented by a number of compilers, it is both useful and > existing practice. Just because a feature has been implemented, in whatever number of compilers, doesn't mean it's useful. Furthermore the important question here is not whether binary constants can be implemented relatively easily, obviously they can. The question is how much marginal utililty do they offer, to what subset of the C development community, and what are the ramifications to the community as a whole for adding them? All I'm asking is that the people advocating the new feature make an effort to find an answer to these questions, which they seem unwilling to do. > As for the cost, where would this arise? I wrote a response to a posting by Robert Wessel which went through some of the considerations for collateral costs. Also, the link that I posted upthread has some interesting things to say on this question, for reference here that is again - https://www.cs.washington.edu/events/colloquia/search/details?id=2594 > There's the link to the C++ proposal: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf I think most people would agree that the attitude of C++ towards new language features is noticeably different from the attitude of C towards new language features (and appropriately so IMO). In any case the document mentioned doesn't give any justification or analysis of why it would be good to add binary constants to C++, it just says what they are, ie, what changes or additions would need to be made to the C++ standard document to include them. So this document doesn't address the questions that need addressing.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-31 17:46 -0700 |
| Message-ID | <ce035fe7-da60-4d3b-b428-a903b43a20f4@googlegroups.com> |
| In reply to | #66599 |
On Friday, July 31, 2015 at 1:25:22 AM UTC-7, Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > > > Tim Rentsch wrote: > >> David Brown <david.brown@hesbynett.no> writes: > >> > >>> 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. > > > > If it wasn't useful to embedded developers, they wouldn't have > > asked for it, would they? > > I do think it would not have been asked for if some embedded > developers didn't /think/ it would be useful (presumably, for > them). Whether it is actually objectively useful, and how > useful, and to what audience, are seprate questions. > > > Surely standardising existing practice is one of the language > > committee's roles in life. > > That depends on what audience considers said language feature > to be important. In 1999 ISO C added complex arithmetic types, > presumably so Fortran code that uses such types could be > (re-)written in C. But in 2011 this decision was partially > reversed, and complex types were made an optional feature of > standard C. Even though complex types are used by some > members of the C development community, they aren't used > widely enough to be required in standard C. Similarly just > because some people think binary constants are useful doesn't > make a compelling argument that every C implementation should > be forced to provide them. > > > If a feature has been requested and > > implemented by a number of compilers, it is both useful and > > existing practice. > > Just because a feature has been implemented, in whatever number > of compilers, doesn't mean it's useful. Furthermore the > important question here is not whether binary constants can be > implemented relatively easily, obviously they can. The question > is how much marginal utililty do they offer, to what subset of > the C development community, and what are the ramifications to > the community as a whole for adding them? All I'm asking is that > the people advocating the new feature make an effort to find an > answer to these questions, which they seem unwilling to do. > > > As for the cost, where would this arise? > > I wrote a response to a posting by Robert Wessel which went > through some of the considerations for collateral costs. > Also, the link that I posted upthread has some interesting > things to say on this question, for reference here that is > again - > > https://www.cs.washington.edu/events/colloquia/search/details?id=2594 > > > > There's the link to the C++ proposal: > > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf > > I think most people would agree that the attitude of C++ towards > new language features is noticeably different from the attitude > of C towards new language features (and appropriately so IMO). > In any case the document mentioned doesn't give any justification > or analysis of why it would be good to add binary constants to > C++, it just says what they are, ie, what changes or additions > would need to be made to the C++ standard document to include > them. So this document doesn't address the questions that > need addressing. It seems to me that it would be good programming style to add a comment at the start of each translation unit specifying what language is being used and what extensions and/or options. A simple ".c" is not enough these days.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-02 06:00 -0700 |
| Message-ID | <kfn3801c0be.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66627 |
David Kleinecke <dkleinecke@gmail.com> writes: >> [snip] > > It seems to me that it would be good programming style to add a > comment at the start of each translation unit specifying what > language is being used and what extensions and/or options. A > simple ".c" is not enough these days. I would not be inclined to do this, because in many cases a single source file supports multiple compilation environments. I agree a project should include the information, eg, in a makefile, but not in the source files themselves. YMMV.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-02 16:31 +0200 |
| Message-ID | <mpl9g7$5ep$1@dont-email.me> |
| In reply to | #66599 |
On 31/07/15 10:25, Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> Tim Rentsch wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> 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. >> >> If it wasn't useful to embedded developers, they wouldn't have >> asked for it, would they? > > I do think it would not have been asked for if some embedded > developers didn't /think/ it would be useful (presumably, for > them). Whether it is actually objectively useful, and how > useful, and to what audience, are seprate questions. While it is true that these are separate questions, are you really suggesting that embedded developers don't know what's good for them when they ask for (and use) binary literals, or that compiler vendors don't know what's good for them and their users when they implement binary literals, or that the C++ standards committee doesn't know how useful binary literals are? There are plenty of amateur or inexperienced embedded developers, but they are not /all/ kids asking for chocolate cake for dinner. > >> Surely standardising existing practice is one of the language >> committee's roles in life. > > That depends on what audience considers said language feature > to be important. In 1999 ISO C added complex arithmetic types, > presumably so Fortran code that uses such types could be > (re-)written in C. But in 2011 this decision was partially > reversed, and complex types were made an optional feature of > standard C. Even though complex types are used by some > members of the C development community, they aren't used > widely enough to be required in standard C. Similarly just > because some people think binary constants are useful doesn't > make a compelling argument that every C implementation should > be forced to provide them. This is the same cost/benefit argument as before, but the results are very different for complex arithmetic types and for binary literals. Complex arithmetic types are, well, complicated - supporting them is difficult and involves a good many changes to the compiler and libraries. They also (IMHO) fit badly with existing C. This makes their cost very high. I don't know how much use they get - I haven't seen them used (even though complex numbers are used in some embedded systems, such as for FFT's), but I don't work with the sorts of programs where they might be useful. > >> If a feature has been requested and >> implemented by a number of compilers, it is both useful and >> existing practice. > > Just because a feature has been implemented, in whatever number > of compilers, doesn't mean it's useful. Furthermore the > important question here is not whether binary constants can be > implemented relatively easily, obviously they can. The question > is how much marginal utililty do they offer, to what subset of > the C development community, and what are the ramifications to > the community as a whole for adding them? All I'm asking is that > the people advocating the new feature make an effort to find an > answer to these questions, which they seem unwilling to do. > We have made as good an effort to answer this as can reasonably be done in a discussion like this. There are /no/ hidden costs or ramifications, as demonstrated by the ease by which binary literals have been implemented in compilers and the minimal changes needed for their support in C++. One could imagine that there may be bugs introduced by someone writing a binary constant rather than a hex constant in their source code - but (without any supporting evidence) I would imagine that more bugs are caused by incorrect hex constants rather than using binary, or by accidental use of octal literals. >> As for the cost, where would this arise? > > I wrote a response to a posting by Robert Wessel which went > through some of the considerations for collateral costs. Many of the costs you list there are library issues - no one is asking for binary literals to be supported in the library. The people who make most use of binary literals also make the least use of the standard library. I agree that adding binary literals to printf, etc., would be a non-negligible effort (though I believe a lot less effort than you seem to think. In particular, I don't think there would be any issues with backward compatibility). > Also, the link that I posted upthread has some interesting > things to say on this question, for reference here that is > again - > > https://www.cs.washington.edu/events/colloquia/search/details?id=2594 > > >> There's the link to the C++ proposal: >> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf > > I think most people would agree that the attitude of C++ towards > new language features is noticeably different from the attitude > of C towards new language features (and appropriately so IMO). Agreed. However, C++ has shown how trivial this was to implement - C can usefully copy it. > In any case the document mentioned doesn't give any justification > or analysis of why it would be good to add binary constants to > C++, it just says what they are, ie, what changes or additions > would need to be made to the C++ standard document to include > them. So this document doesn't address the questions that > need addressing. >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-24 13:13 -0700 |
| Message-ID | <kfnd1ycxx4w.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66700 |
David Brown <david.brown@hesbynett.no> writes:
> On 31/07/15 10:25, Tim Rentsch wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>
>>> Tim Rentsch wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>>>>> 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.
>>>
>>> If it wasn't useful to embedded developers, they wouldn't have
>>> asked for it, would they?
>>
>> I do think it would not have been asked for if some embedded
>> developers didn't /think/ it would be useful (presumably, for
>> them). Whether it is actually objectively useful, and how
>> useful, and to what audience, are seprate questions.
>
> While it is true that these are separate questions, are you really
> suggesting that embedded developers don't know what's good for
> them when they ask for (and use) binary literals, or that compiler
> vendors don't know what's good for them and their users when they
> implement binary literals, or that the C++ standards committee
> doesn't know how useful binary literals are? [snip]
I don't pretend to know what the C++ standards committee knows or
how they arrive at their decisions. I simply note that the C++
community has a different philosophy regarding adding new and/or
experimental features to the language.
For compiler vendors, I don't think they know or care whether
a language feature is useful, or how useful. If someone asks
for it and it isn't too onerous to implment they put it in,
without considering whether that's a good idea.
For developers, either embedded developers or otherwise, I think
most developers have some idea of whether a language feature
provides some value to them individually, but don't have a good
idea of quantitatiely how much value, or of what the hidden costs
might be and what they are. Also there remains the question of
audience size - which developers are actually going to benefit
(ignoring for the moment the question of how much) if binary
constants were added? Even if developers have a good sense
of how much it would benefit them individually, it's unlikely
they have a good estimate for what the weighted average would
be.
>>> Surely standardising existing practice is one of the language
>>> committee's roles in life.
>>
>> That depends on what audience considers said language feature
>> to be important. In 1999 ISO C added complex arithmetic types,
>> presumably so Fortran code that uses such types could be
>> (re-)written in C. But in 2011 this decision was partially
>> reversed, and complex types were made an optional feature of
>> standard C. Even though complex types are used by some
>> members of the C development community, they aren't used
>> widely enough to be required in standard C. Similarly just
>> because some people think binary constants are useful doesn't
>> make a compelling argument that every C implementation should
>> be forced to provide them.
>
> This is the same cost/benefit argument as before, but the results
> are very different for complex arithmetic types and for binary
> literals. Complex arithmetic types are, well, complicated -
> supporting them is difficult and involves a good many changes to
> the compiler and libraries. They also (IMHO) fit badly with
> existing C. This makes their cost very high. I don't know how
> much use they get - I haven't seen them used (even though complex
> numbers are used in some embedded systems, such as for FFT's), but
> I don't work with the sorts of programs where they might be
> useful.
My point is that a language construct commonly used in a
particular subcommunity is not by itself sufficient to have it be
part of standard C.
Incidentally, I more or less agree with your comment about the
cost of implementing _Complex. On the flip side of that I think
those costs have mostly been paid already, and moreover the value
obtained (for those who need complex numbers) is significant. In
any case that doesn't really bear on the point I was trying to
make.
>>> If a feature has been requested and
>>> implemented by a number of compilers, it is both useful and
>>> existing practice.
>>
>> Just because a feature has been implemented, in whatever number
>> of compilers, doesn't mean it's useful. Furthermore the
>> important question here is not whether binary constants can be
>> implemented relatively easily, obviously they can. The question
>> is how much marginal utililty do they offer, to what subset of
>> the C development community, and what are the ramifications to
>> the community as a whole for adding them? All I'm asking is that
>> the people advocating the new feature make an effort to find an
>> answer to these questions, which they seem unwilling to do.
>
> We have made as good an effort to answer this as can reasonably be
> done in a discussion like this.
I haven't seen any effort to offer any quantitative information.
> There are /no/ hidden costs or
> ramifications, as demonstrated by the ease by which binary
> literals have been implemented in compilers and the minimal
> changes needed for their support in C++.
Flawed reasoning. Any costs outside of just implementation
wouldn't show up considering just the ease of implementing. Also
the costs for supporting binary constants, and the measures used
to weigh those costs, are different for C++ than they are for C.
> One could imagine that
> there may be bugs introduced by someone writing a binary constant
> rather than a hex constant in their source code - but (without any
> supporting evidence) I would imagine that more bugs are caused by
> incorrect hex constants rather than using binary, or by accidental
> use of octal literals.
Without some sort of objective evidence, even if only minimally
objective, we can't know whether these suppositions are true or
not. What I'm asking for is some sort of supporting evidence,
and I think it's reasonable to say that those who would propose
a new language feature should provide it. For example, it would
be interesting to see even a very limited study that compared
the productivity and error rates for developers using
a. hex constants
b. octal constants
c. either (a) or (b), with developer choice
d. non-built-in binary constants, eg, using the B2() macro
or something similar (perhaps both with and without
having (a) and (b) as options)
e. compiler-native binary constants
Perhaps you and some co-workers or associates could do an informal
trial of these different alternatives. I would love to hear what
you find out.
>>> As for the cost, where would this arise?
>>
>> I wrote a response to a posting by Robert Wessel which went
>> through some of the considerations for collateral costs.
>
> Many of the costs you list there are library issues - no one is
> asking for binary literals to be supported in the library.
Sorry, some people are. And I would argue that if binary
constants are added to the language they should also be added to
the library, to better maintain overall conceptual integrity.
> The
> people who make most use of binary literals also make the least
> use of the standard library.
But that doesn't mean they are the only people who matter. Adding
something to the language affects the entire C development
community, whether they use binary constants or not, and they
too should be taken into consideration.
> I agree that adding binary literals
> to printf, etc., would be a non-negligible effort (though I
> believe a lot less effort than you seem to think. In particular,
> I don't think there would be any issues with backward
> compatibility).
On the last point let me suggest that you haven't yet thought hard
enough. Clearly there could be, eg, with strtol().
>> Also, the link that I posted upthread has some interesting
>> things to say on this question, for reference here that is
>> again -
>>
>> https://www.cs.washington.edu/events/colloquia/search/details?id=2594
>>
>>
>>> There's the link to the C++ proposal:
>>>
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf
>>
>> I think most people would agree that the attitude of C++ towards
>> new language features is noticeably different from the attitude
>> of C towards new language features (and appropriately so IMO).
>
> Agreed.
>
> However, C++ has shown how trivial this was to implement - C can
> usefully copy it.
Even if the cost of implementating binary constants in the language
were zero, that doesn't mean they should be added. When considering
such changes it's important to take into account ALL the costs and
ALL the benefits, and quantitatively compare one against the other.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-08-25 08:36 +1200 |
| Message-ID | <d41dikFoivaU1@mid.individual.net> |
| In reply to | #68264 |
Tim Rentsch wrote: > David Brown <david.brown@hesbynett.no> writes: >> >> While it is true that these are separate questions, are you really >> suggesting that embedded developers don't know what's good for >> them when they ask for (and use) binary literals, or that compiler >> vendors don't know what's good for them and their users when they >> implement binary literals, or that the C++ standards committee >> doesn't know how useful binary literals are? [snip] > > I don't pretend to know what the C++ standards committee knows or > how they arrive at their decisions. I simply note that the C++ > community has a different philosophy regarding adding new and/or > experimental features to the language. Yes, the C++ standards committee does something really subversive: they engage with the developer community and adapt the language to meet the needs of that community. > For compiler vendors, I don't think they know or care whether > a language feature is useful, or how useful. If someone asks > for it and it isn't too onerous to implment they put it in, > without considering whether that's a good idea. Again, that listen. That don't presume to tell programmers what is and isn't useful. Your arguments are beginning to sound like a Victorian plutocrat telling the working classes what is and isn't good for them... > For developers, either embedded developers or otherwise, I think > most developers have some idea of whether a language feature > provides some value to them individually, but don't have a good > idea of quantitatiely how much value, or of what the hidden costs > might be and what they are. Also there remains the question of > audience size - which developers are actually going to benefit > (ignoring for the moment the question of how much) if binary > constants were added? Even if developers have a good sense > of how much it would benefit them individually, it's unlikely > they have a good estimate for what the weighted average would > be. Many times more than would benefit from _Complex is probably a safe bet. You can't take such a high handed position regarding costs and benefits when the C standards committee has already set that bar so low with C99. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-31 09:01 -0700 |
| Message-ID | <lnoaisl3k1.fsf@kst-u.example.com> |
| In reply to | #66393 |
Ian Collins <ian-news@hotmail.com> writes:
[...]
> There's the link to the C++ proposal:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf
From that proposal:
EWG decided in Portland (October 2012) to add core language
support for binary literals, with a 0b/0B prefix to distinguish
them (just as we have 0x/0X for hex and 0 for octal today). This
was after guidance from LWG that they preferred not to add this
support to the library.
Binary literals are in the N4296 draft, but as the above suggests
there's no library support for binary I/O. For example, this:
std::cout << std::showbase << std::hex << 42 << "\n";
will print
0x2a
but there's no corresponding way to print "0b101010" (which I find a bit
surprising).
As I mentioned earlier, if binary literals are added to C, I think
support should also be added to printf and scanf, probably using
"%b". If this happens, C++ will eventually incorporate that feature
as part of the C standard library. I suspect that would pressure
the C++ committee to add similar support to <iostream>.
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-08-01 08:13 +1200 |
| Message-ID | <d2237uFdvveU1@mid.individual.net> |
| In reply to | #66605 |
Keith Thompson wrote: > Ian Collins <ian-news@hotmail.com> writes: > [...] >> There's the link to the C++ proposal: >> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf > > From that proposal: > > EWG decided in Portland (October 2012) to add core language > support for binary literals, with a 0b/0B prefix to distinguish > them (just as we have 0x/0X for hex and 0 for octal today). This > was after guidance from LWG that they preferred not to add this > support to the library. > > Binary literals are in the N4296 draft, but as the above suggests > there's no library support for binary I/O. For example, this: > > std::cout << std::showbase << std::hex << 42 << "\n"; > > will print > > 0x2a > > but there's no corresponding way to print "0b101010" (which I find a bit > surprising). Given the driver for binary literals has been the embedded world, I don't find it surprising. > As I mentioned earlier, if binary literals are added to C, I think > support should also be added to printf and scanf, probably using > "%b". If this happens, C++ will eventually incorporate that feature > as part of the C standard library. I suspect that would pressure > the C++ committee to add similar support to <iostream>. C++ already has an (admittedly indirect) means of performing binary I/O using bitset. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-08-02 01:08 -0500 |
| Message-ID | <45crratneenjh9ktjt1l8ioskb7ehrr8e5@4ax.com> |
| In reply to | #66605 |
On Fri, 31 Jul 2015 09:01:02 -0700, Keith Thompson <kst-u@mib.org> wrote: >Ian Collins <ian-news@hotmail.com> writes: >[...] >> There's the link to the C++ proposal: >> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf > >From that proposal: > > EWG decided in Portland (October 2012) to add core language > support for binary literals, with a 0b/0B prefix to distinguish > them (just as we have 0x/0X for hex and 0 for octal today). This > was after guidance from LWG that they preferred not to add this > support to the library. > >Binary literals are in the N4296 draft, but as the above suggests >there's no library support for binary I/O. For example, this: > > std::cout << std::showbase << std::hex << 42 << "\n"; > >will print > > 0x2a > >but there's no corresponding way to print "0b101010" (which I find a bit >surprising). > >As I mentioned earlier, if binary literals are added to C, I think >support should also be added to printf and scanf, probably using >"%b". If this happens, C++ will eventually incorporate that feature >as part of the C standard library. I suspect that would pressure >the C++ committee to add similar support to <iostream>. I disagree. There's little requirement to input and output binary items. Binary literals in a program, OTOH, are quite useful in some circumstances. OTOH, if you wanted to add binary to printf, in additional to the existing octal and hex output, it's not a big deal, presumably would not hurt anything (leaving aside just which escape sequence to use - as has been pointed out "b" is taken), I just see little point. As for the input functions, I also don't *personally* care too much, since they're all pretty fundamentally broken anyway. Just the fact that they *do* allow hex and octal input (for integers), pretty much results in a mismatch with 99% of input specifications out there, except for some where the use of those was introduced as an accident (or bad decision), and we're stuck with it (the components of IPv4 addresses, for example). The error handling on the scanf functions also largely precludes their use. Some of the strto* functions are fairly usable, although if the input is base-16 they can still be a problem (and the strto* functions already support binary input). But adding binary support to the (other) input functions would likely break things, no matter my opinion of the usefulness of those functions. IOW, the C++ addition got it just right.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-02 14:29 -0700 |
| Message-ID | <ln1tfljs4u.fsf@kst-u.example.com> |
| In reply to | #66676 |
Robert Wessel <robertwessel2@yahoo.com> writes:
> On Fri, 31 Jul 2015 09:01:02 -0700, Keith Thompson <kst-u@mib.org>
> wrote:
[...]
>>As I mentioned earlier, if binary literals are added to C, I think
>>support should also be added to printf and scanf, probably using
>>"%b". If this happens, C++ will eventually incorporate that feature
>>as part of the C standard library. I suspect that would pressure
>>the C++ committee to add similar support to <iostream>.
>
> I disagree. There's little requirement to input and output binary
> items. Binary literals in a program, OTOH, are quite useful in some
> circumstances.
We have decimal, octal, and hexadecimal constants, input, and output.
Having decimal, octal, hexadecimal, and binary constants, but only
decimal, octal, and hexadecimal input and output would be inconsistent.
> OTOH, if you wanted to add binary to printf, in additional to the
> existing octal and hex output, it's not a big deal, presumably would
> not hurt anything (leaving aside just which escape sequence to use -
> as has been pointed out "b" is taken), I just see little point.
"b" isn't taken. What are you referring to?
> As for the input functions, I also don't *personally* care too much,
> since they're all pretty fundamentally broken anyway. Just the fact
> that they *do* allow hex and octal input (for integers), pretty much
> results in a mismatch with 99% of input specifications out there,
> except for some where the use of those was introduced as an accident
> (or bad decision), and we're stuck with it (the components of IPv4
> addresses, for example). The error handling on the scanf functions
> also largely precludes their use. Some of the strto* functions are
> fairly usable, although if the input is base-16 they can still be a
> problem (and the strto* functions already support binary input).
The fact that scanf() has undefined behavior on numeric overflow is a
real problem.
What's the problem with strto* and base 16?
> But
> adding binary support to the (other) input functions would likely
> break things, no matter my opinion of the usefulness of those
> functions.
>
> IOW, the C++ addition got it just right.
There is a small incompatibility. Currently this:
sscanf("0b11001001", "%i", &n);
succeeds and sets n to 0; the 'b' and everything after it is ignored.
With the proposed change, it would consume the entire string and set n
to 201. I don't think that's a serious problem.
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-08-03 09:15 +1200 |
| Message-ID | <d27fk4F55b9U4@mid.individual.net> |
| In reply to | #66741 |
Keith Thompson wrote: > Robert Wessel <robertwessel2@yahoo.com> writes: >> On Fri, 31 Jul 2015 09:01:02 -0700, Keith Thompson <kst-u@mib.org> >> wrote: > [...] >>> As I mentioned earlier, if binary literals are added to C, I think >>> support should also be added to printf and scanf, probably using >>> "%b". If this happens, C++ will eventually incorporate that feature >>> as part of the C standard library. I suspect that would pressure >>> the C++ committee to add similar support to <iostream>. >> >> I disagree. There's little requirement to input and output binary >> items. Binary literals in a program, OTOH, are quite useful in some >> circumstances. > > We have decimal, octal, and hexadecimal constants, input, and output. > Having decimal, octal, hexadecimal, and binary constants, but only > decimal, octal, and hexadecimal input and output would be inconsistent. But that doesn't detract from the utility of binary constants. As I said elsewhere, the use case for binary constants is primarily in the embedded world, stdio isn't a concern. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
Page 11 of 22 — ← Prev page 1 … 9 10 [11] 12 13 … 22 Next page →
Back to top | Article view | comp.lang.c
csiph-web