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 8 of 22 — ← Prev page 1 … 6 7 [8] 9 10 … 22 Next page →
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-22 23:38 +0100 |
| Message-ID | <mjob33$jh5$1@dont-email.me> |
| In reply to | #62468 |
On 22/05/2015 21:56, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: >> What I'm doing is providing an orthogonal set of different styles, you >> just choose the column you like: >> int:32 int*4 int32 i32 int >> But remember you will only choose from the first four columns when an >> exact-width type is needed. Mostly names from the last column will be >> used. > > As I said, it's your language. I just don't see any benefit, and some > cost in potential confusion, from permitting both int:32 and int*4 with > exactly the same meaning. Sometimes you put in a bunch of features, some of which get used, and others don't, after which they are quietly dropped. In this case they will probably stay in but not be used (I don't use them any more), other than to underpin designations such as int32 and i32. > (An I correct in assuming that your language, > unlike C, assumes 8-bit bytes?) I guess so. I think so do C# and Java, and doubtless many others (including the Fortran version that 'integer*4' etc came from). Perhaps a fork of C could do the same and maybe benefit from not beating around the bush about what exactly a byte is. It is very refreshing seeing a language reference list the primitive types together with the exact widths of each. (My first compiler project was on the 'pdp-10' 36-bit machine which didn't really have bytes, but that was a long time ago and such systems are pretty much dead (I hope).) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-05-22 18:28 -0500 |
| Message-ID | <ejevladml0ep58beoapn0sn3fog7pt4nnv@4ax.com> |
| In reply to | #62441 |
On Fri, 22 May 2015 14:16:37 +0100, Bartc <bc@freeuk.com> wrote: >On 21/05/2015 22:33, Keith Thompson wrote: >> bart4858@gmail.com writes: > >>> (Actually, this is a list I wrote up some time ago, of 90-odd >>> features of my own C-class language which I considered >>> improvements from their C equivalents or omissions: >>> >>> http://pastebin.com/9ZdmGd68 > >> Interesting. I like quite a few of these features. > >Thanks. > >> A few comments: >> >> 5 Binary literals can be written as 2x1101 or 1101B (C will have >> this soon) >> >> I haven't heard of any proposals to add binary integer constants >> to C; have you? C++ has added them with the syntax `0b1101` or >> `0B1101`. I'd like to see C adopt this. >> >> 6 Octal literals written ax 8x377 not 0377 >> >> If hexadecimal literals are still written as 0xFFFF, I can imagine >> that "8x" and "0x" might be a little difficult to distinguish. If you >> drop C's "0x" syntax and just use "16x", that wouldn't be an issue. > >Octal constants are rare enough that you might be right that at first >glance, it can be mistaken for 0x. But I think that C's leading zero >syntax is going to be worse for catching people out. > >Maybe octals can be highlighted with separators: 8x_377 or 8x'377' for >example. > >16x is a possibility, but 0x is near universal for hex. (I used to use a >H suffix but switched to 0x.) 0x is certainly common for hex, but is far from universal. Consider the list of methods in: https://en.wikipedia.org/wiki/Hexadecimal But I've always figured for C adding 0b and 0o for binary and octal would be a good idea. I'd also depreciate the leading-zero-only form of octal, although I have to assume someone is actually using that. In my personal experience that's never been anything but the inadvertent introduction of a bug.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-22 16:44 -0700 |
| Message-ID | <87egm8qis7.fsf@kst-u.example.com> |
| In reply to | #62474 |
Robert Wessel <robertwessel2@yahoo.com> writes:
[...]
> 0x is certainly common for hex, but is far from universal. Consider
> the list of methods in:
>
> https://en.wikipedia.org/wiki/Hexadecimal
>
> But I've always figured for C adding 0b and 0o for binary and octal
> would be a good idea. I'd also depreciate the leading-zero-only form
> of octal, although I have to assume someone is actually using that. In
> my personal experience that's never been anything but the inadvertent
> introduction of a bug.
You've used octal constants, unless you've managed to avoid using the
constant 0. Of course if the current leading-zero notation were
dropped, the grammar would be changed to make 0 a decimal constant. (Or
it could be base 42; that would work too.)
Octal is commonly used for the mode argument to the POSIX chmod() and
open() functions. Permissions are encoded in binary in groups of 3, so
for example 0750 means read/write/execute for owner, read/execute for
group, and no permissions for others. Such code would have to be
changed to use the new notation.
I'm not sure "0o" is the best choice, unless it's restricted to lower
case; 0O750 is too difficult to read. Perhaps 0C, reminiscent of the
first two letters of "octal"?
--
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-05-24 07:44 -0700 |
| Message-ID | <kfnvbfi6nnp.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #62476 |
Keith Thompson <kst-u@mib.org> writes: > Robert Wessel <robertwessel2@yahoo.com> writes: > [...] >> 0x is certainly common for hex, but is far from universal. Consider >> the list of methods in: >> >> https://en.wikipedia.org/wiki/Hexadecimal >> >> But I've always figured for C adding 0b and 0o for binary and octal >> would be a good idea. I'd also depreciate the leading-zero-only form >> of octal, although I have to assume someone is actually using that. In >> my personal experience that's never been anything but the inadvertent >> introduction of a bug. > > You've used octal constants, unless you've managed to avoid using the > constant 0. Of course if the current leading-zero notation were > dropped, the grammar would be changed to make 0 a decimal constant. (Or > it could be base 42; that would work too.) > > Octal is commonly used for the mode argument to the POSIX chmod() and > open() functions. Permissions are encoded in binary in groups of 3, so > for example 0750 means read/write/execute for owner, read/execute for > group, and no permissions for others. Such code would have to be > changed to use the new notation. > > I'm not sure "0o" is the best choice, unless it's restricted to lower > case; 0O750 is too difficult to read. Perhaps 0C, reminiscent of the > first two letters of "octal"? 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). The current notation for octal is a bit surprising if you're not used to it, but it isn't that bad either. I agree that octal constants offer an opportunity for program flaws, but they are easily found with a simple grep command. Note also that extending constant literals with new base formats will probably also mean adding stuff in library functions, for example strtol(). The current scheme isn't ideal but I can live with it, as I am sure can most others. There are more important things to worry about. Also, note that the matter of expressing literals in different bases is less of an issue in C++, by virtue of constexpr. To my way of thinking that reduces the incentive to make changes to how C handles them.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-24 16:52 +0100 |
| Message-ID | <mjss27$qjf$1@dont-email.me> |
| In reply to | #62526 |
On 24/05/2015 15: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).
Are you suggesting that binary constants are /never/ useful? This is
such a trivially implemented enhancement that you can afford to just
throw it in, and let people use it if they want.
Obviously nobody is suggesting switching from decimal, or hex, to binary
just for the hell of it. Binary will be used for a reason.
Here are some cases where I've used binary constants (most not in C):
(1) As a map. Here, a '1' bit in the last element marks an optional item
in the preceding list of eight:
(ki,ki, 0, 0, 0, 0, 0, 0, 01000000B),
The position of the '1' corresponds exactly to the position item in
the list.
(2) To mask the Nth bit. For one-off masking, specifying the mask in
binary is less error-prone than doing so in hex. It will also be more
obvious that you are masking a single bit, but if masking several, then
the pattern will be far clearer.
(3) To define patterns. So if I had dotted line pattern marked by 1
pixel on ('1') and 2 off, then 3 on and 2 off, then repeating, I might
denote it as the following in a 16-bit cycle:
100_11100_100_11100B
(4) Defining a set of masks:
const attr1 = 0000_0001B
const attr2 = 0000_0010B
const attr3 = 0000_0100B
Binary makes it easy to keep track of where you are. And also see which
might occupy two consecutive bits, or to see how they would interact
when combined with & and |.
(5) Defining data which is grouped by bitfields:
const fadd_op = 01_010_111B # some made-up x87 op
(6) Defining small images, this is more efficient if you can use 1 bit
per pixel but this needs binary:
00000b,
11110b,
10001b,
10001b,
11110b,
10001b,
10001b,
11110b
Etc. The advantage of binary is that it lets you visualise the data when
there's a certain pattern or grouping involved. (It would need
separators too.)
Or, you maybe you are right and this would all be just as easy in
decimal or hex. (When it's come up before, someone devised a macro which
interpreted its parameter as a binary string. But if someone goes to
that much trouble, it means it could do with being in the language.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-05-24 22:19 +0100 |
| Message-ID | <87a8wteks0.fsf@bsb.me.uk> |
| In reply to | #62531 |
Bartc <bc@freeuk.com> writes:
> On 24/05/2015 15: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).
>
> Are you suggesting that binary constants are /never/ useful? This is
> such a trivially implemented enhancement that you can afford to just
> throw it in, and let people use it if they want.
>
> Obviously nobody is suggesting switching from decimal, or hex, to
> binary just for the hell of it. Binary will be used for a reason.
>
> Here are some cases where I've used binary constants (most not in C):
>
> (1) As a map. Here, a '1' bit in the last element marks an optional
> item in the preceding list of eight:
>
> (ki,ki, 0, 0, 0, 0, 0, 0, 01000000B),
>
> The position of the '1' corresponds exactly to the position item in
> the list.
I don't know exactly what you are doing here but if the "eight" is
important why is (ki,ki, 0, 0, 0, 0, 0, 0, 1 << 8) not clearer?
> (2) To mask the Nth bit. For one-off masking, specifying the mask in
> binary is less error-prone than doing so in hex. It will also be more
> obvious that you are masking a single bit,
Surely 1 << N is even less error prone and needs no counting of zeros.
> but if masking several,
> then the pattern will be far clearer.
Maybe. It depends on the pattern and the logic by which is is defined.
An example (with context) would help.
> (3) To define patterns. So if I had dotted line pattern marked by 1
> pixel on ('1') and 2 off, then 3 on and 2 off, then repeating, I might
> denote it as the following in a 16-bit cycle:
>
> 100_11100_100_11100B
Yes, I've used them for this and it's often the clearest notation but
see below in number 6 for a C option.
> (4) Defining a set of masks:
>
> const attr1 = 0000_0001B
> const attr2 = 0000_0010B
> const attr3 = 0000_0100B
Surely
const attr1 = 1 << 0;
const attr2 = 1 << 1;
const attr3 = 1 << 2;
makes the pattern clearer and simpler to check. You could even use an
array or list comprehension (e.g. let attrs = [bit n | n <- [0..6]]).
> Binary makes it easy to keep track of where you are. And also see
> which might occupy two consecutive bits, or to see how they would
> interact when combined with & and |.
All but the last are made simpler using 1 << n, and I'm not sure the
last is really a strong point.
> (5) Defining data which is grouped by bitfields:
>
> const fadd_op = 01_010_111B # some made-up x87 op
Maybe for a couple of once-off cases, but as soon as I have more than
two I'd want to have, say, a macro to build the result from nicely named
parts. Depending on the context, binary constants might help for some
parts:
const fadd_op = FLAGS(1) | ADDR_MODE(010B) | OP_CODE(7);
> (6) Defining small images, this is more efficient if you can use 1 bit
> per pixel but this needs binary:
>
> 00000b,
> 11110b,
> 10001b,
> 10001b,
> 11110b,
> 10001b,
> 10001b,
> 11110b
>
> Etc. The advantage of binary is that it lets you visualise the data
> when there's a certain pattern or grouping involved. (It would need
> separators too.)
Like a linear pattern (number 3) this is one I've used too, but even in
C you can do some messing about in macros to get patterns that stand out
quite strongly:
const unsigned image[] = {
B(X___,___X)
B(_X__,__X_)
B(__X_,_X__)
B(___X,X___)
B(___X,X___)
B(__X_,_X__)
B(_X__,__X_)
B(X___,___X)
};
using these definitions:
#define PAT_____ 0
#define PAT____X 1
#define PAT___X_ 2
#define PAT___XX 3
#define PAT__X__ 4
#define PAT__X_X 5
#define PAT__XX_ 6
#define PAT__XXX 7
#define PAT_X___ 8
#define PAT_X__X 9
#define PAT_X_X_ a
#define PAT_X_XX b
#define PAT_XX__ c
#define PAT_XX_X d
#define PAT_XXX_ e
#define PAT_XXXX f
#define B(a, b) BX(PAT_ ## a, PAT_ ## b)
#define BX(a, b) BXX(a, b)
#define BXX(a, b) 0x ## a ## b,
I agree that the very low cost to implement binary literals should be
taken into account. Even a few uses makes it a net gain, but it almost
certainly needs a digit separator as well.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-24 22:28 +0100 |
| Message-ID | <mjtfoi$6ag$1@dont-email.me> |
| In reply to | #62550 |
On 24/05/15 22:19, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
>
<snip>
>>
>> The advantage of binary is that it lets you visualise the data
>> when there's a certain pattern or grouping involved. (It would need
>> separators too.)
>
> Like a linear pattern (number 3) this is one I've used too, but even in
> C you can do some messing about in macros to get patterns that stand out
> quite strongly:
>
> const unsigned image[] = {
> B(X___,___X)
> B(_X__,__X_)
> B(__X_,_X__)
> B(___X,X___)
> B(___X,X___)
> B(__X_,_X__)
> B(_X__,__X_)
> B(X___,___X)
> };
>
> using these definitions:
>
> #define PAT_____ 0
> #define PAT____X 1
> #define PAT___X_ 2
> #define PAT___XX 3
> #define PAT__X__ 4
> #define PAT__X_X 5
> #define PAT__XX_ 6
> #define PAT__XXX 7
> #define PAT_X___ 8
> #define PAT_X__X 9
> #define PAT_X_X_ a
> #define PAT_X_XX b
> #define PAT_XX__ c
> #define PAT_XX_X d
> #define PAT_XXX_ e
> #define PAT_XXXX f
>
> #define B(a, b) BX(PAT_ ## a, PAT_ ## b)
> #define BX(a, b) BXX(a, b)
> #define BXX(a, b) 0x ## a ## b,
>
> I agree that the very low cost to implement binary literals should be
> taken into account. Even a few uses makes it a net gain, but it almost
> certainly needs a digit separator as well.
>
> <snip>
>
#define l )*2+1
#define O )*2
#define binary ((((((((((((((((0
/* add 16 more (s for 32 bit quantities */
Usage:
a = binary O O O O O O O O O O O O O O O O ; /* 0 */
b = binary O O O O O O O O O O O O O O O l ; /* 1 */
c = binary O O O O O O O O O O O O O O l O ; /* 2 */
d = binary O O O O O O O O O O O O O O l l ; /* 3 */
etc.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-05-25 00:00 +0100 |
| Message-ID | <87oal9d1is.fsf@bsb.me.uk> |
| In reply to | #62551 |
Richard Heathfield <rjh@cpax.org.uk> writes: <snip> > #define l )*2+1 > #define O )*2 > #define binary ((((((((((((((((0 > /* add 16 more (s for 32 bit quantities */ > > Usage: > > a = binary O O O O O O O O O O O O O O O O ; /* 0 */ > b = binary O O O O O O O O O O O O O O O l ; /* 1 */ > c = binary O O O O O O O O O O O O O O l O ; /* 2 */ > d = binary O O O O O O O O O O O O O O l l ; /* 3 */ > > etc. That's nice. (I'd want to #undef O and l right after -- just to be on the safe side.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-10 10:12 -0700 |
| Message-ID | <kfnk2u8543h.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #62551 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 24/05/15 22:19, Ben Bacarisse wrote:
>> Bartc <bc@freeuk.com> writes:
>
> <snip>
>
>>> The advantage of binary is that it lets you visualise the data
>>> when there's a certain pattern or grouping involved. (It would need
>>> separators too.)
>>
>> Like a linear pattern (number 3) this is one I've used too, but even in
>> C you can do some messing about in macros to get patterns that stand out
>> quite strongly:
>>
>> const unsigned image[] = {
>> B(X___,___X)
>> B(_X__,__X_)
>> B(__X_,_X__)
>> B(___X,X___)
>> B(___X,X___)
>> B(__X_,_X__)
>> B(_X__,__X_)
>> B(X___,___X)
>> };
>>
>> using these definitions:
>>
>> #define PAT_____ 0
>> #define PAT____X 1
>> #define PAT___X_ 2
>> #define PAT___XX 3
>> #define PAT__X__ 4
>> #define PAT__X_X 5
>> #define PAT__XX_ 6
>> #define PAT__XXX 7
>> #define PAT_X___ 8
>> #define PAT_X__X 9
>> #define PAT_X_X_ a
>> #define PAT_X_XX b
>> #define PAT_XX__ c
>> #define PAT_XX_X d
>> #define PAT_XXX_ e
>> #define PAT_XXXX f
>>
>> #define B(a, b) BX(PAT_ ## a, PAT_ ## b)
>> #define BX(a, b) BXX(a, b)
>> #define BXX(a, b) 0x ## a ## b,
>>
>> I agree that the very low cost to implement binary literals should be
>> taken into account. Even a few uses makes it a net gain, but it almost
>> certainly needs a digit separator as well.
>>
>> <snip>
>
> #define l )*2+1
> #define O )*2
> #define binary ((((((((((((((((0
> /* add 16 more (s for 32 bit quantities */
>
> Usage:
>
> a = binary O O O O O O O O O O O O O O O O ; /* 0 */
> b = binary O O O O O O O O O O O O O O O l ; /* 1 */
> c = binary O O O O O O O O O O O O O O l O ; /* 2 */
> d = binary O O O O O O O O O O O O O O l l ; /* 3 */
Clever. Thank you for posting this.
I might suggest an (untested) improvement:
#define l *2+1)
#define O *2)
#define binary ((((((((((((((((0U
This should be somewhat safer, especially in implementations
that have 16-bit ints.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-24 23:13 +0100 |
| Message-ID | <mjtici$iai$1@dont-email.me> |
| In reply to | #62550 |
On 24/05/2015 22:19, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
>> (1) As a map. Here, a '1' bit in the last element marks an optional
>> item in the preceding list of eight:
>>
>> (ki,ki, 0, 0, 0, 0, 0, 0, 01000000B),
>>
>> The position of the '1' corresponds exactly to the position item in
>> the list.
>
> I don't know exactly what you are doing here but if the "eight" is
> important why is (ki,ki, 0, 0, 0, 0, 0, 0, 1 << 8) not clearer?
It might be clearer with a slightly different example written like this:
(ki,ki,kr,ki, 0, 0, 0, 0,
0__1__1__0__0__0__0__0_B)
Each bit is a flag for the corresponding item above. This way it's easy
to see at a glance which item is marked, and maintenance is simpler.
Probably the separators are not really needed with only eight items:
0110_0000B would have done; the original didn't use them.
(A series of int values would have worked also, but in the original
context, a single int had to contain the bit flags.)
>> (4) Defining a set of masks:
>>
>> const attr1 = 0000_0001B
>> const attr2 = 0000_0010B
>> const attr3 = 0000_0100B
>
> Surely
>
> const attr1 = 1 << 0;
> const attr2 = 1 << 1;
> const attr3 = 1 << 2;
>
> makes the pattern clearer and simpler to check. You could even use an
> array or list comprehension (e.g. let attrs = [bit n | n <- [0..6]]).
Maybe, but sometimes just laying out all the bits can be clearer than
using a formula. For the same reasons that tabulating numbers in aligned
columns can make it easier to compare or to take in data.
For example, I'd imagine that this:
const rmask = 0x00_00_FF
const gmask = 0x00_FF_00
const bmask = 0xFF_00_00
is a little easier to grasp than:
const rmask = 0xFF << 0
const gmask = 0xFF << 8
const bmask = 0xFF << 16
>> (6) Defining small images, this is more efficient if you can use 1 bit
>> per pixel but this needs binary:
>>
>> 00000b,
>> 11110b,
>> 10001b,
>> Etc. The advantage of binary is that it lets you visualise the data
>> when there's a certain pattern or grouping involved. (It would need
>> separators too.)
>
> Like a linear pattern (number 3) this is one I've used too, but even in
> C you can do some messing about in macros to get patterns that stand out
> quite strongly:
>
> const unsigned image[] = {
> B(X___,___X)
> B(_X__,__X_)
> B(__X_,_X__)
> B(___X,X___)
> B(___X,X___)
> B(__X_,_X__)
> B(_X__,__X_)
> B(X___,___X)
> };
>
> using these definitions:
>
> #define PAT_____ 0
> #define PAT____X 1
....
> I agree that the very low cost to implement binary literals should be
> taken into account. Even a few uses makes it a net gain, but it almost
> certainly needs a digit separator as well.
Yes there are lots of ways to do some of this stuff, but it sometimes
need some ingenuity. And obviously C has managed without it up to now.
But I think if binary constants had been available, they would be used
for a lot of it. Tim however was saying he couldn't see any uses for
them at all.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-25 11:30 +0100 |
| Message-ID | <mjuthf$a7o$1@dont-email.me> |
| In reply to | #62550 |
On 24/05/2015 22:19, Ben Bacarisse wrote: > Bartc <bc@freeuk.com> writes: >> (5) Defining data which is grouped by bitfields: >> >> const fadd_op = 01_010_111B # some made-up x87 op > > Maybe for a couple of once-off cases, but as soon as I have more than > two I'd want to have, say, a macro to build the result from nicely named > parts. Depending on the context, binary constants might help for some > parts: > > const fadd_op = FLAGS(1) | ADDR_MODE(010B) | OP_CODE(7); This is the actual set of examples that I couldn't find yesterday: http://pastebin.com/GiWaTEu1 The binary form keeps it compact. (Note that the original 22-page Intel datasheets for the 8087 (among other chips) use binary in the instruction set details. Then it's useful that the source forms matches that format. Although I can't remember how the above example originated.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-05-25 07:41 -0700 |
| Message-ID | <95ba9277-f547-46a1-9ab2-160759731130@googlegroups.com> |
| In reply to | #62550 |
On Monday, 25 May 2015 00:19:20 UTC+3, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
>
> > Etc. The advantage of binary is that it lets you visualise the data
> > when there's a certain pattern or grouping involved. (It would need
> > separators too.)
>
> Like a linear pattern (number 3) this is one I've used too, but even in
> C you can do some messing about in macros to get patterns that stand out
> quite strongly:
>
> const unsigned image[] = {
> B(X___,___X)
> B(_X__,__X_)
> B(__X_,_X__)
> B(___X,X___)
> B(___X,X___)
> B(__X_,_X__)
> B(_X__,__X_)
> B(X___,___X)
> };
>
> using these definitions:
>
> #define PAT_____ 0
> #define PAT____X 1
> #define PAT___X_ 2
> #define PAT___XX 3
> #define PAT__X__ 4
> #define PAT__X_X 5
> #define PAT__XX_ 6
> #define PAT__XXX 7
> #define PAT_X___ 8
> #define PAT_X__X 9
> #define PAT_X_X_ a
> #define PAT_X_XX b
> #define PAT_XX__ c
> #define PAT_XX_X d
> #define PAT_XXX_ e
> #define PAT_XXXX f
>
> #define B(a, b) BX(PAT_ ## a, PAT_ ## b)
> #define BX(a, b) BXX(a, b)
> #define BXX(a, b) 0x ## a ## b,
>
> I agree that the very low cost to implement binary literals should be
> taken into account. Even a few uses makes it a net gain, but it almost
> certainly needs a digit separator as well.
Neat trick of self constructing binary literals.
Can some pedant reject usage of those 'PAT__XX_' on review as usage
of reserved names?
Can perhaps fall back to usage of 'oXXo' or the like on such case but
'_XX_' looks better.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-05-25 17:10 +0100 |
| Message-ID | <87r3q4bpu8.fsf@bsb.me.uk> |
| In reply to | #62596 |
Öö Tiib <ootiib@hot.ee> writes:
> On Monday, 25 May 2015 00:19:20 UTC+3, Ben Bacarisse wrote:
>> Bartc <bc@freeuk.com> writes:
>>
>> > Etc. The advantage of binary is that it lets you visualise the data
>> > when there's a certain pattern or grouping involved. (It would need
>> > separators too.)
>>
>> Like a linear pattern (number 3) this is one I've used too, but even in
>> C you can do some messing about in macros to get patterns that stand out
>> quite strongly:
>>
>> const unsigned image[] = {
>> B(X___,___X)
>> B(_X__,__X_)
>> B(__X_,_X__)
>> B(___X,X___)
>> B(___X,X___)
>> B(__X_,_X__)
>> B(_X__,__X_)
>> B(X___,___X)
>> };
>>
>> using these definitions:
>>
>> #define PAT_____ 0
>> #define PAT____X 1
>> #define PAT___X_ 2
>> #define PAT___XX 3
>> #define PAT__X__ 4
>> #define PAT__X_X 5
>> #define PAT__XX_ 6
>> #define PAT__XXX 7
>> #define PAT_X___ 8
>> #define PAT_X__X 9
>> #define PAT_X_X_ a
>> #define PAT_X_XX b
>> #define PAT_XX__ c
>> #define PAT_XX_X d
>> #define PAT_XXX_ e
>> #define PAT_XXXX f
>>
>> #define B(a, b) BX(PAT_ ## a, PAT_ ## b)
>> #define BX(a, b) BXX(a, b)
>> #define BXX(a, b) 0x ## a ## b,
>>
>> I agree that the very low cost to implement binary literals should be
>> taken into account. Even a few uses makes it a net gain, but it almost
>> certainly needs a digit separator as well.
>
> Neat trick of self constructing binary literals.
> Can some pedant reject usage of those 'PAT__XX_' on review as usage
> of reserved names?
I think it's OK. The PAT__ names are fine, and though an implementation
is permitted to define macros called __XX (and so on), they will have no
effect on the code because no macro called __XX is ever defined or
expanded.
> Can perhaps fall back to usage of 'oXXo' or the like on such case but
> '_XX_' looks better.
I like Richard's nested expression idea better in some ways. I think
(for patterns) you could get the stringer contrast by using X and _
where he wrote O and l. That's safe because _ on its own is not a
reserved name.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-25 17:42 +0100 |
| Message-ID | <mjvjb6$v70$1@dont-email.me> |
| In reply to | #62599 |
On 25/05/15 17:10, Ben Bacarisse wrote: > I like Richard's nested expression idea better in some ways. I think > (for patterns) you could get the stringer contrast by using X and _ > where he wrote O and l. That's safe because _ on its own is not a > reserved name. The idea is not mine - it comes from Peter van der Linden's book, "Deep C Secrets". All I did was to introduce O and l (to mimic 0 and 1, of course). His original tokens were, IIRC, _ and X. :-) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-25 12:20 -0700 |
| Message-ID | <87oal8o45e.fsf@kst-u.example.com> |
| In reply to | #62596 |
Öö Tiib <ootiib@hot.ee> writes:
[...]
> Neat trick of self constructing binary literals.
> Can some pedant reject usage of those 'PAT__XX_' on review as usage
> of reserved names?
In C, PAT__XX_ is not reserved.
(In C++, identifiers containing a double underscore are reserved.)
--
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:07 -0700 |
| Message-ID | <kfnoajk54c5.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #62531 |
Bartc <bc@freeuk.com> writes: > On 24/05/2015 15: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). > > Are you suggesting that binary constants are /never/ useful? No, only that they offer very marginal utility, and cases where the extra utility might be worthwhile are sufficiently rare so that it is better for the language to leave them out. Any language construct anyone can think up is going to be useful in _some_ circumstances; the question is does the value outweigh the intellectual cost of making the language bigger. Binary constants are just not very useful, as evidenced by their rarity in regular writing. By comparison octal constants or hexadecimal constants occur with reasonable frequency. > This is such a trivially implemented enhancement that you can > afford to just throw it in, and let people use it if they want. The cost of implementation is irrelevant here. Also you are ignoring the collateral costs for things like library functions, etc. > Obviously nobody is suggesting switching from decimal, or hex, to > binary just for the hell of it. Binary will be used for a reason. > [examples] I don't find any of these examples compelling, let alone convincing. Most of them are better done using techniques others have pointed out in their responses. The bitmap example is arguably an exception, but even in that case other approaches were pointed out that IMO do a better job; plus putting bitmaps in programs is very rare (and these days tends to be done using resource files, which don't have to rely on language syntax). In general I think it's a good idea to follow Tony Hoare's advice: a proposed language construct should be added to the language only if it is going to be used by every (non-trivial) program written in that language. Binary constants fail that test. > Or, you maybe you are right and this would all be just as easy in > decimal or hex. (When it's come up before, someone devised a macro > which interpreted its parameter as a binary string. But if someone > goes to that much trouble, it means it could do with being in the > language.) It could mean that, but in this case I don't think it does. The reason is pretty simple: most programs don't need it. Better to leave the funny macro solution in for those (very!) few programs that do.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-10 20:09 +0100 |
| Message-ID | <mnp57m$jpo$1@dont-email.me> |
| In reply to | #65140 |
On 10/07/2015 18:07, Tim Rentsch wrote: > Bartc <bc@freeuk.com> writes: >> Are you suggesting that binary constants are /never/ useful? > > No, only that they offer very marginal utility, and cases where > the extra utility might be worthwhile are sufficiently rare so > that it is better for the language to leave them out. You mean, such as octal constants, and a hundred other things that hardly anyone ever uses? > Any > language construct anyone can think up is going to be useful > in _some_ circumstances; the question is does the value outweigh > the intellectual cost of making the language bigger. Sometimes orthogonality and completeness is also of value. > Binary > constants are just not very useful, as evidenced by their rarity > in regular writing. Well, there might be a good reason for that! It's difficult to use binary constants when they don't exist in the language. If you mean writing in natural language, then I can understand they will not figure too much in Shakespeare or Dickens, but I'm looking at the AMD64 manuals now and they do use binary constants within the text. > By comparison octal constants or hexadecimal > constants occur with reasonable frequency. Octal constants don't, unless you include the value 0. I'm fairly sure a lot of C coders don't even know they exist. >> This is such a trivially implemented enhancement that you can >> afford to just throw it in, and let people use it if they want. > > The cost of implementation is irrelevant here. Also you are > ignoring the collateral costs for things like library functions, > etc. What are those costs? As I can't see they impact library functions at all. >> Obviously nobody is suggesting switching from decimal, or hex, to >> binary just for the hell of it. Binary will be used for a reason. >> [examples] > > I don't find any of these examples compelling, let alone > convincing. Most of them are better done using techniques others > have pointed out in their responses. Well, /I/ use them and I find them a benefit. I don't care if other people try to convince themselves that they are not needed. I am in the fortunate position of being able to write or adapt languages so that I can do what I like. But I feel sorry for those deprived of a simple, handy feature such as this, or are forced to resort to hairy-looking macros. > It could mean that, but in this case I don't think it does. > The reason is pretty simple: most programs don't need it. I found it amusing once to list all the things that C programs didn't really need because it was possible to fall back on something else. Believe me, there wasn't much of the language left! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-11 11:19 -0700 |
| Message-ID | <kfnk2u6woa2.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65177 |
Bartc <bc@freeuk.com> writes: > On 10/07/2015 18:07, Tim Rentsch wrote: >> Bartc <bc@freeuk.com> writes: >> >>> Are you suggesting that binary constants are /never/ useful? >> >> No, only that they offer very marginal utility, and cases where >> the extra utility might be worthwhile are sufficiently rare so >> that it is better for the language to leave them out. > > You mean, such as octal constants, Personally I find octal constants useful perhaps somewhat rarely, but they do offer significant utility in those cases. YMMV. > and a hundred other things that > hardly anyone ever uses? Not sure which hundred things you think no one uses, but if you post a list here I'd be happy to take a look at it. >> Any >> language construct anyone can think up is going to be useful >> in _some_ circumstances; the question is does the value outweigh >> the intellectual cost of making the language bigger. > > Sometimes orthogonality and completeness is also of value. Yes, that is a factor. It may not be the determining factor, but it is a factor. >> Binary >> constants are just not very useful, as evidenced by their rarity >> in regular writing. > > Well, there might be a good reason for that! It's difficult to use > binary constants when they don't exist in the language. If you mean > writing in natural language, then I can understand they will not > figure too much in Shakespeare or Dickens, but I'm looking at the > AMD64 manuals now and they do use binary constants within the text. I was thinking of technical literature and documentation. >> By comparison octal constants or hexadecimal >> constants occur with reasonable frequency. > > Octal constants don't, unless you include the value 0. I'm fairly sure > a lot of C coders don't even know they exist. I guess you haven't read the same technical literature that I have. >>> This is such a trivially implemented enhancement that you can >>> afford to just throw it in, and let people use it if they want. >> >> The cost of implementation is irrelevant here. Also you are >> ignoring the collateral costs for things like library functions, >> etc. > > What are those costs? As I can't see they impact library > functions at all. Really? Are you familiar with the functions in <stdlib.h> and <stdio.h>? >>> Obviously nobody is suggesting switching from decimal, or hex, to >>> binary just for the hell of it. Binary will be used for a reason. >>> [examples] >> >> I don't find any of these examples compelling, let alone >> convincing. Most of them are better done using techniques others >> have pointed out in their responses. > > Well, /I/ use them and I find them a benefit. I don't care if other > people try to convince themselves that they are not needed. When it comes to adding something to C, it's necessary to take into account what other people think. > I am in the fortunate position of being able to write or adapt > languages so that I can do what I like. But I feel sorry for those > deprived of a simple, handy feature such as this, or are forced to > resort to hairy-looking macros. Okay, but my comments here are made in the context of whether something should be added to C. I have no opinion on what should go into your pet language. >> It could mean that, but in this case I don't think it does. >> The reason is pretty simple: most programs don't need it. > > I found it amusing once to list all the things that C programs didn't > really need because it was possible to fall back on something > else. Believe me, there wasn't much of the language left! I've looked through that list, or at least what I think you're referring to. I didn't find it to be of much value, since basically all it reflects is your own opinions; that is, it doesn't say what other people think they need, but only what you think they need. If one wants to be effective in getting changes made to C, it's important to take into account what other people actually think, not just what you think they should think.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-11 20:25 +0100 |
| Message-ID | <mnrqg1$sos$1@dont-email.me> |
| In reply to | #65322 |
On 11/07/2015 19:19, Tim Rentsch wrote:
> Bartc <bc@freeuk.com> writes:
>> What are those costs? As I can't see they impact library
>> functions at all.
>
> Really? Are you familiar with the functions in <stdlib.h>
> and <stdio.h>?
Many of them, yes. One or two might be affected if it becomes necessary
to support binary input and output. But binary is most useful when it's
possible to write binary constants within the source code. I/O can be
done with user functions. In that case, which library functions are
affected?
>> I am in the fortunate position of being able to write or adapt
>> languages so that I can do what I like. But I feel sorry for those
>> deprived of a simple, handy feature such as this, or are forced to
>> resort to hairy-looking macros.
>
> Okay, but my comments here are made in the context of whether
> something should be added to C.
As I said, many people /would/ benefit, but others are deciding they
shouldn't have it, something so fundamental that it is extraordinary
that it isn't in already.
> I have no opinion on what
> should go into your pet language.
My pet language can also be used in wrapper mode for C. I do actually
get a kick of being able to just write digit patterns expressed like this:
println 2x_1_00_111_0000_11111_00000_111111
println 111'110'101'100'0011'0010'0001'0000_B
println 4x_3032_3233_2323
and it effortlessly spits out:
printf("%d\n",40958015);
printf("%d\n",262943248);
printf("%d\n",13561787);
However, you clearly don't want anyone to be able to do that in C
itself. (The 3rd example is actually base 4; this was used in real code!
Some might find it an interesting puzzle as to what the digits mean
here. The separators are not significant.)
>> I found it amusing once to list all the things that C programs didn't
>> really need because it was possible to fall back on something
>> else. Believe me, there wasn't much of the language left!
>
> I've looked through that list, or at least what I think you're
> referring to. I didn't find it to be of much value, since
> basically all it reflects is your own opinions;
That's probably not the list. (If you're talking about the list of '100
Things', then quite a few people agreed with many of them. But I'm not
surprised that you don't!)
No, it's features that are not absolutely essential, like control
structures, structs, or even most variables. You wouldn't want to
program in such a language, but when using C as a target, then using
such a stripped down language is feasible.
Binary constants are just another of those things that can make life a
bit easier.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-16 08:48 -0700 |
| Message-ID | <kfnoajcp0gy.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65326 |
Bartc <bc@freeuk.com> writes: > On 11/07/2015 19:19, Tim Rentsch wrote: >> Bartc <bc@freeuk.com> writes: >> >>> What are those costs? As I can't see they impact library >>> functions at all. >> >> Really? Are you familiar with the functions in <stdlib.h> >> and <stdio.h>? > > Many of them, yes. One or two might be affected if it becomes > necessary to support binary input and output. But binary is most > useful when it's possible to write binary constants within the > source code. I/O can be done with user functions. In that case, > which library functions are affected? Obviously the C language designers have chosen to reflect the presence (or absence) of certain constant format in various library functions. There is no reason to assume binary constants either should or would be treated any differently. I'm sure you are capable of looking through the Standard and discovering which functions fall into this category. >>> I am in the fortunate position of being able to write or adapt >>> languages so that I can do what I like. But I feel sorry for those >>> deprived of a simple, handy feature such as this, or are forced to >>> resort to hairy-looking macros. >> >> Okay, but my comments here are made in the context of whether >> something should be added to C. > > As I said, many people /would/ benefit, but others are deciding > they shouldn't have it, something so fundamental that it is > extraordinary that it isn't in already. A needlessly bombastic comment. I know your opinion; my point is your opinion is not what counts in such cases. >> I have no opinion on what >> should go into your pet language. > > My pet language [snip] I also have no interest in discussing your pet language while in comp.lang.c. >>> I found it amusing once to list all the things that C programs didn't >>> really need because it was possible to fall back on something >>> else. Believe me, there wasn't much of the language left! >> >> I've looked through that list, or at least what I think you're >> referring to. I didn't find it to be of much value, since >> basically all it reflects is your own opinions; > > That's probably not the list. (If you're talking about the list > of 100 Things', then quite a few people agreed with many of them. > But I'm not surprised that you don't!) I think you misunderstood the point of my comment. I expect I agreed with some of the items on your list and didn't agree with others, but the point of my comment had nothing to do with whether I agreed or not. > No, it's features that are not absolutely essential, like control > structures, structs, or even most variables. You wouldn't want to > program in such a language, but when using C as a target, then > using such a stripped down language is feasible. AFAICT that has no bearing on the current discussion. Given what has been under discussion, I don't know why you would bring it up. > Binary constants are just another of those things that can make > life a bit easier. I'm sure there are cases when having binary constants in C would make some particular coding task easier. But the key questions are how much easier, how rarely do those situations occur, and what are the costs that would be borne if C added such constants. You keep ignoring these questions; doing that makes any argument you give be not convincing.
[toc] | [prev] | [next] | [standalone]
Page 8 of 22 — ← Prev page 1 … 6 7 [8] 9 10 … 22 Next page →
Back to top | Article view | comp.lang.c
csiph-web