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 7 of 22 — ← Prev page 1 … 5 6 [7] 8 9 … 22 Next page →
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-05-20 11:58 -0500 |
| Message-ID | <mjie1u$avu$1@dont-email.me> |
| In reply to | #62349 |
Stephen Sprunk wrote:
> On 17-May-15 14:28, Bartc wrote:
>> On 17/05/2015 21:36, Stephen Sprunk wrote:
>>> On 17-May-15 09:02, Bartc wrote:
>>>> switch (c) { case UPPER:
>>>>
>>>> But, you still have write that lot in the first place, with the
>>>> same potential for mistakes, which will now be propagated
>>>> everywhere.
>>>
>>> Worse, now your lack of support for non-ASCII letters is hidden in
>>> some header file, rather than in the code where it belongs.
>>
>> So how would you code a single switch case to detect all 26 letters
>> of the alphabet? (And if you say use something other than a switch,
>> then that's side-stepping the issue.)
>
> Who says the user's alphabet has 26 letters--or that the user's script
> is an alphabet at all, or that the concept of "upper case" applies?
>
>> Anyway using a macro such as UPPER is one approach that can work
>> provided it's reliably defined, if there is no way to avoid
>> enumerating every single character. (Maybe you've noticed there's a
>> letter missing.) However this obviously needs to be done; it would be
>> better if it was built-in.
>
> It doesn't seem to be so "obvious" to those who work with languages
> other than English, i.e. the majority of humanity.
>
>>> That's part of why we have isupper() et al.
>>
>> What does it do with character codes 128 to 255? This is an unknown.
>> If I'm parsing some input and specifically need to detect A-Z, a-z,
>> 0-9 and a few extra, then it's not so useful.
>
> If you need to detect those _specific_ characters, and you can safely
> ignore the million or so other characters, then you can spend a minute
> or two writing the cases out--but I agree that "case 'A','B':" would be
> a nice syntactic shortcut for such code.
case 'A':
case 'B':
Oh so onerous :)
> We've already demonstrated why
> we can't have "case 'A'..'Z':", which I know is what you really want.
>
If you want Pascal, use Pascal. Royal "you" there, not pointed at Stephen.
> OTOH, if what you really want is to detect letters and numbers in
> general, then there are various is*() functions that are far better for
> that purpose than anything the average programmer will come up with,
+1
> and
> IMHO we shouldn't tempt him away from the correct solution by offering a
> better way to do the incorrect solution.
>
> S
>
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2015-05-20 14:00 -0700 |
| Message-ID | <662af1c4-4aff-4810-9a67-b913281fab59@googlegroups.com> |
| In reply to | #62355 |
On Wednesday, 20 May 2015 17:52:26 UTC+1, Les Cargill wrote: > Stephen Sprunk wrote: > > or two writing the cases out--but I agree that "case 'A','B':" would be > > a nice syntactic shortcut for such code. > > > case 'A': > case 'B': > > Oh so onerous :) Try writing 26 of them. Or 100, if you want to detect the range 100 to 199 for example (or 100 to c. 209 with every tenth intermediate value skipped, just to forestall you suggesting using an 'if'). > > We've already demonstrated why > > we can't have "case 'A'..'Z':", which I know is what you really want. > > > > If you want Pascal, use Pascal. Royal "you" there, not pointed at Stephen. Pascal had some good stuff in it. But I can write 'A'..'Z' now, and I can make it compile under C. However I need to go to the trouble of superimposing a somewhat different language on top of it when it could be implemented so easily. Look, what exactly would happen if it /was/ available in C? Probably nothing. If you're worried about EBCDIC, then don't use it. (I understand that gcc may already have that extension, and the world doesn't seem to have ended yet.) If a program intended for ASCII is ever run on EBCDIC hardware, then there may indeed be a problem, but I suspect it will go wrong in a dozen other ways first, including not being able to compile at all (many C applications seem extremely fragile). (In the early 80s I was programming machines with Z80s with display systems based on ASCII codes for text. I was anyway coding font bitmaps and glyphs myself based on codes that I chose, which usually were ASCII (sometimes dropping to 6-bit, but A-Z were still consecutive). The chances of my code running on some IBM mainframe were miniscule. So why /shouldn't/ I write 'A'..'Z' and assume ASCII code points? As I said above, other things would break first, such as the graphics hardware being obsolete and incompatible anyway.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-05-20 18:10 -0500 |
| Message-ID | <mjj3qp$7g2$1@dont-email.me> |
| In reply to | #62369 |
bart4858@gmail.com wrote:
> On Wednesday, 20 May 2015 17:52:26 UTC+1, Les Cargill wrote:
>> Stephen Sprunk wrote:
>
>>> or two writing the cases out--but I agree that "case 'A','B':"
>>> would be a nice syntactic shortcut for such code.
>>
>>
>> case 'A': case 'B':
>>
>> Oh so onerous :)
>
> Try writing 26 of them. Or 100, if you want to detect the range 100
> to 199 for example (or 100 to c. 209 with every tenth intermediate
> value skipped, just to forestall you suggesting using an 'if').
>
Doctor, doctor, it hurts when I do that...
Declarative range checks and possibly tables spring to mind
as better approaches.
>>> We've already demonstrated why we can't have "case 'A'..'Z':",
>>> which I know is what you really want.
>>>
>>
>> If you want Pascal, use Pascal. Royal "you" there, not pointed at
>> Stephen.
>
> Pascal had some good stuff in it. But I can write 'A'..'Z' now, and
> I can make it compile under C. However I need to go to the trouble of
> superimposing a somewhat different language on top of it when it
> could be implemented so easily.
>
Sure. But it's not 'C' any more.
"switch" control in 'C' would compile to a jump table in
older compilers. Very handy when you were shaving every cycle.
Today, it's less of a thing.
> Look, what exactly would happen if it /was/ available in C? Probably
> nothing. If you're worried about EBCDIC, then don't use it. (I
> understand that gcc may already have that extension, and the world
> doesn't seem to have ended yet.)
>
Wouldn't hurt a thing, really. I think it's somewhat less concise than
"if (x<0) ; else if (x>100) ; else
{
}"
with the appropriate bracing/line breaks.
> If a program intended for ASCII is ever run on EBCDIC hardware, then
> there may indeed be a problem, but I suspect it will go wrong in a
> dozen other ways first, including not being able to compile at all
> (many C applications seem extremely fragile).
>
> (In the early 80s I was programming machines with Z80s with display
> systems based on ASCII codes for text. I was anyway coding font
> bitmaps and glyphs myself based on codes that I chose, which usually
> were ASCII (sometimes dropping to 6-bit, but A-Z were still
> consecutive).
>
> The chances of my code running on some IBM mainframe were miniscule.
> So why /shouldn't/ I write 'A'..'Z' and assume ASCII code points? As
> I said above, other things would break first, such as the graphics
> hardware being obsolete and incompatible anyway.)
>
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2015-05-21 00:57 -0700 |
| Message-ID | <de666fd0-b4e0-4f1f-adeb-7efc277c22fd@googlegroups.com> |
| In reply to | #62374 |
On Thursday, 21 May 2015 00:04:05 UTC+1, Les Cargill wrote: >Bart: > >> Oh so onerous :) > > > > Try writing 26 of them. Or 100, if you want to detect the range 100 > > to 199 for example (or 100 to c. 209 with every tenth intermediate > > value skipped, just to forestall you suggesting using an 'if'). > > > > Doctor, doctor, it hurts when I do that... > > Declarative range checks and possibly tables spring to mind > as better approaches. .... > Sure. But it's not 'C' any more. > > "switch" control in 'C' would compile to a jump table in > older compilers. Very handy when you were shaving every cycle. > Today, it's less of a thing. It's about being expressive. To check whether some value lies in one particular set of values or another, then 'switch' is a good way of coding that. A set will be some combination of single values and ranges. That can be concisely denoted by syntax such as case 10,12..20: instead of enumerating each value (and possibly getting one wrong, as happens with tedious repetition). (It can also be impossible when the endpoints of the range are symbols or expressions). It can still be C. But the intention can be taken in at a glance. It's not good when you have to start looking at workarounds because the language doesn't support what you want to do. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-05-21 12:40 -0500 |
| Message-ID | <mjl4t9$pgj$1@dont-email.me> |
| In reply to | #62391 |
bart4858@gmail.com wrote: > On Thursday, 21 May 2015 00:04:05 UTC+1, Les Cargill wrote: >> Bart: > >>>> Oh so onerous :) >>> >>> Try writing 26 of them. Or 100, if you want to detect the range 100 >>> to 199 for example (or 100 to c. 209 with every tenth intermediate >>> value skipped, just to forestall you suggesting using an 'if'). >>> >> >> Doctor, doctor, it hurts when I do that... >> >> Declarative range checks and possibly tables spring to mind >> as better approaches. > .... >> Sure. But it's not 'C' any more. >> >> "switch" control in 'C' would compile to a jump table in >> older compilers. Very handy when you were shaving every cycle. >> Today, it's less of a thing. > > It's about being expressive. To check whether some value lies > in one particular set of values or another, then 'switch' is > a good way of coding that. > > A set will be some combination of single values and ranges. > That can be concisely denoted by syntax such as case 10,12..20: > instead of enumerating each value (and possibly getting one > wrong, as happens with tedious repetition). (It can also be > impossible when the endpoints of the range are symbols or > expressions). It can still be C. But the intention can be taken > in at a glance. > When I've run into cases where I felt there was risk from this - around 200 values it starts to be pretty painful - I'd write something in a scripting language to generate the overall structure. If it gets big enough, it's worth thinking in tables. Having a bespoke switch with even dozens of labels is probably doing it wrong. > It's not good when you have to start looking at workarounds > because the language doesn't support what you want to do. > > Sure. So maybe 'C' is not for you. I don't mean that to sound elitist, but if it bothers you, use something else. IMO, you ( or at least I ) see what happened with C++. It seemed like a good idea at the time... -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2015-05-21 13:25 -0700 |
| Message-ID | <ab71ac94-14cd-4c6d-bc53-91da96572e5a@googlegroups.com> |
| In reply to | #62420 |
On Thursday, 21 May 2015 18:34:46 UTC+1, Les Cargill wrote: > bart....@gmail.com wrote: > > A set will be some combination of single values and ranges. > > That can be concisely denoted by syntax such as case 10,12..20: > > instead of enumerating each value (and possibly getting one > > wrong, as happens with tedious repetition). (It can also be > > impossible when the endpoints of the range are symbols or > > expressions). It can still be C. But the intention can be taken > > in at a glance. > If it gets big enough, it's worth thinking in tables. Having > a bespoke switch with even dozens of labels is probably doing > it wrong. Tell that to the people who wrote CPython; the main dispatch loop is a giant switch. (Although you can't recognise it beneath a mess of multi-layered macros.) > > It's not good when you have to start looking at workarounds > > because the language doesn't support what you want to do. > > > > > > Sure. So maybe 'C' is not for you. I don't mean that to sound > elitist, but if it bothers you, use something else. I have done and I do. But I also have to be involved with C from time to time. My OS uses APIs defined in C for example. > IMO, you ( or at least I ) see what happened with C++. > It seemed like a good idea at the time... I agree. But I reckon I know how to make modest enhancements to a language without turning it a huge, incomprehensible mess that no single person understands fully. (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 The resulting language is still low-level (it does what C does). Most features are straightforward to implement, although not all can be retro-fitted into C easily. The 'switch' features mentioned in this thread are #45 and #46 in the list.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-21 14:33 -0700 |
| Message-ID | <874mn5ty3y.fsf@kst-u.example.com> |
| In reply to | #62430 |
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
>
> The resulting language is still low-level (it does what C does).
> Most features are straightforward to implement, although not all
> can be retro-fitted into C easily.
>
> The 'switch' features mentioned in this thread are #45 and #46
> in the list.)
Interesting. I like quite a few of these features.
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.
8 Numeric literals can have separators (either _ ' or `)
I can imagine ' and ` causing syntactic ambiguities. If I were
designing a language (I'm not), I'd just use a single character; I don't
see providing multiple choices as an advantage in this particular case.
9 Large integer literals don't need L LL or other suffixes except to
designate type
How does that differ from C? For example, an unsuffixed decimal
constant is of type int, long int, or long long int, depending on its
value.
11 Exact-width integer types can be specified via syntax, as int:N
for N bits, or int*N for N bytes wide.
Another case where multiple options are IMHO not helpful. I'd probably
stick to the ":N" syntax. (I presume N has to be a constant?)
14 Exact-width floating point types available, eg. real:64 or real*8
(this comes from an old Fortran dialect)
The size of a floating-point type doesn't completely describe it. It's
also not the most important characteristic for a programmer. I care
about precision and range; the compiler can figure out how many bytes
are needed.
Ada's syntax is, for example:
type Real is digits 6 range -1.0e100 .. +1.0e100;
But whatever syntax you have is probably just going to select one of two
or three supported formats.
17 Arrays are value types (however there are no array ops other than
assignment and equality, same as structs)
Arrays are tricky. What happens if you try to compare or assign two
arrays of different lengths?
19 Arrays and pointers are distinct types. To pass an array to a
function, usually a pointer to the array type (not element type)
is needed
Arrays and pointers are distinct types in C.
If a function has a parameter of pointer-to-array type, can it accept a
pointer to an array of any length? Are there distinct types "pointer to
array of ints" and "pointer to array of 42 ints"?
40 Loop controls 'break' and 'continue' (I call them 'exit' and
'next') work with multi-level loops using an index
If you support calling C functions, making "exit" a keyword might cause
problems.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-05-22 09:11 +0200 |
| Message-ID | <mjmkp3$ke$1@dont-email.me> |
| In reply to | #62433 |
On 21/05/15 23: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 >> >> The resulting language is still low-level (it does what C does). >> Most features are straightforward to implement, although not all >> can be retro-fitted into C easily. >> >> The 'switch' features mentioned in this thread are #45 and #46 >> in the list.) > > Interesting. I like quite a few of these features. > > 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. I don't think I have seen proposals to at 0b1101 constants to the C standards, but it is a very common extension which has been supported in gcc and clang (and many embedded compilers) for many years. Since it is a supported /de facto/ standard in C, and a standard in C++, it will probably turn up in the C standards eventually - it should be just a matter of paperwork. I certainly don't see competing formats like 2x1101 or 1101B being used. > > 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. Personally, I would rather see octal support being dropped entirely. I know that's not going to happen - but hopefully compilers will one day have optional warnings to detect them (I know of some compilers that already do). > > 8 Numeric literals can have separators (either _ ' or `) > > I can imagine ' and ` causing syntactic ambiguities. If I were > designing a language (I'm not), I'd just use a single character; I don't > see providing multiple choices as an advantage in this particular case. > C++14 has ' as a digit separator. Many people would have preferred _, but that's the one that got chosen. It is not unlikely that C (or at least, C compilers) will follow. > 9 Large integer literals don't need L LL or other suffixes except to > designate type > > How does that differ from C? For example, an unsuffixed decimal > constant is of type int, long int, or long long int, depending on its > value. > > 11 Exact-width integer types can be specified via syntax, as int:N > for N bits, or int*N for N bytes wide. > > Another case where multiple options are IMHO not helpful. I'd probably > stick to the ":N" syntax. (I presume N has to be a constant?) > > 14 Exact-width floating point types available, eg. real:64 or real*8 > (this comes from an old Fortran dialect) > > The size of a floating-point type doesn't completely describe it. It's > also not the most important characteristic for a programmer. I care > about precision and range; the compiler can figure out how many bytes > are needed. For some uses, exact sizes /are/ important. A good option would be to have a <stdfloat.h> like <stdint.h>, defining float32_t and float64_t (and optionally float128_t, or others that people might find useful) with the requirement that they are the given size, and in standard IEEE formats (just as int32_t must be two's complement as well as being 32 bits). That would cover both requirements. > > Ada's syntax is, for example: > type Real is digits 6 range -1.0e100 .. +1.0e100; > > But whatever syntax you have is probably just going to select one of two > or three supported formats. > > 17 Arrays are value types (however there are no array ops other than > assignment and equality, same as structs) > > Arrays are tricky. What happens if you try to compare or assign two > arrays of different lengths? > > 19 Arrays and pointers are distinct types. To pass an array to a > function, usually a pointer to the array type (not element type) > is needed > > Arrays and pointers are distinct types in C. > > If a function has a parameter of pointer-to-array type, can it accept a > pointer to an array of any length? Are there distinct types "pointer to > array of ints" and "pointer to array of 42 ints"? > > 40 Loop controls 'break' and 'continue' (I call them 'exit' and > 'next') work with multi-level loops using an index > > If you support calling C functions, making "exit" a keyword might cause > problems. >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-22 08:15 -0700 |
| Message-ID | <87zj4wskxq.fsf@kst-u.example.com> |
| In reply to | #62439 |
David Brown <david.brown@hesbynett.no> writes:
> On 21/05/15 23:33, Keith Thompson wrote:
[...]
>> 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.
>
> Personally, I would rather see octal support being dropped entirely. I
> know that's not going to happen - but hopefully compilers will one day
> have optional warnings to detect them (I know of some compilers that
> already do).
I'd miss being able to use 0. 8-)}
>> 8 Numeric literals can have separators (either _ ' or `)
>>
>> I can imagine ' and ` causing syntactic ambiguities. If I were
>> designing a language (I'm not), I'd just use a single character; I don't
>> see providing multiple choices as an advantage in this particular case.
>>
>
> C++14 has ' as a digit separator. Many people would have preferred _,
> but that's the one that got chosen. It is not unlikely that C (or at
> least, C compilers) will follow.
I think C++14 uses ' because it uses _ for user-defined literals. IMHO
that's a pity; there's ample precedent for using _ as a digit separator,
and I would have liked to see the same thing in C and C++.
[...]
>> 14 Exact-width floating point types available, eg. real:64 or real*8
>> (this comes from an old Fortran dialect)
>>
>> The size of a floating-point type doesn't completely describe it. It's
>> also not the most important characteristic for a programmer. I care
>> about precision and range; the compiler can figure out how many bytes
>> are needed.
>
> For some uses, exact sizes /are/ important. A good option would be to
> have a <stdfloat.h> like <stdint.h>, defining float32_t and float64_t
> (and optionally float128_t, or others that people might find useful)
> with the requirement that they are the given size, and in standard IEEE
> formats (just as int32_t must be two's complement as well as being 32
> bits). That would cover both requirements.
In that case it's not the size that's important, it's the size *and the
representation*.
In C implementations that support Annex F, float and double are reuqired
to be IEEE 32-bit and 64-bit, respectively. The requirements for long
double are less strict.
It might make sense to have a <stdfloat.h> header that defines types
guaranteed to match the IEEE formats.
[...]
--
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 | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-22 11:47 -0500 |
| Message-ID | <mjnmh4$uoc$1@dont-email.me> |
| In reply to | #62446 |
On 22-May-15 10:15, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> C++14 has ' as a digit separator. Many people would have preferred >> _, but that's the one that got chosen. It is not unlikely that C >> (or at least, C compilers) will follow. > > I think C++14 uses ' because it uses _ for user-defined literals. > IMHO that's a pity; there's ample precedent for using _ as a digit > separator, and I would have liked to see the same thing in C and > C++. There's plenty of room for debate about which new features of C++ that we should backport into C, but once we've decided to do so, IMHO C should, to the extent possible, strive to be compatible with the C-like subset of C++ (and vice versa, when applicable). For the record, I'm also in favor of cleaning up existing differences, e.g. type of character literals, constness of string literals, etc., not because any of them are important in and of themselves but because any differences make it harder for the many people who need to compile the same code (typically header files, but not always) in both languages. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-22 12:11 -0700 |
| Message-ID | <87vbfkqvga.fsf@kst-u.example.com> |
| In reply to | #62452 |
Stephen Sprunk <stephen@sprunk.org> writes:
> On 22-May-15 10:15, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> C++14 has ' as a digit separator. Many people would have preferred
>>> _, but that's the one that got chosen. It is not unlikely that C
>>> (or at least, C compilers) will follow.
>>
>> I think C++14 uses ' because it uses _ for user-defined literals.
>> IMHO that's a pity; there's ample precedent for using _ as a digit
>> separator, and I would have liked to see the same thing in C and
>> C++.
>
> There's plenty of room for debate about which new features of C++ that
> we should backport into C, but once we've decided to do so, IMHO C
> should, to the extent possible, strive to be compatible with the C-like
> subset of C++ (and vice versa, when applicable).
I agree.
> For the record, I'm also in favor of cleaning up existing differences,
> e.g. type of character literals, constness of string literals, etc., not
> because any of them are important in and of themselves but because any
> differences make it harder for the many people who need to compile the
> same code (typically header files, but not always) in both languages.
I'd like string literals to be const, but it would break some existing
code. Dropping implicit int did that too, but it was easier to fix the
code. If the next standard made string literals const, a lot of users
would either stick with the older standard or use compilers that are
non-conforming to the new standard.
Changing the type of character literals wouldn't break as much code --
but there aren't many cases where it matters. In most cases, character
literals are implicitly converted to the required type anyway. (It
matters in C++ because of overloading.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-05-23 07:26 +1200 |
| Message-ID | <cs9e7gF78edU1@mid.individual.net> |
| In reply to | #62465 |
Keith Thompson wrote: > > I'd like string literals to be const, but it would break some existing > code. Dropping implicit int did that too, but it was easier to fix the > code. If the next standard made string literals const, a lot of users > would either stick with the older standard or use compilers that are > non-conforming to the new standard. Wouldn't making string literals const simply cause already broken code to fail to compile, rather than break currently correct code? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-22 14:14 -0700 |
| Message-ID | <87iobkqpqq.fsf@kst-u.example.com> |
| In reply to | #62466 |
Ian Collins <ian-news@hotmail.com> writes:
> Keith Thompson wrote:
>> I'd like string literals to be const, but it would break some existing
>> code. Dropping implicit int did that too, but it was easier to fix the
>> code. If the next standard made string literals const, a lot of users
>> would either stick with the older standard or use compilers that are
>> non-conforming to the new standard.
>
> Wouldn't making string literals const simply cause already broken
> code to fail to compile, rather than break currently correct code?
Not entirely. The code that would be broken is probably poor style, but
it's perfectly valid.
This program:
#include <stdio.h>
void print_string(char *s) {
puts(s);
}
int main(void) {
print_string("hello");
return 0;
}
is strictly conforming under C90, C99, and C11 (I'm assuming the
possibility of puts() failing doesn't affect strict conformance).
It would be better to define the parameter `s` as `const char *s`, but
as long as the function *doesn't* modify the string there's no
actual problem.
(Prior to C89, there was no "const" keyword; making string literals
const would have broken all pre-ANSI programs that passed string
literals to functions.)
gcc's "-Wwrite-strings" option makes it warn about the above program.
Combined with "-pedantic-errors", it makes gcc non-conforming.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-05-23 09:28 +1200 |
| Message-ID | <cs9lcdFjvmaU3@mid.individual.net> |
| In reply to | #62470 |
Keith Thompson wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> Keith Thompson wrote:
>>> I'd like string literals to be const, but it would break some existing
>>> code. Dropping implicit int did that too, but it was easier to fix the
>>> code. If the next standard made string literals const, a lot of users
>>> would either stick with the older standard or use compilers that are
>>> non-conforming to the new standard.
>>
>> Wouldn't making string literals const simply cause already broken
>> code to fail to compile, rather than break currently correct code?
>
> Not entirely. The code that would be broken is probably poor style, but
> it's perfectly valid.
>
> This program:
>
> #include <stdio.h>
>
> void print_string(char *s) {
> puts(s);
> }
>
> int main(void) {
> print_string("hello");
> return 0;
> }
>
> is strictly conforming under C90, C99, and C11 (I'm assuming the
> possibility of puts() failing doesn't affect strict conformance).
> It would be better to define the parameter `s` as `const char *s`, but
> as long as the function *doesn't* modify the string there's no
> actual problem.
>
> (Prior to C89, there was no "const" keyword; making string literals
> const would have broken all pre-ANSI programs that passed string
> literals to functions.)
>
> gcc's "-Wwrite-strings" option makes it warn about the above program.
> Combined with "-pedantic-errors", it makes gcc non-conforming.
Non-conforming but a sensible combination none the less! I remember the
amount of cruft that was flushed out of the old Solaris code bases when
the compilers changed to make string literals read only.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-05-22 21:36 -0500 |
| Message-ID | <mjooli$nkg$1@dont-email.me> |
| In reply to | #62471 |
Ian Collins wrote:
> Keith Thompson wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>> Keith Thompson wrote:
>>>> I'd like string literals to be const, but it would break some existing
>>>> code. Dropping implicit int did that too, but it was easier to fix the
>>>> code. If the next standard made string literals const, a lot of users
>>>> would either stick with the older standard or use compilers that are
>>>> non-conforming to the new standard.
>>>
>>> Wouldn't making string literals const simply cause already broken
>>> code to fail to compile, rather than break currently correct code?
>>
>> Not entirely. The code that would be broken is probably poor style, but
>> it's perfectly valid.
>>
>> This program:
>>
>> #include <stdio.h>
>>
>> void print_string(char *s) {
>> puts(s);
>> }
>>
>> int main(void) {
>> print_string("hello");
>> return 0;
>> }
>>
>> is strictly conforming under C90, C99, and C11 (I'm assuming the
>> possibility of puts() failing doesn't affect strict conformance).
>> It would be better to define the parameter `s` as `const char *s`, but
>> as long as the function *doesn't* modify the string there's no
>> actual problem.
>>
>> (Prior to C89, there was no "const" keyword; making string literals
>> const would have broken all pre-ANSI programs that passed string
>> literals to functions.)
>>
>> gcc's "-Wwrite-strings" option makes it warn about the above program.
>> Combined with "-pedantic-errors", it makes gcc non-conforming.
>
> Non-conforming but a sensible combination none the less!
Yes.
> I remember the
> amount of cruft that was flushed out of the old Solaris code bases when
> the compilers changed to make string literals read only.
>
I have to wonder how many defects were found in that way.
Maybe it's a bit rude, but I consider the mixing of buffers
and literals conceptually to be an excellent way to write lots
of Heisenbugs. I've fixed lots of those; you know they happened,
and nobody seems to have caught them at it.
To wit:
char z[] = "Hello ";
printf("%s\n",strcat(z," in there."));
That may not even crash. It *should*, but you never know.
--
Les Cargill
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <pc+usenet@asdf.org> |
|---|---|
| Date | 2015-05-25 11:36 +0300 |
| Message-ID | <87zj4tqcj9.fsf@bazspaz.fatphil.org> |
| In reply to | #62446 |
Keith Thompson <kst-u@mib.org> writes: > David Brown <david.brown@hesbynett.no> writes: > > On 21/05/15 23:33, Keith Thompson wrote: > [...] > >> 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. > > > > Personally, I would rather see octal support being dropped entirely. I > > know that's not going to happen - but hopefully compilers will one day > > have optional warnings to detect them (I know of some compilers that > > already do). > > I'd miss being able to use 0. 8-)} Were octal contants outlawed, you'd still be able to use 0, as it would be a decimal constant instead. Defaulting to octal I never liked. I'd have been happier with 0c755 (and I like 0b... likewise). Alas it's too late to change now. 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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-22 14:16 +0100 |
| Message-ID | <mjna5l$duf$1@dont-email.me> |
| In reply to | #62433 |
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.)
> 8 Numeric literals can have separators (either _ ' or `)
>
> I can imagine ' and ` causing syntactic ambiguities. If I were
> designing a language (I'm not), I'd just use a single character; I don't
> see providing multiple choices as an advantage in this particular case.
Yeah, but which one? Allowing several means that data source can be
pasted directly from other languages; some might use ', others _
>
> 9 Large integer literals don't need L LL or other suffixes except to
> designate type
>
> How does that differ from C? For example, an unsuffixed decimal
> constant is of type int, long int, or long long int, depending on its
> value.
TBH I don't know exactly what the rules are in C. I know that sometimes
odd compiler errors go away if I put a suffix in.
>
> 11 Exact-width integer types can be specified via syntax, as int:N
> for N bits, or int*N for N bytes wide.
>
> Another case where multiple options are IMHO not helpful. I'd probably
> stick to the ":N" syntax. (I presume N has to be a constant?)
Again, this allows people to choose a style they prefer. So long as it's
consistent within the same code, I can't see that it's a problem. So a
32-bit signed int can be expressed as any of:
int:32 int*4 int32 i32
Don't forget that C also allows:
int, signed int, int signed, signed and int32_t
(with even more variations if you introduce long, short, unsigned and
const.)
> (I presume N has to be a constant?)
It has to be a number, macro, or constant expression. But usually a
colloquial name is used ('byte'), or a name without : or * (int16).
> 14 Exact-width floating point types available, eg. real:64 or real*8
> (this comes from an old Fortran dialect)
>
> The size of a floating-point type doesn't completely describe it. It's
> also not the most important characteristic for a programmer. I care
> about precision and range; the compiler can figure out how many bytes
> are needed.
> Ada's syntax is, for example:
> type Real is digits 6 range -1.0e100 .. +1.0e100;
>
> But whatever syntax you have is probably just going to select one of two
> or three supported formats.
It's too easy designing something and ending up with something like Ada!
And I know my limits. With floating point, in practice you're going to
get 32 or 64 bit IEEE floats. And you will normally just use 'real'
(64-bit) unless the design or interface calls for a short version.
> 17 Arrays are value types (however there are no array ops other than
> assignment and equality, same as structs)
>
> Arrays are tricky. What happens if you try to compare or assign two
> arrays of different lengths?
You just get a type error. (However lower bounds have to match too; I
might look into that.)
> 19 Arrays and pointers are distinct types. To pass an array to a
> function, usually a pointer to the array type (not element type)
> is needed
>
> Arrays and pointers are distinct types in C.
>
> If a function has a parameter of pointer-to-array type, can it accept a
> pointer to an array of any length? Are there distinct types "pointer to
> array of ints" and "pointer to array of 42 ints"?
The array is just unbounded like the equivalent (but rarely used) C version:
proc fn(ref[]int a) = ... # pointer to array of int
(I won't attempt the C version because I will get it wrong.)
> 40 Loop controls 'break' and 'continue' (I call them 'exit' and
> 'next') work with multi-level loops using an index
>
> If you support calling C functions, making "exit" a keyword might cause
> problems.
That's part of a larger set of problems with trying to use C libraries,
where I have to duplicate what's in the corresponding header files.
Sometimes it's easier to write an intermediate module in actual C, but
with a simpler interface that I specify. Then I can call exit()
indirectly via my_exit() in the C helper module.
If it's just name clashes with C runtime functions, sometimes I can
write clib.printf() to distinguish from a local printf. But with 'exit'
being a keyword, that doesn't work. However defining it as _exit() seems
to work under Windows.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-22 08:38 -0700 |
| Message-ID | <87vbfksjvc.fsf@kst-u.example.com> |
| In reply to | #62441 |
Bartc <bc@freeuk.com> writes:
> On 21/05/2015 22:33, Keith Thompson wrote:
[...]
>> 8 Numeric literals can have separators (either _ ' or `)
>>
>> I can imagine ' and ` causing syntactic ambiguities. If I were
>> designing a language (I'm not), I'd just use a single character; I don't
>> see providing multiple choices as an advantage in this particular case.
>
> Yeah, but which one? Allowing several means that data source can be
> pasted directly from other languages; some might use ', others _
If there are three different ways to write a numeric literal,
programmers are going to use all three. In my opinion, that's not
a good thing, and the minor advantage of the added flexibility is
IMHO outweighed by the potential confusion.
A minor point; Markdown uses the backtick to delimit code. Using it as
part of your language syntax could make it slightly more difficult to
discuss in some forums.
Of course it's your language, and my opinion probably shouldn't
count for much.
>> 9 Large integer literals don't need L LL or other suffixes except to
>> designate type
>>
>> How does that differ from C? For example, an unsuffixed decimal
>> constant is of type int, long int, or long long int, depending on its
>> value.
>
> TBH I don't know exactly what the rules are in C. I know that
> sometimes odd compiler errors go away if I put a suffix in.
It can be necessary in expressions. For example `1000 * 1000` will
overflow if int is 16 bits; you can write `1000L * 1000L` to avoid that.
>> 11 Exact-width integer types can be specified via syntax, as int:N
>> for N bits, or int*N for N bytes wide.
>>
>> Another case where multiple options are IMHO not helpful. I'd probably
>> stick to the ":N" syntax. (I presume N has to be a constant?)
>
> Again, this allows people to choose a style they prefer. So long as
> it's consistent within the same code, I can't see that it's a
> problem.
It *won't* always be consistent within the same code, unless each
program is written by one and only one person who never changes his or
her mind.
> So a 32-bit signed int can be expressed as any of:
>
> int:32 int*4 int32 i32
>
> Don't forget that C also allows:
>
> int, signed int, int signed, signed and int32_t
>
> (with even more variations if you introduce long, short, unsigned and
> const.)
int32_t doesn't belong in that list.
Again, in my opinion a language shouldn't provide multiple ways to
express the same thing *unless* there's some real expressive advantage
to doing so. If there's only one way to do it, code is easier to read.
(Ironically, I'm a big fan of Perl, whose motto is TMTOWTDI, "There's
more than one way to do it". I never claimed to be entirely
consistent.)
[...]
> It's too easy designing something and ending up with something like
> Ada!
I think the designers of Ada would disagree with that!
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-05-22 18:06 +0100 |
| Message-ID | <mjnnk1$39r$1@dont-email.me> |
| In reply to | #62448 |
On 22/05/2015 16:38, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: >> On 21/05/2015 22:33, Keith Thompson wrote: > [...] >>> 8 Numeric literals can have separators (either _ ' or `) >>> >>> I can imagine ' and ` causing syntactic ambiguities. If I were >>> designing a language (I'm not), I'd just use a single character; I don't >>> see providing multiple choices as an advantage in this particular case. >> >> Yeah, but which one? Allowing several means that data source can be >> pasted directly from other languages; some might use ', others _ > > If there are three different ways to write a numeric literal, > programmers are going to use all three. I think I've used two separator styles in the same number, the extra one to superimpose some extra structure or meaning on top of the normal 3- and 4-digit groups. People will take advantage however even with a single separator character, unless you impose restrictions: 0__________________1_2__3___4____5_____6______7_______8 > A minor point; Markdown uses the backtick to delimit code. Using it as > part of your language syntax could make it slightly more difficult to > discuss in some forums. I can't remember why I allowed the back-tick, as single quote is also a available without shifting. >> So a 32-bit signed int can be expressed as any of: >> >> int:32 int*4 int32 i32 >> >> Don't forget that C also allows: >> >> int, signed int, int signed, signed and int32_t >> >> (with even more variations if you introduce long, short, unsigned and >> const.) > > int32_t doesn't belong in that list. Well, OK, but the point is that signed, unsigned, const, long, short, int and so on can appear in any order. Sometimes you can leave something out, so that 'signed short int', 'short signed int' and just 'short' all mean the same thing. So if you're talking about different ways of specifying the same thing, C has got it down to a fine art! What I'm doing is providing an orthogonal set of different styles, you just choose the column you like: word:8 word*1 word8 u8 byte word:16 word*2 word16 u16 halfword (I've just made this up..) word:32 word*4 word32 u32 word word:64 word*8 word64 u64 dword int:8 int*1 int8 i8 int:16 int*2 int16 i16 halfint (..and this) int:32 int*4 int32 i32 int int:64 int*8 int64 i64 dint real:32 real*4 real32 r32 real:64 real*8 real64 r64 real char:8 char*1 char8 c8 char char:16 char*2 char16 c16 char:32 char*4 char32 c32 bit:1 bit*1 bit (u1) bit (also word:1, etc) bit:2 bit*2 bit2 (u2) bit:4 bit*4 bit4 (u4) 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. >> It's too easy designing something and ending up with something like >> Ada! > > I think the designers of Ada would disagree with that! I wasn't criticising it. I mean if you take some things to their logical conclusion, you might end up with something as comprehensive as Ada. So specifying types by ranges, you will eventually end up with Ada's type system if done properly. I admire Ada but this is intended to be a low level language with a simple type system. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-22 13:56 -0700 |
| Message-ID | <87r3q8qqla.fsf@kst-u.example.com> |
| In reply to | #62455 |
Bartc <bc@freeuk.com> writes:
> On 22/05/2015 16:38, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
[...]
>>> Don't forget that C also allows:
>>>
>>> int, signed int, int signed, signed and int32_t
>>>
>>> (with even more variations if you introduce long, short, unsigned and
>>> const.)
>>
>> int32_t doesn't belong in that list.
>
> Well, OK, but the point is that signed, unsigned, const, long, short,
> int and so on can appear in any order. Sometimes you can leave
> something out, so that 'signed short int', 'short signed int' and just
> short' all mean the same thing.
>
> So if you're talking about different ways of specifying the same
> thing, C has got it down to a fine art!
Sure -- but why repeat C's mistakes?
> What I'm doing is providing an orthogonal set of different styles, you
> just choose the column you like:
>
> word:8 word*1 word8 u8 byte
> word:16 word*2 word16 u16 halfword (I've just made this up..)
> word:32 word*4 word32 u32 word
> word:64 word*8 word64 u64 dword
> int:8 int*1 int8 i8
> int:16 int*2 int16 i16 halfint (..and this)
> int:32 int*4 int32 i32 int
> int:64 int*8 int64 i64 dint
> real:32 real*4 real32 r32
> real:64 real*8 real64 r64 real
> char:8 char*1 char8 c8 char
> char:16 char*2 char16 c16
> char:32 char*4 char32 c32
> bit:1 bit*1 bit (u1) bit (also word:1, etc)
> bit:2 bit*2 bit2 (u2)
> bit:4 bit*4 bit4 (u4)
>
> 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. (An I correct in assuming that your language,
unlike C, assumes 8-bit bytes?)
[...]
--
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 7 of 22 — ← Prev page 1 … 5 6 [7] 8 9 … 22 Next page →
Back to top | Article view | comp.lang.c
csiph-web