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 3 of 22 — ← Prev page 1 2 [3] 4 5 … 22 Next page →
| From | James Dow Allen <jdallen2000@yahoo.com> |
|---|---|
| Date | 2015-04-24 13:27 -0700 |
| Message-ID | <fbe2d35f-e040-4be7-a2e0-3136037a053c@googlegroups.com> |
| In reply to | #61020 |
On Saturday, April 25, 2015 at 12:21:03 AM UTC+7, Richard Heathfield wrote: > concept of reduction modulo (<TYPE>_MAX + 1) for unsigned integer types > is integral to a proper understanding of C BUT when browsing the code quickly, it is easily overlooked that the variable is unsigned rather than signed. Initializing a max/min aggregate to very large or very small (or often just any negative) is very common. "-1" looks like a lower bound. "(unsigned [whatever])-1" would be recognized as an upper bound. Stated differently writing "-1" and expecting the user to immediately know that a large positive integer is intended is a form of obfuscation. I don't feel strongly about this. But my coding is sometimes denigrated for assuming reader knows, e.g. precedence rules, and turnabout is fair play. :-) A key difference is that many complex expressions are understandable by themselves, BUT your example requires that the reader be aware of the specific type declared elsewhere (and often irrelevant for quick browsing). Of course anyone planning to modify the code would know the type, but sometimes we browse large chunks of code quickly for general comprehension. James
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-04-25 10:25 +0000 |
| Message-ID | <553b6b6d.10031484@news.xs4all.nl> |
| In reply to | #61015 |
James Dow Allen <jdallen2000@yahoo.com> wrote: > Geeez. Can't you guys assume I wrote what was intended? > :-) :-) The compiler can't... Richard
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-24 23:02 +0100 |
| Message-ID | <87sibn3kec.fsf@bsb.me.uk> |
| In reply to | #61015 |
James Dow Allen <jdallen2000@yahoo.com> writes: <snip> >> If RAND_MAX is a power-of-2 > > Obviously (again) I meant one less than a power-of-two. > > Geeez. Can't you guys assume I wrote what was intended? That's a wise bit of advice but I am completely stumped by what you intended to say about removing the bias. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.lists@bsb.me.uk> |
|---|---|
| Date | 2015-04-24 11:30 +0100 |
| Message-ID | <87egn96co9.fsf@bsb.me.uk> |
| In reply to | #60978 |
James Dow Allen <jdallen2000@yahoo.com> writes: > Two nitpicks. > > On Thursday, April 23, 2015 at 2:10:02 PM UTC+7, Richard Heathfield wrote: <snip> >> return 1 + sides * (rand() / (RAND_MAX + 1.0)); > > That introduces a tiny bias. If RAND_MAX is a power-of-2 > the simplest change to get an unbiased variate is > return 1 + sides * ((rand() | 1) / (RAND_MAX + 1.0)); RAND_MAX is very unlikely to be a power of two, but if it is, this change introduces a bug (in that the result can now be larger than intended) whilst not removing the bias. When RAND_MAX is one less than a power of two (the more usual case) there is no bug, but the bias remains (though altered, of course). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-26 08:09 -0700 |
| Message-ID | <kfn618jorir.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60978 |
James Dow Allen <jdallen2000@yahoo.com> writes:
> Two nitpicks.
>
> On Thursday, April 23, 2015 at 2:10:02 PM UTC+7, Richard Heathfield wrote:
>> *low = -1;
>> The code as written is perfectly clear, and
>> needs no rewriting. A cast would be pointless obscurantism.
>
> Au contraire, much clearer (for me) would be, for example
> *low = (unsigned)-1;
> YMMV. Some codings clear to me are less clear to others;
> and, in this case, vice versa. Yes, the cast is implicit
> anyway *but only if I'm bothered to check low's type.*
> In any event, I fail to see why such a cast is "obscurantism;"
> it's rather *the opposite.*
I have a strong aversion to casts, especially in situations
like this one. I agree however that this line merits
some sort of fix-up, since what's going on isn't obvious.
(That might be different if we were initialialing rather
than assigning, because the type would be right in case, but
we aren't.) Taking both of these concerns into account, I
suggest
*low = (uintmax_t){ -1 };
which surely does the right thing if the left-hand-side type is
any unsigned integer type, and also makes it obvious that setting
some unsigned type to all ones is what is intended.
>> return 1 + sides * (rand() / (RAND_MAX + 1.0));
>
> That introduces a tiny bias. If RAND_MAX is a power-of-2
> the simplest change to get an unbiased variate is
> return 1 + sides * ((rand() | 1) / (RAND_MAX + 1.0));
> Yes, the bias is miniscule unless RAND_MAX is small.
> But nitpicking about random() usage is one thing we do here. :-)
I have to disagree on this one. If RAND_MAX % sides != sides-1
then there is no way to get an unbiased sample without multiple
calls (potentially) to rand(). The /simplest/ change to get an
unbiased variate is probably this one:
int
die( int sides ){
int r = rand();
return r < sides ? r + 1 : die( sides );
}
which I'm sure other folks will have no difficulty criticizing
or improving. :)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-26 12:26 -0700 |
| Message-ID | <87egn6hesd.fsf@kst-u.example.com> |
| In reply to | #61141 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> I have a strong aversion to casts, especially in situations
> like this one. I agree however that this line merits
> some sort of fix-up, since what's going on isn't obvious.
> (That might be different if we were initialialing rather
> than assigning, because the type would be right in case, but
> we aren't.) Taking both of these concerns into account, I
> suggest
>
> *low = (uintmax_t){ -1 };
>
> which surely does the right thing if the left-hand-side type is
> any unsigned integer type, and also makes it obvious that setting
> some unsigned type to all ones is what is intended.
[...]
The use of a compound literal for a scalar type might be a bit
confusing to some. I'm not saying it *should* be, and I wouldn't
mind if that became a common idiom, but I'm not sure I've seen anyone
other than you take advantage of it. A cast would be equivalent
and arguably clearer. (It's also supported in C90, but uintmax_t
isn't, so ...).
But it doesn't *always* work correctly. On 64-bit targets, gcc
supports types `__int128` and `unsigned __int128` as an extension --
but they're *not* treated as extended integer types, and intmax_t
and uintmax_t are still 64 bits. Which means that if *low happens
to be of type unsigned __int128, then the above will assign an
incorrect value to it, whereas
*low = -1;
would have worked correctly.
I've been told that some ABI requires intmax_t and uintmax_t
to be 64 bits. IMHO that's a horrible requirement.
It doesn't forbid extended types wider than 64 bits, but
it forbids implementing them correctly. But I just checked
http://www.x86-64.org/documentation/abi.pdf, and it doesn't mention
[u]intmax_t or <stdint.h>.
--
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-04-28 09:52 -0700 |
| Message-ID | <kfnoam8ci08.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61156 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [...]
>> I have a strong aversion to casts, especially in situations
>> like this one. I agree however that this line merits
>> some sort of fix-up, since what's going on isn't obvious.
>> (That might be different if we were initialialing rather
>> than assigning, because the type would be right in case, but
>> we aren't.) Taking both of these concerns into account, I
>> suggest
>>
>> *low = (uintmax_t){ -1 };
>>
>> which surely does the right thing if the left-hand-side type is
>> any unsigned integer type, and also makes it obvious that setting
>> some unsigned type to all ones is what is intended.
>
> [...]
>
> The use of a compound literal for a scalar type might be a bit
> confusing to some. I'm not saying it *should* be, and I wouldn't
> mind if that became a common idiom, but I'm not sure I've seen
> anyone other than you take advantage of it.
I agree it's more likely to see a cast used in such cases, which
is probably largely historical. I agree also that it would be
unfamiliar (not sure about confusing, but at least unfamiliar)
to many readers. However that's not a reason not to use it -
if it is a better way to express what is intended (which IMO it
is), then it's better to make the switch. Change has to start
somewhere.
> A cast would be equivalent and arguably clearer.
A cast would be equivalent /in this case/, but not in similar
cases, and that is the point. Using a compound literal in cases
like this is safer because it accepts only assignable types, not
the wider range of types that casts allow. As for clearer, I
believe that is a mistaken identification; it's what most
people are used to, but that doesn't make it clearer. I would
argue that using a cast is less clear, because casts can effect
both safe and unsafe conversions, whereas compound literals can
effect only safe conversions (with the obvious disclaimers about
narrowing, void *, etc). If I see a cast I have to wonder (if
even only briefly) whether the conversion is safe or unsafe,
but with compound literals there is no such concern. IMO casts
should be limited to cases of unsafe conversions, and compound
literals used for all safe conversion.
> (It's also supported in C90, but uintmax_t isn't, so ...).
Right.
> But it doesn't *always* work correctly. On 64-bit targets, gcc
> supports types `__int128` and `unsigned __int128` as an extension
> -- but they're *not* treated as extended integer types, and
> intmax_t and uintmax_t are still 64 bits. Which means that if
> *low happens to be of type unsigned __int128, then the above will
> assign an incorrect value to it, whereas
>
> *low = -1;
>
> would have worked correctly.
It does work correctly in the cases I said it would, where the
left-hand side is an unsigned integer type, since the __int128
types are not integer types as the Standard uses the term (kind
of what you pointed out). However I take your point, and it is
a good one.
> I've been told that some ABI requires intmax_t and uintmax_t to
> be 64 bits. IMHO that's a horrible requirement.
Beyond horrble. Stupefyingly bad.
> It doesn't
> forbid extended types wider than 64 bits, but it forbids
> implementing them correctly. But I just checked
> http://www.x86-64.org/documentation/abi.pdf, and it doesn't
> mention [u]intmax_t or <stdint.h>.
So, this raises the question - do you know of some actual
specification that limits [u]intmax_t to 64 bits?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-28 11:27 -0700 |
| Message-ID | <871tj4glau.fsf@kst-u.example.com> |
| In reply to | #61203 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> I've been told that some ABI requires intmax_t and uintmax_t to
>> be 64 bits. IMHO that's a horrible requirement.
>
> Beyond horrble. Stupefyingly bad.
>
>> It doesn't
>> forbid extended types wider than 64 bits, but it forbids
>> implementing them correctly. But I just checked
>> http://www.x86-64.org/documentation/abi.pdf, and it doesn't
>> mention [u]intmax_t or <stdint.h>.
>
> So, this raises the question - do you know of some actual
> specification that limits [u]intmax_t to 64 bits?
No, I don't. The web page showing C++11 implementation status for
Clang, in the section on C99 features in C++11, says:
Extended integral types: N/A
with a footnote that says:
No compiler changes are required for an implementation such as Clang
that does not provide any extended integer types. __int128 is not
treated as an extended integer type, because changing intmax_t would
be an ABI-incompatible change.
I don't know what ABI that's referring to. As I said, the x86-64 ABI
document I was able to find (which isn't referenced from the Clang page)
doesn't mention [u]intmax_t, or even <stdint.h>.
There's a gcc bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49595
that's been resolved as "invalid". The response says that __int128 is
not an "extended integer type" as defined by the C99 standard, and
therefore the definition of [u]intmax_t needn't reflect its existence.
That's true, but no real justification is given for the (permitted but
IMHO flawed) decision to treat __int128 as an extension rather than as
an extended integer type. A comment in the bug report claims that
sizeof(intmax_t) is fixed by various LP64 ABIs and cannot be changed
but no support is given for that claim, even though someone else
specifically asked for specifics.
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-28 20:09 +0100 |
| Message-ID | <mholrr$lcl$1@dont-email.me> |
| In reply to | #61205 |
On 28/04/15 19:27, Keith Thompson wrote: <snip> > A comment in the bug report claims that > > sizeof(intmax_t) is fixed by various LP64 ABIs and cannot be changed That's priceless. Next stop: intmaxmax_t -- 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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-30 07:11 -0700 |
| Message-ID | <kfnzj5paeoh.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61205 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>
> [...]
>
>>> I've been told that some ABI requires intmax_t and uintmax_t to
>>> be 64 bits. IMHO that's a horrible requirement.
>>
>> Beyond horrble. Stupefyingly bad.
>>
>>> It doesn't
>>> forbid extended types wider than 64 bits, but it forbids
>>> implementing them correctly. But I just checked
>>> http://www.x86-64.org/documentation/abi.pdf, and it doesn't
>>> mention [u]intmax_t or <stdint.h>.
>>
>> So, this raises the question - do you know of some actual
>> specification that limits [u]intmax_t to 64 bits?
>
> No, I don't. The web page showing C++11 implementation status for
> Clang, in the section on C99 features in C++11, says:
>
> Extended integral types: N/A
>
> with a footnote that says:
>
> No compiler changes are required for an implementation such as Clang
> that does not provide any extended integer types. __int128 is not
> treated as an extended integer type, because changing intmax_t would
> be an ABI-incompatible change.
>
> I don't know what ABI that's referring to. As I said, the x86-64 ABI
> document I was able to find (which isn't referenced from the Clang page)
> doesn't mention [u]intmax_t, or even <stdint.h>.
>
> There's a gcc bug report:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49595
>
> that's been resolved as "invalid". The response says that __int128 is
> not an "extended integer type" as defined by the C99 standard, and
> therefore the definition of [u]intmax_t needn't reflect its existence.
> That's true, but no real justification is given for the (permitted but
> IMHO flawed) decision to treat __int128 as an extension rather than as
> an extended integer type. A comment in the bug report claims that
>
> sizeof(intmax_t) is fixed by various LP64 ABIs and cannot be changed
>
> but no support is given for that claim, even though someone else
> specifically asked for specifics.
Thank you for the information. Following this, I decided to do
some web research. Based on what I read, I have a theory of
sorts, which is this. Operating systems such as Linux supply a
system call library, to access functions in the OS. What is
needed by that library defines the ABI for that system. Rightly
or wrongly, the system-supplied library is thought to include
(some portion of) a standard C library. Since the OS now "owns"
those functions, the ABI for that OS covers any types used in
said library. The types [u]intmax_t are among those type,
because they may be used for arguments given to printf (ie, there
is a format specifier that expects such types). Hence the ABI
for the OS includes these types as part of its specifications.
Some selected quotes:
"(b) The <stdint.h> types may need to be compatible with
those chosen by vendors. For intmax_t, this may affect the
printf ABI."
"Indeed. The underlying type of all typedefs is part of the
ABI if you're considering C++. [...] I think [u]intmax_t
should just be moved back to alltypes.h with the correct
per-arch definitions."
"Unfortunately, not many software developers rush towards
binary compatibility - for instance, the Microsoft compilers
use their own C++ ABI. And because Morpher produces binary
object files, users of compilers that do not stick to the
Generic C++ ABI can face compatibility problems."
"Most platforms have a well-defined ABI that covers C code,
but ABIs that cover C++ functionality are not yet common."
For reference here are URLS for pages that turned up in my search
(some of which may be incidental to the question). If you look
into this question further I'd be interested to hear any other
conclusions you might reach.
http://gcc.gnu.org/ml/gcc/2000-07/msg00142.html
http://www.risc.jku.at/education/courses/ws2003/intropar/origin-new/MproCplrDbx_TG/sgi_html/ch06.html
http://upstream-tracker.org/compat_reports/jemalloc/3.4.1_to_3.5.1/abi_compat_report.html
http://www.openwall.com/lists/musl/2013/02/09/3
http://morpher.com/documentation/articles/abi/
http://gcc.gnu.org/onlinedocs/gcc/Compatibility.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2270.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2130.html
http://developerblog.redhat.com/2014/10/23/comparing-abis-for-compatibility-with-libabigail-part-1/
http://infocenter.arm.com/help/topic/com.arm.doc.dui0774a/chr1383660321827.html
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140224/100324.html
http://herbsutter.com/2012/12/04/compatibility/
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <pc+usenet@asdf.org> |
|---|---|
| Date | 2015-05-09 13:14 +0300 |
| Message-ID | <87lhgyrral.fsf@bazspaz.fatphil.org> |
| In reply to | #61205 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: > > Keith Thompson <kst-u@mib.org> writes: > [...] > >> I've been told that some ABI requires intmax_t and uintmax_t to > >> be 64 bits. IMHO that's a horrible requirement. > > > > Beyond horrble. Stupefyingly bad. I think I'm somewhere between you two on that point. > >> It doesn't > >> forbid extended types wider than 64 bits, but it forbids > >> implementing them correctly. But I just checked > >> http://www.x86-64.org/documentation/abi.pdf, and it doesn't > >> mention [u]intmax_t or <stdint.h>. > > > > So, this raises the question - do you know of some actual > > specification that limits [u]intmax_t to 64 bits? > > No, I don't. The web page showing C++11 implementation status for > Clang, in the section on C99 features in C++11, says: > > Extended integral types: N/A > > with a footnote that says: > > No compiler changes are required for an implementation such as Clang > that does not provide any extended integer types. __int128 is not > treated as an extended integer type, because changing intmax_t would > be an ABI-incompatible change. > > I don't know what ABI that's referring to. As I said, the x86-64 ABI > document I was able to find (which isn't referenced from the Clang page) > doesn't mention [u]intmax_t, or even <stdint.h>. Looks like proof by assertion. > There's a gcc bug report: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49595 > > that's been resolved as "invalid". The response says that __int128 is > not an "extended integer type" as defined by the C99 standard, and > therefore the definition of [u]intmax_t needn't reflect its existence. > That's true, but no real justification is given for the (permitted but > IMHO flawed) decision to treat __int128 as an extension rather than as > an extended integer type. I presume it does all the usual (extended) interger type behaviour (appropriate conversion rank and associated automatic conversions/ promotions)? How does GCC explain that away - does it list all of the usual behaviour of integer types and say that despite 128-bit types not being integer types they behave the same way? > A comment in the bug report claims that > > sizeof(intmax_t) is fixed by various LP64 ABIs and cannot be changed > > but no support is given for that claim, even though someone else > specifically asked for specifics. Ah, proof by assertion again, always a winner. At least they didn't just point the finger at Clang and say "we're just doing what they said was right". Phil -- A well regulated militia, being necessary to the security of a free state, the right of the people to keep and bear arms, shall be well regulated.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-10 08:23 -0700 |
| Message-ID | <kfn8ucwfod8.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61800 |
Phil Carmody <pc+usenet@asdf.org> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>
>> [...]
>>
>>>> I've been told that some ABI requires intmax_t and uintmax_t to
>>>> be 64 bits. IMHO that's a horrible requirement.
>>>
>>> Beyond horrble. Stupefyingly bad.
>
> I think I'm somewhere between you two on that point.
Oh really? I thought "stupefyingly bad" was a fairly mild
increase over "horrible" - ie, not so extreme as, eg,
"horrifically grotesque". :)
>>>> It doesn't
>>>> forbid extended types wider than 64 bits, but it forbids
>>>> implementing them correctly. But I just checked
>>>> http://www.x86-64.org/documentation/abi.pdf, and it doesn't
>>>> mention [u]intmax_t or <stdint.h>.
>>>
>>> So, this raises the question - do you know of some actual
>>> specification that limits [u]intmax_t to 64 bits?
>>
>> No, I don't. The web page showing C++11 implementation status for
>> Clang, in the section on C99 features in C++11, says:
>>
>> Extended integral types: N/A
>>
>> with a footnote that says:
>>
>> No compiler changes are required for an implementation such as
>> Clang that does not provide any extended integer types.
>> __int128 is not treated as an extended integer type, because
>> changing intmax_t would be an ABI-incompatible change.
>>
>> I don't know what ABI that's referring to. As I said, the x86-64
>> ABI document I was able to find (which isn't referenced from the
>> Clang page) doesn't mention [u]intmax_t, or even <stdint.h>.
>
> Looks like proof by assertion.
I think the remark is meant only as a statement, not as a proof.
>> There's a gcc bug report:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49595
>>
>> that's been resolved as "invalid". The response says that __int128
>> is not an "extended integer type" as defined by the C99 standard,
>> and therefore the definition of [u]intmax_t needn't reflect its
>> existence. That's true, but no real justification is given for the
>> (permitted but IMHO flawed) decision to treat __int128 as an
>> extension rather than as an extended integer type.
>
> I presume it does all the usual (extended) interger type behaviour
> (appropriate conversion rank and associated automatic conversions/
> promotions)? How does GCC explain that away - does it list all of
> the usual behaviour of integer types and say that despite 128-bit
> types not being integer types they behave the same way?
The types __[u]int128 satisfy some, but not all, requirements
that the Standard gives for standard/extended integer types.
This page
http://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html
says this:
As an extension the integer scalar type __int128 is
supported for targets which have an integer mode wide enough
to hold 128 bits. Simply write __int128 for a signed 128-bit
integer, or unsigned __int128 for an unsigned 128-bit
integer. There is no support in GCC for expressing an
integer constant of type __int128 for targets with long long
integer less than 128 bits wide.
Note that there are other considerations besides promotion and
conversion rank. For example, are int128_t or PRI*128 defined?
(I believe they are not.) Also there are implications for the
preprocessor, where all integer types have a width matching
[u]intmax_t, but not __[u]int128.
>> A comment in the bug report claims that
>>
>> sizeof(intmax_t) is fixed by various LP64 ABIs and cannot be
>> changed
>>
>> but no support is given for that claim, even though someone else
>> specifically asked for specifics.
>
> Ah, proof by assertion again, always a winner. At least they
> didn't just point the finger at Clang and say "we're just doing
> what they said was right".
Did you see my followup note? There is some substance to the
claim, because of practical realities concerning how linking
is done with third-party libraries. To me this indicates a
flaw somewhere, but it isn't clear just where.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-10 11:06 -0700 |
| Message-ID | <87egmogve8.fsf@kst-u.example.com> |
| In reply to | #61819 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> The types __[u]int128 satisfy some, but not all, requirements
> that the Standard gives for standard/extended integer types.
The types are `__int128` and `unsigned __int128`. `__int128` is treated
as an implementation-defined keyword.
The main requirement that they fail to satisfy is documentation that
they're extended integer types. The gcc manual specifically says that
gcc doesn't support any extended integer types.
> This page
>
> http://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html
>
> says this:
>
> As an extension the integer scalar type __int128 is
> supported for targets which have an integer mode wide enough
> to hold 128 bits. Simply write __int128 for a signed 128-bit
> integer, or unsigned __int128 for an unsigned 128-bit
> integer. There is no support in GCC for expressing an
> integer constant of type __int128 for targets with long long
> integer less than 128 bits wide.
>
> Note that there are other considerations besides promotion and
> conversion rank. For example, are int128_t or PRI*128 defined?
No.
> (I believe they are not.) Also there are implications for the
> preprocessor, where all integer types have a width matching
> [u]intmax_t, but not __[u]int128.
gcc's preprocessor warns about integer constants bigger than 2**64-1.
[...]
--
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-11 21:52 -0700 |
| Message-ID | <kfnd226cs7v.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61830 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: > [...] >> The types __[u]int128 satisfy some, but not all, requirements >> that the Standard gives for standard/extended integer types. > > The types are `__int128` and `unsigned __int128`. Ahh, okay, thank you for the correction. > `__int128` is treated > as an implementation-defined keyword. > > The main requirement that they fail to satisfy is documentation that > they're extended integer types. The gcc manual specifically says that > gcc doesn't support any extended integer types. I was thinking of implicit requirements like their ranges being a subset of the range of [u]intmax_t. (I don't know if there are others, I didn't try to make an exhaustive list.) >> This page >> >> http://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html >> >> says this: >> >> As an extension the integer scalar type __int128 is >> supported for targets which have an integer mode wide enough >> to hold 128 bits. Simply write __int128 for a signed 128-bit >> integer, or unsigned __int128 for an unsigned 128-bit >> integer. There is no support in GCC for expressing an >> integer constant of type __int128 for targets with long long >> integer less than 128 bits wide. >> >> Note that there are other considerations besides promotion and >> conversion rank. For example, are int128_t or PRI*128 defined? > > No. > >> (I believe they are not.) Also there are implications for the >> preprocessor, where all integer types have a width matching >> [u]intmax_t, but not __[u]int128. > > gcc's preprocessor warns about integer constants bigger than 2**64-1. Right, which presumably it would not do if __int128 were considered by gcc to be an extended integer type.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-10 12:20 -0400 |
| Message-ID | <mio0f6$vva$1@dont-email.me> |
| In reply to | #61205 |
On 04/28/2015 02:27 PM, Keith Thompson wrote: ... > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49595 > > that's been resolved as "invalid". The response says that __int128 is > not an "extended integer type" as defined by the C99 standard, and > therefore the definition of [u]intmax_t needn't reflect its existence. > That's true, but no real justification is given for the (permitted but > IMHO flawed) decision to treat __int128 as an extension rather than as > an extended integer type. A comment in the bug report claims that That's a perfectly feasible approach - but it has certain consequences: if __int128 isn't an extended integer type (and it's certainly not a standard integer type), it can't qualify as an integer type. The standard doesn't allow for extended floating point types, so it can't qualify as a floating point type (and probably wouldn't meet the appropriate requirements if the standard did allow extended floating point types). Therefore, it can't qualify as an arithmetic type, either. By similar logic, it can't qualify as a scalar type. Therefore, any use of __int128 in any context where an integer, arithmetic or scalar type is required to avoid a constraint violation, a diagnostic must be issued if __int128 is used. With the appropriate options chosen, does gcc issue the required diagnostics? I'd test it myself, but I'm very short of spare time right now. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-05-10 13:22 -0400 |
| Message-ID | <ntM3x.42259$rF4.2150@fx23.iad> |
| In reply to | #61823 |
On 5/10/15 12:20 PM, James Kuyper wrote: > On 04/28/2015 02:27 PM, Keith Thompson wrote: > ... >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49595 >> >> that's been resolved as "invalid". The response says that __int128 is >> not an "extended integer type" as defined by the C99 standard, and >> therefore the definition of [u]intmax_t needn't reflect its existence. >> That's true, but no real justification is given for the (permitted but >> IMHO flawed) decision to treat __int128 as an extension rather than as >> an extended integer type. A comment in the bug report claims that > > That's a perfectly feasible approach - but it has certain consequences: > if __int128 isn't an extended integer type (and it's certainly not a > standard integer type), it can't qualify as an integer type. The > standard doesn't allow for extended floating point types, so it can't > qualify as a floating point type (and probably wouldn't meet the > appropriate requirements if the standard did allow extended floating > point types). Therefore, it can't qualify as an arithmetic type, either. > By similar logic, it can't qualify as a scalar type. > > Therefore, any use of __int128 in any context where an integer, > arithmetic or scalar type is required to avoid a constraint violation, a > diagnostic must be issued if __int128 is used. > > With the appropriate options chosen, does gcc issue the required > diagnostics? I'd test it myself, but I'm very short of spare time right now. > Not diagnostic*s* but diagnostic. The standard makes no requirement to the number of diagnostics generated for an "incorrect" program. A compiler could just say "You have errors" if a constraint is violated and be conforming. There also is no requirement that diagnostic is an "error", so a perfectly conforming diagnostic would be: Info: __int128 used, printed just once per translation unit.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-10 18:44 +0100 |
| Message-ID | <mio5bo$kjl$1@dont-email.me> |
| In reply to | #61825 |
On 10/05/15 18:22, Richard Damon wrote: > On 5/10/15 12:20 PM, James Kuyper wrote: <snip> >> With the appropriate options chosen, does gcc issue the required >> diagnostics? I'd test it myself, but I'm very short of spare time right now. >> > > Not diagnostic*s* but diagnostic. I might beg to differ. :-) The term "diagnostics" is often used in the same grammatical sense as "statistics" or "pediatrics" (indeed, the Standard itself uses the word in that way], and so the way in which James used the word is perfectly correct (assuming that he meant it in that way). The word "diagnostic" is an adjective, not a noun. The term "issue a diagnostic" is a common one, and perhaps acceptable for that reason, but the proper term should be "issue a diagnostic message" (which is the way in which the Standard uses the term, when it is referring to the issuing of a message. If James meant "diagnostics" in the sense of a plural, however, then I agree with your correction. <snip> -- 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-10 11:12 -0700 |
| Message-ID | <87a8xcgv3p.fsf@kst-u.example.com> |
| In reply to | #61823 |
James Kuyper <jameskuyper@verizon.net> writes:
[...]
> Therefore, any use of __int128 in any context where an integer,
> arithmetic or scalar type is required to avoid a constraint violation, a
> diagnostic must be issued if __int128 is used.
>
> With the appropriate options chosen, does gcc issue the required
> diagnostics? I'd test it myself, but I'm very short of spare time right now.
Yes. With "gcc -std=cNN -pedantic" (where NN is 90, 99, or 11), it
warns:
c.c:2:5: warning: ISO C does not support ‘__int128’ type [-Wpedantic]
__int128 n = 0;
^
--
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-11 21:46 -0700 |
| Message-ID | <kfnh9ricsib.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61823 |
James Kuyper <jameskuyper@verizon.net> writes: > On 04/28/2015 02:27 PM, Keith Thompson wrote: > ... >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49595 >> >> that's been resolved as "invalid". The response says that __int128 is >> not an "extended integer type" as defined by the C99 standard, and >> therefore the definition of [u]intmax_t needn't reflect its existence. >> That's true, but no real justification is given for the (permitted but >> IMHO flawed) decision to treat __int128 as an extension rather than as >> an extended integer type. A comment in the bug report claims that > > That's a perfectly feasible approach - but it has certain consequences: > if __int128 isn't an extended integer type (and it's certainly not a > standard integer type), [snip] The last part there is ambiguous, and I'm not sure what is meant. It may be true that __int128 is not a standard integer type in a particular implementation, but __int128 can refer to a standard integer type in a(nother) conforming implementation.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-12 10:11 -0700 |
| Message-ID | <873831g1pf.fsf@kst-u.example.com> |
| In reply to | #61878 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> James Kuyper <jameskuyper@verizon.net> writes:
>> On 04/28/2015 02:27 PM, Keith Thompson wrote:
>> ...
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49595
>>>
>>> that's been resolved as "invalid". The response says that __int128 is
>>> not an "extended integer type" as defined by the C99 standard, and
>>> therefore the definition of [u]intmax_t needn't reflect its existence.
>>> That's true, but no real justification is given for the (permitted but
>>> IMHO flawed) decision to treat __int128 as an extension rather than as
>>> an extended integer type. A comment in the bug report claims that
>>
>> That's a perfectly feasible approach - but it has certain consequences:
>> if __int128 isn't an extended integer type (and it's certainly not a
>> standard integer type), [snip]
>
> The last part there is ambiguous, and I'm not sure what is meant.
> It may be true that __int128 is not a standard integer type in
> a particular implementation, but __int128 can refer to a standard
> integer type in a(nother) conforming implementation.
I was referring mostly to gcc. (A side point: __int128 isn't
supported on all targets.)
The standard integer types are _Bool and signed and unsigned char,
short, int, long, and long long. The integer types are those plus
any extended integer types. (Plain char doesn't seem to fit into
that scheme, which I find odd.)
__int128 could be the same type as long long, for example (it's in the
implementation's reserved namespace so it could be just about
*anything*). But there wouldn't be much point in defining it that way,
since it should also be int128_t. (That's me, not the standard, saying
it "should" be defined as in128_t.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 3 of 22 — ← Prev page 1 2 [3] 4 5 … 22 Next page →
Back to top | Article view | comp.lang.c
csiph-web