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 13 of 22 — ← Prev page 1 … 11 12 [13] 14 15 … 22 Next page →
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-08-02 01:16 -0500 |
| Message-ID | <g7drratsj493gq4h4f1ll8je8701s8f5cj@4ax.com> |
| In reply to | #66663 |
On Sun, 02 Aug 2015 00:04:41 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:
>Keith Thompson <kst-u@mib.org> writes:
>
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> [...]
>>> If I were writing a C program that needed to include these values,
>>> I expect I would write it something like this:
>>>
>>> enum I808_opcodes {
>>> I8086_AAS = B2( 00111111 ), /* ASCII Adjust for Subtract */
>>> I8086_DAS = B2( 00101111 ), /* Decimal Adjust for Subtract */
>>> /* ... etc ... */
>>> I8086_limit = B2( 11111111 )
>>> };
>>>
>>> where B2() is a macro for producing a constant expressed in
>>> binary.
><snip>
>> I'd be interested in seeing that macro.
>
>Maybe:
>
> #define B2(digits) B(0x##digits)
> #define bit(v, d) (((v) & (1 << 4*(d))) >> 3*(d))
> #define B(h) (bit(h, 0) | bit(h, 1) | bit(h, 2) | bit(h, 3) | \
> bit(h, 4) | bit(h, 5) | bit(h, 6) | bit(h, 7))
>
>though I'm sure there's some nicer bit-twiddling way to go from 0/1 hex
>to binary.
That has limited syntax checking (the input is not checked for actual
binary digits) and range issues (8/16 maximum bits on implementations
with 32/64 bit longs).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-02 12:21 +0100 |
| Message-ID | <87lhdu7x78.fsf@bsb.me.uk> |
| In reply to | #66678 |
Robert Wessel <robertwessel2@yahoo.com> writes:
> On Sun, 02 Aug 2015 00:04:41 +0100, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>
>>Keith Thompson <kst-u@mib.org> writes:
>>
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> [...]
>>>> If I were writing a C program that needed to include these values,
>>>> I expect I would write it something like this:
>>>>
>>>> enum I808_opcodes {
>>>> I8086_AAS = B2( 00111111 ), /* ASCII Adjust for Subtract */
>>>> I8086_DAS = B2( 00101111 ), /* Decimal Adjust for Subtract */
>>>> /* ... etc ... */
>>>> I8086_limit = B2( 11111111 )
>>>> };
>>>>
>>>> where B2() is a macro for producing a constant expressed in
>>>> binary.
>><snip>
>>> I'd be interested in seeing that macro.
>>
>>Maybe:
>>
>> #define B2(digits) B(0x##digits)
>> #define bit(v, d) (((v) & (1 << 4*(d))) >> 3*(d))
>> #define B(h) (bit(h, 0) | bit(h, 1) | bit(h, 2) | bit(h, 3) | \
>> bit(h, 4) | bit(h, 5) | bit(h, 6) | bit(h, 7))
>>
>>though I'm sure there's some nicer bit-twiddling way to go from 0/1 hex
>>to binary.
>
>
> That has limited syntax checking (the input is not checked for actual
> binary digits) and range issues (8/16 maximum bits on implementations
> with 32/64 bit longs).
Yes, it was just a proof of concept. You need a test that h &
0xeeeeeeee is zero, and you need 1l rather than one in the shift. The 8
bit limit was by design -- it was in the spec I think. And if 8 bits
are always specified you don't need 0x##digits##l, but I think I'd do
that anyway.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-02 19:42 +0200 |
| Message-ID | <mplkme$g9p$1@dont-email.me> |
| In reply to | #66678 |
On 02/08/15 08:16, Robert Wessel wrote:
> On Sun, 02 Aug 2015 00:04:41 +0100, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> [...]
>>>> If I were writing a C program that needed to include these values,
>>>> I expect I would write it something like this:
>>>>
>>>> enum I808_opcodes {
>>>> I8086_AAS = B2( 00111111 ), /* ASCII Adjust for Subtract */
>>>> I8086_DAS = B2( 00101111 ), /* Decimal Adjust for Subtract */
>>>> /* ... etc ... */
>>>> I8086_limit = B2( 11111111 )
>>>> };
>>>>
>>>> where B2() is a macro for producing a constant expressed in
>>>> binary.
>> <snip>
>>> I'd be interested in seeing that macro.
>>
>> Maybe:
>>
>> #define B2(digits) B(0x##digits)
>> #define bit(v, d) (((v) & (1 << 4*(d))) >> 3*(d))
>> #define B(h) (bit(h, 0) | bit(h, 1) | bit(h, 2) | bit(h, 3) | \
>> bit(h, 4) | bit(h, 5) | bit(h, 6) | bit(h, 7))
>>
>> though I'm sure there's some nicer bit-twiddling way to go from 0/1 hex
>> to binary.
>
>
> That has limited syntax checking (the input is not checked for actual
> binary digits) and range issues (8/16 maximum bits on implementations
> with 32/64 bit longs).
>
The situation is not unlike the home-made static_assert macros before
_Static_assert was introduced in C11 (and C++11). You could do static
assertions, using messy macros that introduced typedef'ed structs with
arrays of negative sizes when the assertion failed, leading to
compile-time errors. But it is neater, clearer, less error-prone and
gives more useful diagnostics when you use a compiler-supported language
feature for static assertions.
Yes, you can make macros for binary literals. But rather than having
everyone invent their own wheels, with the time and risk involved, or
copy different wheels of differing qualities from random internet
searches, it is much easier to have a single, good, clear and
unambiguous syntax supported by the compiler, and checked with good
diagnostics. There is no need to use "B2" on some code, and perhaps
"B8" on other code (since that's a more common name for an 8-bit binary
literal), and other macros to handle different lengths. There is no
need to worry about the risk of extra run-time code being generated.
You just use a simple standard 0b0110 and get on with the code.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-24 09:58 -0700 |
| Message-ID | <kfny4h0y66f.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66712 |
David Brown <david.brown@hesbynett.no> writes:
> On 02/08/15 08:16, Robert Wessel wrote:
>> On Sun, 02 Aug 2015 00:04:41 +0100, Ben Bacarisse
>> <ben.usenet@bsb.me.uk> wrote:
>>
>>> Keith Thompson <kst-u@mib.org> writes:
>>>
>>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> [...]
>>>>> If I were writing a C program that needed to include these values,
>>>>> I expect I would write it something like this:
>>>>>
>>>>> enum I808_opcodes {
>>>>> I8086_AAS = B2( 00111111 ), /* ASCII Adjust for Subtract */
>>>>> I8086_DAS = B2( 00101111 ), /* Decimal Adjust for Subtract */
>>>>> /* ... etc ... */
>>>>> I8086_limit = B2( 11111111 )
>>>>> };
>>>>>
>>>>> where B2() is a macro for producing a constant expressed in
>>>>> binary.
>>>
>>> <snip>
>>>
>>>> I'd be interested in seeing that macro.
>>>
>>> Maybe:
>>>
>>> #define B2(digits) B(0x##digits)
>>> #define bit(v, d) (((v) & (1 << 4*(d))) >> 3*(d))
>>> #define B(h) (bit(h, 0) | bit(h, 1) | bit(h, 2) | bit(h, 3) | \
>>> bit(h, 4) | bit(h, 5) | bit(h, 6) | bit(h, 7))
>>>
>>> though I'm sure there's some nicer bit-twiddling way to go from 0/1 hex
>>> to binary.
>>
>> That has limited syntax checking (the input is not checked for actual
>> binary digits) and range issues (8/16 maximum bits on implementations
>> with 32/64 bit longs).
>
> The situation is not unlike the home-made static_assert macros before
> _Static_assert was introduced in C11 (and C++11). You could do static
> assertions, using messy macros that introduced typedef'ed structs with
> arrays of negative sizes when the assertion failed, leading to
> compile-time errors. [snip elaboration]
It's not really a good analogy. The macro version of static
assert functionality is a bit kludgey because even when it's
being used correctly it relies on compiler error behavior. The
B2 macro isn't like that - it relies on normal C semantics, not
compiler error behavior. A better analogy is the assert() macro.
Feeding assert() garbage, eg, 'assert(;)', gives garbage output,
ie, probably a compiler error, but if the input is well-formed
then assert() works using well-defined semantcs. The B2() macro
is the same way.
> Yes, you can make macros for binary literals. But rather than having
> everyone invent their own wheels, with the time and risk involved, or
> copy different wheels of differing qualities from random internet
> searches, it is much easier to have a single, good, clear and
> unambiguous syntax supported by the compiler, and checked with good
> diagnostics. There is no need to use "B2" on some code, and perhaps
> "B8" on other code (since that's a more common name for an 8-bit
> binary literal), and other macros to handle different lengths. There
> is no need to worry about the risk of extra run-time code being
> generated. You just use a simple standard 0b0110 and get on with the
> code.
The B2() macro isn't limited to eight bits; there is no reason
to have different names for different widths. As for it being
easier to have binary literals, that sounds like laziness; what
you're saying is it will be easier for you because the work has
been pushed off onto someone else. This seems wrong to me - the
people who are getting the benefit should be the ones who have
to put in the work.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-24 22:22 +0200 |
| Message-ID | <mrfub8$gms$1@dont-email.me> |
| In reply to | #68247 |
On 24/08/15 18:58, Tim Rentsch wrote: > The B2() macro isn't limited to eight bits; there is no reason > to have different names for different widths. As for it being > easier to have binary literals, that sounds like laziness; what > you're saying is it will be easier for you because the work has > been pushed off onto someone else. This seems wrong to me - the > people who are getting the benefit should be the ones who have > to put in the work. > I really thought this discussion was finished long ago. However... Yes, the B2 macro as given is limited to eight bits. You could extend it in some way to cover more, but it would need a change of structure if you don't have support for 64-bit literals (more than 8 hex digits). Since we are concerned with embedded systems, some of which are 8-bit devices, 64-bit values are not necessarily supported. And yes, I am quite happy with the idea of "pushing off the work onto someone else". You might call it "division of labour", or perhaps "using a compiler that someone else made". The alternative is for every programmer to write their own compiler, and I don't think that's a very practical idea. So yes, I would rather that the compiler developers wrote support for 0b01 binary literals which I could use, instead of inventing my own half-baked macro solution that is different from everyone else's half-baked macro solution. And here's the clincher, which you have seem to have forgotten - compiler writers for embedded compilers have already made support for 0b01 binary literals. There is no work left to be done, except for a few outlying embedded compilers (most of which are dying anyway, victims to the success of gcc and clang). Major non-embedded C compilers will also support it sooner or later, because they are almost all C++ compilers as well as C compilers. And as for the evidence of their use that you keep asking for, there are two regulars in this group who work as embedded developers (Ian and myself). We both say we like 0b binary literals, and find them useful - and that our experience with colleagues is that they also use them. It's a small sample, but it's pretty direct. We also have circumstantial evidence - gcc added support for 0b binary literals to the AVR port because users asked for them. gcc developers made the support general across all ports, because AVR users found them useful, and other gcc users were envious. clang and other compilers added 0b literals because people asked for them. C++ added support because people wanted official support for a feature that they were already using as a compiler extension. So 0b binary literals are a useful extension - people want it, people use it. It's a low-cost extension - on many compilers, it is already implemented. It is a far nicer syntax than home-made macro solutions. Clearly it is not an /essential/ feature - people got by without binary literals, using either hex or messy macros. And it might not be suitable for adding to the C standards, especially because it would lead to inconsistencies with the standard library I/O routines (people who use binary literals don't care, but the C standards committee values consistency). But fortunately for embedded developers, binary literals are solidly established in compliers and we can use them when we find them helpful regardless of the C standards.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-08-01 20:20 -0400 |
| Message-ID | <Kndvx.31092$S35.29994@fx30.iad> |
| In reply to | #66649 |
On 8/1/15 4:43 PM, Keith Thompson wrote: > > If you treat the argument as an integer constant, you have to handle > both decimal and octal constants, and B2(0111111) != B2(111111). > > [...] > Not if you token paste a 0 in front, then they are all octal. You also may want to add an UL to the end just to make them all unsigned long so you start with a consistent type (able to handle up to 11 bits, assuming 32 bit longs). If you can count on long long support, the you can get up to 22 bits with ULL.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-02 18:57 -0700 |
| Message-ID | <kfn38019lrn.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66649 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [...]
>> If I were writing a C program that needed to include these values,
>> I expect I would write it something like this:
>>
>> enum I808_opcodes {
>> I8086_AAS = B2( 00111111 ), /* ASCII Adjust for Subtract */
>> I8086_DAS = B2( 00101111 ), /* Decimal Adjust for Subtract */
>> /* ... etc ... */
>> I8086_limit = B2( 11111111 )
>> };
>>
>> where B2() is a macro for producing a constant expressed in
>> binary. Writing this macro took about ten minutes. (The code
>> shown above is actual code, compiling cleanly in C90 and C99 (and
>> presumably C11, although I didn't test that).) IMO this is a
>> better solution than using a new form of integer constant, both
>> because it works now and because it works with older versions
>> of C that don't support binary constants.
>
> I'd be interested in seeing that macro.
Here is simplified version for just eight bits that illustrates
the technique used. (Here I am using a convention where a macro
name with a trailing _ means a "private" macro whose arguments
are understood to have been parenthesized by the caller.)
#define B2( n ) ( (unsigned) B2d_( ( 0##n ) ) )
#define B2d_( n ) ( B2c_( (n / 4096) ) * 16 + B2c_( (n % 4096) ) )
#define B2c_( n ) ( B2b_( (n / 64) ) * 4 + B2b_( (n % 64) ) )
#define B2b_( n ) ( B2a_( (n / 8) ) * 2 + B2a_( (n % 8) ) )
#define B2a_( n ) ( n / (2 > n) )
Generalizing to more than eight bits should be straightforward;
at the high end a little bit of care needs to be taken so as not
to exceed the range of integers that the implementation supports,
and make a suitable choice for the result type, but I think that
is not too difficult for anyone who is used to using the macros
in <limits.h>.
Note the definition of B2a_() verifies that each "bit" value is
either zero or one by dividing by (2 > n), which gives a warning
for division-by-zero when the condition is violated. (Strictly
speaking a warning is not required in contexts where the result
doesn't have to be a constant, but I expect most compilers will
give such a warning in those cases also.)
> I came up with a version that stringifies its argument (requiring
> exactly 8 binary digits), but it doesn't expand to a constant
> expression.
The result of this version is usable as an integer constant
expression.
> If you treat the argument as an integer constant, you have to handle
> both decimal and octal constants, and B2(0111111) != B2(111111).
As you can see this is taken care of by token pasting a leading
zero onto the front (and discovered independently by Richard
Damon), so such cases give the same value. This also gives a
slightly bigger range of constants that are handled correctly.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-08-02 08:21 +1200 |
| Message-ID | <d24o1iF55b9U1@mid.individual.net> |
| In reply to | #66642 |
Tim Rentsch wrote: > Bartc <bc@freeuk.com> writes: > >> That would far more difficult, longer and more costly >> exercise than just adding it! That's why this debate is >> ridiculous. (You don't work in the public sector, by any chance? >> This is the sort of thing they like doing. With other people's >> money.) > > ISTM that you are the one who is willing to spend other > people's time, for a feature that seems to have little value, > just because you want it. My position is that these other > people's time should _not_ be spent, for something that > provides so little value. Something that provides so little value to *you*. C99 set the adding value (and cost of implementation) bar pretty low with the inclusion of the all the maths stuff hardly anyone uses.. The biggest impediment to the take up of C99 was the cost of adding the (to embedded programmers) zero value maths library requirements. For those of us who write drivers and board support code, binary literals do add value. That's why they are such a common extension to embedded compilers. I would be interested to see the results of a poll of C programmers asking "what would you rather have in C, binary literals or <tgmath.h>?" -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-01 14:31 -0700 |
| Message-ID | <lnk2tek85x.fsf@kst-u.example.com> |
| In reply to | #66651 |
Ian Collins <ian-news@hotmail.com> writes:
[...]
> Something that provides so little value to *you*. C99 set the adding
> value (and cost of implementation) bar pretty low with the inclusion of
> the all the maths stuff hardly anyone uses.. The biggest impediment to
> the take up of C99 was the cost of adding the (to embedded programmers)
> zero value maths library requirements.
>
> For those of us who write drivers and board support code, binary
> literals do add value. That's why they are such a common extension to
> embedded compilers.
>
> I would be interested to see the results of a poll of C programmers asking
>
> "what would you rather have in C, binary literals or <tgmath.h>?"
C99 made two major additions to the math library.
One was <tgmath.h>, which never struck me as being all that useful.
(Though it does let you define a floating-point typedef and operate on
it, and change the typedef without having to change all the calls.)
The other was the addition of functions for float and long double. For
example, C90 only had
double sqrt(double);
C99 extended this to;
float sqrtf(float);
double sqrt(double);
long double sqrtl(double);
and likewise for the other floating-point functions.
I don't do a lot of floating-point myself, but the latter strikes me as
a perfectly reasonable change, filling in an arbitrary gap in C90.
(BTW, <tgmath.h> wouldn't have made sense without the float and long
double functions.)
--
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 | Tonton Th <tTh@nowhere.invalid> |
|---|---|
| Date | 2015-08-01 22:26 +0000 |
| Message-ID | <slrnmrqhsb.19o.tTh@hangartistique.cispeo.fr> |
| In reply to | #66651 |
On 2015-08-01, Ian Collins <ian-news@hotmail.com> wrote: > "what would you rather have in C, binary literals or <tgmath.h>?" Binary Literals. -- <<< http://la.buvette.org/photos/myrys/20ans/avance-rapide.avi
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-08-02 01:10 -0500 |
| Message-ID | <51drra5l8kp2okl6m99fpfuppmo5n1g16d@4ax.com> |
| In reply to | #66651 |
On Sun, 02 Aug 2015 08:21:06 +1200, Ian Collins <ian-news@hotmail.com> wrote: >Tim Rentsch wrote: >> Bartc <bc@freeuk.com> writes: >> >>> That would far more difficult, longer and more costly >>> exercise than just adding it! That's why this debate is >>> ridiculous. (You don't work in the public sector, by any chance? >>> This is the sort of thing they like doing. With other people's >>> money.) >> >> ISTM that you are the one who is willing to spend other >> people's time, for a feature that seems to have little value, >> just because you want it. My position is that these other >> people's time should _not_ be spent, for something that >> provides so little value. > >Something that provides so little value to *you*. C99 set the adding >value (and cost of implementation) bar pretty low with the inclusion of >the all the maths stuff hardly anyone uses.. The biggest impediment to >the take up of C99 was the cost of adding the (to embedded programmers) >zero value maths library requirements. > >For those of us who write drivers and board support code, binary >literals do add value. That's why they are such a common extension to >embedded compilers. > >I would be interested to see the results of a poll of C programmers asking > >"what would you rather have in C, binary literals or <tgmath.h>?" Even better: binary literals or hex FP constants? (And yes, I understand hex FP have a purpose).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-02 09:02 -0400 |
| Message-ID | <mpl49o$k76$1@dont-email.me> |
| In reply to | #66677 |
On 08/02/2015 02:10 AM, Robert Wessel wrote: > On Sun, 02 Aug 2015 08:21:06 +1200, Ian Collins <ian-news@hotmail.com> > wrote: ... >> I would be interested to see the results of a poll of C programmers asking >> >> "what would you rather have in C, binary literals or <tgmath.h>?" > > > Even better: binary literals or hex FP constants? (And yes, I > understand hex FP have a purpose). That's easy: Hex FP constants. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-02 14:23 +0100 |
| Message-ID | <mpl5hk$ocu$1@dont-email.me> |
| In reply to | #66688 |
On 02/08/2015 14:02, James Kuyper wrote:
> On 08/02/2015 02:10 AM, Robert Wessel wrote:
>> On Sun, 02 Aug 2015 08:21:06 +1200, Ian Collins <ian-news@hotmail.com>
>> wrote:
> ...
>>> I would be interested to see the results of a poll of C programmers asking
>>>
>>> "what would you rather have in C, binary literals or <tgmath.h>?"
>>
>>
>> Even better: binary literals or hex FP constants? (And yes, I
>> understand hex FP have a purpose).
>
> That's easy: Hex FP constants.
What about binary FP constants?
(I tried this in my non-C language:
print 0B11.101
output when told to translate to C:
printf("%f",3.625);
Which I was surprised at as I can't remember implementing it. However it
needs some attention as 0B11.101e100 doesn't work. It's also not that
clear whether the exponent should be a power of 10, or of 2.
Binary FP output is not available as that uses C's sprintf, which
doesn't support it.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-02 15:31 -0700 |
| Message-ID | <lnwpxdiapy.fsf@kst-u.example.com> |
| In reply to | #66693 |
Bartc <bc@freeuk.com> writes:
[...]
> What about binary FP constants?
>
> (I tried this in my non-C language:
>
> print 0B11.101
>
> output when told to translate to C:
>
> printf("%f",3.625);
>
> Which I was surprised at as I can't remember implementing it. However it
> needs some attention as 0B11.101e100 doesn't work. It's also not that
> clear whether the exponent should be a power of 10, or of 2.
>
> Binary FP output is not available as that uses C's sprintf, which
> doesn't support it.)
C already has hexadecimal floating-point constants, using 'P' rather
than 'E' to mark the exponent (since 'E' is a valid hexadecimal digit).
The exponent represents a power of 2.
*If* binary FP constants were to be added to C, they should be just like
hexadecimal FP constants but with a "0b" prefix rather than "0x". Thus
0b1.1p3 == 12.0.
I don't suggest that binary FP constants (or I/O) would be worthwhile.
Non-decimal floating-point is not as human-readable as non-decimal
integers, and hexadecimal already serves the purpose of capturing the
exact value (for systems where FLT_RADIX is a power of 2).
(Incidentally, Ada supports numeric constants and I/O using all bases
from 2 to 16.)
--
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-08-02 09:01 -0700 |
| Message-ID | <kfn8u9tadcp.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66651 |
Ian Collins <ian-news@hotmail.com> writes: > Tim Rentsch wrote: >> Bartc <bc@freeuk.com> writes: >> >>> That would far more difficult, longer and more costly >>> exercise than just adding it! That's why this debate is >>> ridiculous. (You don't work in the public sector, by any chance? >>> This is the sort of thing they like doing. With other people's >>> money.) >> >> ISTM that you are the one who is willing to spend other >> people's time, for a feature that seems to have little value, >> just because you want it. My position is that these other >> people's time should _not_ be spent, for something that >> provides so little value. > > Something that provides so little value to *you*. Personally I think I would not be inclined to use binary constants under most circumstances, however that isn't what I was talking about. My assertion is that binary constants don't provide much value to people who would generally use them if they were available, because the density of use is low, and because there are alternatives available with roughly the same productivity measures. > C99 set the > adding value (and cost of implementation) bar pretty low with the > inclusion of the all the maths stuff hardly anyone uses.. The > biggest impediment to the take up of C99 was the cost of adding > the (to embedded programmers) zero value maths library > requirements. Are you suggesting that WG14 didn't go through their normal vetting process for the additional math functions and <tgmath.h> addition to C99? That seems very unlikely to me. In any case there is a big difference between that math functionality and binary constants, namely, the math functions offer capabilities which are essentially unavailable if those functions weren't there, whereas binary constants may be somewhat more convenient but don't really provide any new capability. That is an enormous difference. > For those of us who write drivers and board support code, binary > literals do add value. That's why they are such a common > extension to embedded compilers. I'm not disputing that they add value - the question is how much, and what is the value on the other side of the scale. It isn't useful to treat "value added" as a boolean. > I would be interested to see the results of a poll of C > programmers asking > > "what would you rather have in C, binary literals or <tgmath.h>?" Fortunately some people have the sense to rely on better metrics.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-02 16:56 -0700 |
| Message-ID | <lnfv41i6rf.fsf@kst-u.example.com> |
| In reply to | #66703 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> Are you suggesting that WG14 didn't go through their normal
> vetting process for the additional math functions and <tgmath.h>
> addition to C99? That seems very unlikely to me. In any case
> there is a big difference between that math functionality and
> binary constants, namely, the math functions offer capabilities
> which are essentially unavailable if those functions weren't
> there, whereas binary constants may be somewhat more convenient
> but don't really provide any new capability. That is an enormous
> difference.
Perhaps <tgmath.h> is a bigger deal than I'm aware of, but it
seems to me that it provides some added convenience but no real
new functionality. Likewise sqrtf() and other float functions
(which can be emulated by converting the argument from double to
float and the result from float to double). sqrtd() and friends
do provide functionality that didn't exist in C90, at least for
implementations where long double is bigger than double.
--
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-08-03 10:18 -0700 |
| Message-ID | <kfnh9og8f56.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66759 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: > [...] >> Are you suggesting that WG14 didn't go through their normal >> vetting process for the additional math functions and <tgmath.h> >> addition to C99? That seems very unlikely to me. In any case >> there is a big difference between that math functionality and >> binary constants, namely, the math functions offer capabilities >> which are essentially unavailable if those functions weren't >> there, whereas binary constants may be somewhat more convenient >> but don't really provide any new capability. That is an enormous >> difference. > > Perhaps <tgmath.h> is a bigger deal than I'm aware of, but it > seems to me that it provides some added convenience but no real > new functionality. What <tgmath.h> provides is a limited form of overloading (and only for certain math functions). You could say that <tgmath.h> provides no new functionality in the same sense that 'sizeof (Expression)' provides no new functionality over 'sizeof (type-name)'. In principle, it is possible to track down the type of the expression involved, and put that type in as the operand of sizeof. In practice, doing that is laborious and error-prone, because the information involved is somewhere else, and subject to independent change. There's a good reason why people are advised to use 'malloc( 10 * sizeof *p )' rather than 'malloc( 10 * sizeof (int) )'. The macros in <tgmath.h> provide a similar kind of situation with regard to use of certain math.h functions.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-08-03 12:10 +1200 |
| Message-ID | <d27prdF55b9U5@mid.individual.net> |
| In reply to | #66703 |
Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> Tim Rentsch wrote: >>> Bartc <bc@freeuk.com> writes: >>> >>>> That would far more difficult, longer and more costly >>>> exercise than just adding it! That's why this debate is >>>> ridiculous. (You don't work in the public sector, by any chance? >>>> This is the sort of thing they like doing. With other people's >>>> money.) >>> >>> ISTM that you are the one who is willing to spend other >>> people's time, for a feature that seems to have little value, >>> just because you want it. My position is that these other >>> people's time should _not_ be spent, for something that >>> provides so little value. >> >> Something that provides so little value to *you*. > > Personally I think I would not be inclined to use binary > constants under most circumstances, however that isn't what I was > talking about. My assertion is that binary constants don't > provide much value to people who would generally use them if they > were available, because the density of use is low, and because > there are alternatives available with roughly the same > productivity measures. I don't think you are in a position to tell us embedded developers what value a feature we both want and use (by way of extensions) provides. >> C99 set the >> adding value (and cost of implementation) bar pretty low with the >> inclusion of the all the maths stuff hardly anyone uses.. The >> biggest impediment to the take up of C99 was the cost of adding >> the (to embedded programmers) zero value maths library >> requirements. > > Are you suggesting that WG14 didn't go through their normal > vetting process for the additional math functions and <tgmath.h> > addition to C99? No, I'm suggesting there was no problem adding features that were of little use to the majority of C programmers (I'm willing to stick my neck out and say that kernel and embedded programmers are the current majority). I'm also suggesting these changes went a long way to preventing C99 gaining wide acceptance. >> For those of us who write drivers and board support code, binary >> literals do add value. That's why they are such a common >> extension to embedded compilers. > > I'm not disputing that they add value - the question is how much, > and what is the value on the other side of the scale. It isn't > useful to treat "value added" as a boolean. A lot more than other C99 features, notably those that are now optional. >> I would be interested to see the results of a poll of C >> programmers asking >> >> "what would you rather have in C, binary literals or <tgmath.h>?" > > Fortunately some people have the sense to rely on better metrics. Such as add what he who shouts loudest wants rather than everyday programmers? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-24 10:52 -0700 |
| Message-ID | <kfntwroy3pa.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66761 |
Ian Collins <ian-news@hotmail.com> writes: > Tim Rentsch wrote: >> Ian Collins <ian-news@hotmail.com> writes: >> >>> Tim Rentsch wrote: >>>> Bartc <bc@freeuk.com> writes: >>>> >>>>> That would far more difficult, longer and more costly >>>>> exercise than just adding it! That's why this debate is >>>>> ridiculous. (You don't work in the public sector, by any chance? >>>>> This is the sort of thing they like doing. With other people's >>>>> money.) >>>> >>>> ISTM that you are the one who is willing to spend other >>>> people's time, for a feature that seems to have little value, >>>> just because you want it. My position is that these other >>>> people's time should _not_ be spent, for something that >>>> provides so little value. >>> >>> Something that provides so little value to *you*. >> >> Personally I think I would not be inclined to use binary >> constants under most circumstances, however that isn't what I was >> talking about. My assertion is that binary constants don't >> provide much value to people who would generally use them if they >> were available, because the density of use is low, and because >> there are alternatives available with roughly the same >> productivity measures. > > I don't think you are in a position to tell us embedded developers > what value a feature we both want and use (by way of extensions) > provides. I'm happy to be convinced otherwise if presented with suitable facts and objective evidence. So far though all I've gotten is opinion. >>> C99 set the >>> adding value (and cost of implementation) bar pretty low with the >>> inclusion of the all the maths stuff hardly anyone uses.. The >>> biggest impediment to the take up of C99 was the cost of adding >>> the (to embedded programmers) zero value maths library >>> requirements. >> >> Are you suggesting that WG14 didn't go through their normal >> vetting process for the additional math functions and <tgmath.h> >> addition to C99? > > No, I'm suggesting there was no problem adding features that were > of little use to the majority of C programmers (I'm willing to > stick my neck out and say that kernel and embedded programmers are > the current majority). There are various assumptions in there, let me point out a few. One is that every developer who is a kernel or embedded developer is affected. I doubt that is true. A more significant assumption is that the relevant metric is simply how many developers are affected. That's not really a good metric. One obviously better metric is number of developers affected times the utility gained (or a weighted sum of productivity gained over each affected developer). Under this metric I think the argument shifts in favor of <tgmath.h>, since the productivity gained by having binary literals is so low, as there are other means of achieving the same result. > I'm also suggesting these changes went a long way to > preventing C99 gaining wide acceptance. Really? You think <tgmath.h>, and other math functions, account for the slow uptake of C99? I see no reason to think that's true in the absence of any sort of corroborating evidence. >>> For those of us who write drivers and board support code, binary >>> literals do add value. That's why they are such a common >>> extension to embedded compilers. >> >> I'm not disputing that they add value - the question is how much, >> and what is the value on the other side of the scale. It isn't >> useful to treat "value added" as a boolean. > > A lot more than other C99 features, notably those that are now > optional. Reviewing 6.10.8.3, I believe there are two such features: complex numbers and variable length arrays. IMO it is highly unlikely that binary constants offer more benefit than either of these. Do you have anything to offer besides your opinion that it's more? >>> I would be interested to see the results of a poll of C >>> programmers asking >>> >>> "what would you rather have in C, binary literals or <tgmath.h>?" >> >> Fortunately some people have the sense to rely on better metrics. > > Such as add what he who shouts loudest wants rather than everyday > programmers? ISTM that the people who have been "shouting" have been (some of) those who want binary constants. But in any case what I had in mind is some sort of quantitative measure for what the weighted value add would be, not just how many people think they want something. IME most programmers don't have a good sense of what's important for programming language features, in terms of objective results for what affects productivity and reliability. So I don't think much weight should be given just to whether someone thinks they want something. Is it really asking too much for someone to provide some sort of objective evidence that the proposed feature will yield non-negligible value?
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-24 20:01 +0100 |
| Message-ID | <mrfpjp$s6u$1@dont-email.me> |
| In reply to | #68248 |
On 24/08/2015 18:52, Tim Rentsch wrote: IME most programmers don't have a good sense of > what's important for programming language features, in terms of > objective results for what affects productivity and reliability. > So I don't think much weight should be given just to whether > someone thinks they want something. For most programming I had to do in my job, I had to create the tools needed including throwing together a language and a compiler. It seems now that I wasn't the right person to know what I needed in my own language! Actually, since the hardware was limited and the tools had to be kept small, and my time was limited because I had other duties, it is doubtful I would have wasted effort on unnecessary or non-viable features. (I can't remember if I had binary constants, but considering most of my coding was very low-level, and I also wrote assemblers, then it was extremely likely.) -- bartc
[toc] | [prev] | [next] | [standalone]
Page 13 of 22 — ← Prev page 1 … 11 12 [13] 14 15 … 22 Next page →
Back to top | Article view | comp.lang.c
csiph-web