Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #43061 > unrolled thread
| Started by | "BartC" <bc@freeuk.com> |
|---|---|
| First post | 2014-04-18 11:45 +0100 |
| Last post | 2014-04-21 09:08 +0200 |
| Articles | 20 on this page of 280 — 25 participants |
Back to article view | Back to comp.lang.c
Constant strings "BartC" <bc@freeuk.com> - 2014-04-18 11:45 +0100
Re: Constant strings Richard Damon <Richard@Damon-Family.org> - 2014-04-18 07:34 -0400
Re: Constant strings G G <gdotone@gmail.com> - 2014-04-18 05:23 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-18 17:16 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-18 11:08 -0700
Re: Constant strings G G <gdotone@gmail.com> - 2014-04-18 13:11 -0700
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-18 10:21 -0400
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-18 08:45 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-18 16:48 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-18 09:21 -0700
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-19 09:09 +1200
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-18 23:53 +0100
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-18 23:06 +0000
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-19 03:57 -0700
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-19 23:41 +1200
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-19 06:21 -0700
Re: Constant strings Barry Schwarz <schwarzb@dqel.com> - 2014-04-19 10:04 -0700
Re: Constant strings Barry Schwarz <schwarzb@dqel.com> - 2014-04-19 16:54 -0700
Re: Constant strings Seungbeom Kim <musiphil@bawi.org> - 2014-04-19 17:54 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-19 13:20 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-19 23:32 +0100
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-19 23:38 +0000
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-19 17:28 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-20 10:53 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-20 14:29 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-20 23:41 +0100
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-21 11:14 +1200
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-21 13:05 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-21 11:11 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-20 19:44 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-21 10:51 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-21 13:29 -0400
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-21 11:04 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 11:31 +0100
Re: Constant strings Martin Shobe <martin.shobe@yahoo.com> - 2014-04-22 06:24 -0500
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 13:34 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-22 09:19 -0400
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 15:00 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 07:53 -0700
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-22 12:48 -0400
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-22 07:28 -0400
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 05:46 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 07:45 -0700
Re: Constant strings Ike Naar <ike@iceland.freeshell.org> - 2014-04-22 16:34 +0000
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 10:10 -0700
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-22 11:50 -0500
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 18:48 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-22 14:02 -0400
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 19:48 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-22 15:28 -0400
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-22 19:48 -0500
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-23 11:56 +0100
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-23 12:59 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-23 08:21 -0400
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-23 14:09 +0100
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-23 14:19 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-23 08:40 -0400
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-23 11:56 -0400
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-23 11:10 -0700
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-23 19:19 -0500
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-23 19:19 -0700
Re: Constant strings Robert Wessel <robertwessel2@yahoo.com> - 2014-04-23 23:53 -0500
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-24 11:55 +0000
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-24 11:27 -0500
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-24 20:03 +0000
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-24 17:16 -0500
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-23 17:39 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-23 13:06 -0400
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-23 10:25 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-23 11:30 -0700
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-23 20:55 +0000
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-23 21:53 -0700
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-24 17:05 +1200
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-24 00:59 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-23 18:39 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-23 14:53 -0400
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-23 21:09 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-23 19:23 -0400
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-25 10:52 -0500
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-23 19:36 -0500
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-24 10:37 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-24 07:45 -0400
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-24 13:15 +0100
Re: Constant strings Martin Shobe <martin.shobe@yahoo.com> - 2014-04-24 08:33 -0500
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-24 09:47 -0400
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-24 15:09 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-24 12:07 -0400
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-24 18:23 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-24 14:49 -0400
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-24 13:48 -0500
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-24 12:32 -0700
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-24 23:57 -0500
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-25 08:31 -0400
Re: Constant strings Martin Shobe <martin.shobe@yahoo.com> - 2014-04-25 09:51 -0500
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-25 16:45 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-25 09:07 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-25 17:33 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-25 11:38 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-25 11:42 -0700
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-25 10:58 -0500
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-25 11:29 -0700
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-25 15:10 -0400
Re: Constant strings Martin Shobe <martin.shobe@yahoo.com> - 2014-04-25 19:06 -0500
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-26 05:39 -0400
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-26 04:07 -0700
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-26 12:50 +0100
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-26 05:03 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-26 11:23 -0700
Re: Constant strings gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-26 19:13 +0000
Re: Constant strings Richard <rgrdev_@gmail.com> - 2014-04-26 23:54 +0200
Re: Constant strings Richard Damon <Richard@Damon-Family.org> - 2014-04-26 18:47 -0400
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-26 23:01 +0000
Re: Constant strings Seungbeom Kim <musiphil@bawi.org> - 2014-04-26 18:09 -0700
Re: Constant strings gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-27 01:22 +0000
Re: Constant strings Richard <rgrdev_@gmail.com> - 2014-04-27 04:09 +0200
Re: Constant strings David Thompson <dave.thompson2@verizon.net> - 2014-05-25 16:44 -0400
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-05-25 14:43 -0700
Re: Constant strings Richard <rgrdev_@gmail.com> - 2014-04-27 04:09 +0200
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-27 05:36 +0000
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-27 06:42 -0700
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-27 02:42 +0000
Re: Constant strings Richard <rgrdev_@gmail.com> - 2014-04-27 04:45 +0200
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-27 14:13 -0500
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-27 20:11 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 03:22 +0100
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-28 10:00 +0100
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 11:24 +0100
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-28 12:30 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 13:58 +0100
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-28 12:22 +0000
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-28 08:53 -0700
Re: Constant strings gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-28 16:10 +0000
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 18:11 +0000
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-28 11:34 -0700
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-28 19:01 +0000
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-28 11:06 +0000
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-28 12:48 +0100
Re: Constant strings Richard Damon <Richard@Damon-Family.org> - 2014-04-28 08:11 -0400
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 14:04 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 12:55 +0100
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-28 13:23 +0100
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 13:47 +0100
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-28 06:01 -0700
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-29 08:43 +1200
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 21:08 +0000
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-29 09:32 +1200
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 22:41 +0100
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 22:00 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 23:18 +0100
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-28 15:43 -0700
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-28 23:23 +0000
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 22:47 +0000
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-28 23:17 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-29 01:18 +0100
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-29 00:31 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-29 01:58 +0100
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-29 01:13 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-29 03:19 +0100
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-29 03:31 +0000
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-29 04:21 +0000
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-29 04:29 +0000
Re: Constant strings Richard <rgrdev_@gmail.com> - 2014-04-29 09:14 +0200
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-29 14:05 +0100
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-29 00:37 -0700
Re: Constant strings Richard <rgrdev_@gmail.com> - 2014-04-29 13:36 +0200
Re: Constant strings ralph <nt_consulting@yahoo.com> - 2014-04-29 07:49 -0500
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-29 06:28 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-29 07:37 -0700
Re: Constant strings David Brown <david.brown@hesbynett.no> - 2014-04-29 17:15 +0200
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-29 20:58 +0000
Re: Constant strings David Brown <david.brown@hesbynett.no> - 2014-04-30 10:16 +0200
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-29 16:04 +0000
Re: Constant strings gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-29 16:10 +0000
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-29 09:58 -0700
Re: Constant strings Richard <rgrdev_@gmail.com> - 2014-04-30 12:46 +0200
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-29 14:51 +0000
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-29 16:05 +0000
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-29 01:53 +0000
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-28 23:11 +0000
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 23:29 +0000
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-29 00:18 +0000
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 21:52 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 23:08 +0100
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 22:31 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-29 00:54 +0100
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-28 23:10 +0100
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-29 11:28 +1200
Re: Constant strings gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-27 06:31 +0000
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-26 12:27 +0100
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-26 13:11 +0100
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-26 13:50 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-26 11:26 -0700
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-27 02:21 +0100
Re: Constant strings Martin Shobe <martin.shobe@yahoo.com> - 2014-04-26 08:05 -0500
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-26 11:39 -0700
Re: Constant strings Martin Shobe <martin.shobe@yahoo.com> - 2014-04-26 16:27 -0500
Re: Constant strings Ian Zimmerman <itz@buug.org> - 2014-04-27 10:46 -0700
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-26 22:46 -0400
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-27 10:08 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-27 07:35 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-27 16:35 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-27 12:28 -0700
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-27 12:36 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-27 23:14 -0400
Re: Constant strings Seungbeom Kim <musiphil@bawi.org> - 2014-04-26 18:03 -0700
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-27 02:33 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-24 07:49 -0700
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-25 03:03 +0100
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-25 22:50 +0100
Re: Constant strings Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2014-04-24 20:20 -0600
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-24 23:31 -0700
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-25 15:24 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-25 08:31 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-24 07:58 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-26 13:38 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-26 11:50 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-24 07:42 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-24 08:43 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-23 11:28 -0700
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-23 18:42 +0000
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-24 14:03 -0500
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-23 20:49 +0000
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-23 21:21 +0000
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-23 10:50 -0500
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-22 19:41 -0500
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 09:43 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 18:19 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 11:45 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 20:01 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 12:19 -0700
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-23 11:01 -0500
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-22 15:21 -0500
Re: Constant strings Richard <rgrdev_@gmail.com> - 2014-04-20 11:08 +0100
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 02:26 -0700
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-22 21:36 +1200
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 13:14 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 07:25 -0700
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 08:29 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 09:35 -0700
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 09:54 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 10:17 -0700
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 10:31 -0700
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 02:33 -0700
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-22 21:37 +1200
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 07:17 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-19 13:42 +0100
Re: Constant strings Ike Naar <ike@iceland.freeshell.org> - 2014-04-19 15:42 +0000
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-19 16:19 +0000
Re: Constant strings Seungbeom Kim <musiphil@bawi.org> - 2014-04-19 17:47 -0700
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-22 11:00 -0500
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 18:36 +0100
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-23 09:38 +1200
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 23:25 +0100
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-23 10:48 +1200
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-23 12:37 +0100
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-23 13:47 +0100
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-23 14:03 +0100
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-24 09:14 +1200
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-23 23:37 +0100
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-24 10:54 +1200
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-24 00:52 +0100
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-24 01:04 +0000
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-24 13:16 +1200
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-23 19:14 -0700
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-24 03:41 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-23 16:04 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-18 08:53 -0700
Re: Constant strings Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-20 16:02 -0700
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-18 16:13 +0000
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-18 18:34 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-18 11:06 -0700
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-18 18:54 +0000
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-18 14:15 -0700
Re: Constant strings Rosario193 <Rosario@invalid.invalid> - 2014-04-20 20:15 +0200
Re: Constant strings Rosario193 <Rosario@invalid.invalid> - 2014-04-20 22:13 +0200
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-20 14:31 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-20 14:30 -0700
Re: Constant strings Rosario193 <Rosario@invalid.invalid> - 2014-04-21 02:43 +0200
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-21 03:12 +0000
Re: Constant strings Rosario193 <Rosario@invalid.invalid> - 2014-04-21 09:08 +0200
Page 11 of 14 — ← Prev page 1 … 9 10 [11] 12 13 14 Next page →
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-27 16:35 +0100 |
| Message-ID | <tv97v.167842$Ey6.26793@fx24.am4> |
| In reply to | #43649 |
"Keith Thompson" <kst-u@mib.org> wrote in message news:lnlhuqrgb5.fsf@nuthaus.mib.org... > "BartC" <bc@freeuk.com> writes: >> This was sufficient to give a different diagnostic (when being passed as >> a >> void* parameter) on one well-known compiler. Not an official difference, >> but >> different behaviour nonetheless. > > Sorry, I'm confused. We're talking about the difference between an > array of const int and a (hypothetical) const array of int. There is no > const array of int in your example. What "different diagnostic" are you > referring to? I don't know how to do message links. This refers to my post in this thread, a reply to James Kuyper, dated 26-Apr-14 12:27 (GMT+1), and a follow-up (reply to Ben Bacarisse) at 13:50 GMT+1. To summarise, with standard gcc options, the compiler generated a warning when passing this array: const int A[3]; as the first parameter of memset(), when using A (pointer to const int), but not when using &A (pointer to array of const int). I suggested that a hypothetical 'pointer to const array of int' type here, would have helped it detect the use of a pointer to a read-only location (and therefore behave differently compared with 'pointer to array of const int). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-27 12:28 -0700 |
| Message-ID | <lnd2g2r2qc.fsf@nuthaus.mib.org> |
| In reply to | #43658 |
"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnlhuqrgb5.fsf@nuthaus.mib.org...
>> "BartC" <bc@freeuk.com> writes:
>>> This was sufficient to give a different diagnostic (when being
>>> passed as a void* parameter) on one well-known compiler. Not an
>>> official difference, but different behaviour nonetheless.
>>
>> Sorry, I'm confused. We're talking about the difference between an
>> array of const int and a (hypothetical) const array of int. There is no
>> const array of int in your example. What "different diagnostic" are you
>> referring to?
>
> I don't know how to do message links. This refers to my post in this thread,
> a reply to James Kuyper, dated 26-Apr-14 12:27 (GMT+1), and a follow-up
> (reply to Ben Bacarisse) at 13:50 GMT+1.
>
> To summarise, with standard gcc options, the compiler generated a warning
> when passing this array:
>
> const int A[3];
>
> as the first parameter of memset(), when using A (pointer to const int), but
> not when using &A (pointer to array of const int). I suggested that a
> hypothetical 'pointer to const array of int' type here, would have helped it
> detect the use of a pointer to a read-only location (and therefore behave
> differently compared with 'pointer to array of const int).
Interesting.
This program:
#include <string.h>
#include <stdio.h>
int main(void) {
const int arr[10] = { 0 };
memset(&arr, 0xff, sizeof arr);
printf("arr[0] = %d\n", arr[0]);
}
produces no warnings with gcc 4.9.0 (the latest version), but with clang
3.4:
clang -std=c11 -pedantic -Wall -Wextra -O3 c.c -o c
I get:
c.c:4:12: warning: passing 'const int (*)[10]' to parameter of type 'void *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
memset(&arr, 0xff, sizeof arr);
^~~~
/usr/include/string.h:65:28: note: passing argument to parameter '__s' here
extern void *memset (void *__s, int __c, size_t __n) __THROW __nonnull ((1));
^
1 warning generated.
It appears to me that gcc follows the letter of the standard, and clang
follows its intent.
The rules for argument passing and initialization are the same as for
simple assignment, at least for cases like this. N1570 6.5.16.1 says:
One of the following shall hold:
[...]
- the left operand has atomic, qualified, or unqualified pointer
type, and (considering the type the left operand would have after
lvalue conversion) one operand is a pointer to an object type, and
the other is a pointer to a qualified or unqualified version of
void, and the type pointed to by the left has all the qualifiers
of the type pointed to by the right;
[...]
The previous bullet, which I haven't quoted, applies when the left and
right operands point to compatible types rather than one of them
pointing to void.
If I'm understanding this correctly (and I'm not at all confident of
that), the solution would not be to create a distinction between array
of const FOO and const array of FOO, but to fix 6.5.16.1 so that the
qualifiers of an array's element type are considered rather than just
the qualifiers of the array type itself (and recursively for arrays of
arrays).
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-27 12:36 +0100 |
| Message-ID | <0.6aa98cf9756e09563298.20140427123611BST.87k3ab3syc.fsf@bsb.me.uk> |
| In reply to | #43637 |
James Kuyper <jameskuyper@verizon.net> writes: > On 04/26/2014 09:05 AM, Martin Shobe wrote: <snip> >> Not that I know of. That doesn't mean there isn't a difference to the >> users of the phrase. That just means the difference isn't extensional. > > I've looked up the term "extensional" > <http://en.wikipedia.org/wiki/Extensional>, which I've not seen used > with this meaning before. The definitions I found left me just as > confused about what you meant as I was before I read that definition. It might help to consider the meaning in (formal) logic which is probably closer to what Martin means: http://en.wikipedia.org/wiki/Extensionality Applying that definition directly to C long int a; signed long a; are different definitions, but the difference resides entirely in the definition itself, and is not manifest in any property of 'a' that a programmer might cares about. It would be reasonable to describe the two definitions as different, but not extensionally different. Using this context (where extensionality refers to differences in program semantics) non-extensional differences matter in programming. We carefully choose variable names thought it makes not a bit of difference to the semantics; people argue over 'if (2 == x)' vs. 'if (x == 2)' and even over the order of 'const int' vs 'int const'. However, because arrays play such a small role in the semantics of C, it is very hard to see the value in even the non-extensional (i.e. non-semantic) distinction between a const array and an array with const elements. <snip> > So, if someone believes that a const array of int is in some way > different from an array of const int, the are intensionally different, > even if that person is mistaken? I think it's more a matter of focus. When someone argues that it makes no difference if you write 2 == x or x == 2 they are probably thinking extensionally. They are intensionally different (in the technical sense) and some people care. Similarly, it is logically possible to imagine a situation in which some one might want to make the non-extensional distinction between and const array and an array of consts (though I can't think of one off hand). > If that's what you're talking about, > then I don't see any point in worrying about intensional differences; > only the extensional ones really matter to me. I think I've seen you argue for things that have no semantic consequences, such as expression order in equality tests, but the upshot is that there are two separate cases to be made: do the two notions differ in any way that is detectable within C, and are there any other reasons why the distinction might matter? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-27 23:14 -0400 |
| Message-ID | <ljkh1t$a3g$1@dont-email.me> |
| In reply to | #43643 |
On 04/27/2014 07:36 AM, Ben Bacarisse wrote: > James Kuyper <jameskuyper@verizon.net> writes: ... >> If that's what you're talking about, >> then I don't see any point in worrying about intensional differences; >> only the extensional ones really matter to me. > > I think I've seen you argue for things that have no semantic > consequences, such as expression order in equality tests, but the upshot Yes, I have, though in that particular case I argued for an order that does a better job of producing error messages when certain common types of mistakes are made. I'm not clear whether that counts as an extensional or intensional distinction - I do, however, consider it a practically useful one. On the flip side, while I presented an argument for that order, I've seldom actually used that order - in this case, the benefits to be too weak to even convince myself. A better example, and one that is closely related to this thread, is the fact that I follow a convention of using T* for function parameters that point to a single object, and T[] for function parameters that point at the first of a series of objects that are (or at least, might be) accessed by the function, even though there's not a single feature of C that cares about that distinction. I've never argued that such concerns were a strong argument for any particular coding style. > is that there are two separate cases to be made: do the two notions > differ in any way that is detectable within C, and are there any other > reasons why the distinction might matter? In C as it's currently written, there is no way to even use one of the two notions, much less identify a meaningful distinction between them. As Seungbeom Kim has already pointed out, 6.7.3p9 says "If the specification of an array type includes any type qualifiers, the element type is so-qualified, not the array type." The suggestion that was made was that an opportunity had been missed to make the C type system more consistent, which means it must be talking about a modified version of C. It must, at a minimum, be modified by removing section 6.7.3p9. But on top of that, I don't see it as much of a missed opportunity, unless that modified version of C also differed from current standard C by making the distinction matter for some reason. What I've been trying to identify is what people who feel this way think the distinction should be. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Seungbeom Kim <musiphil@bawi.org> |
|---|---|
| Date | 2014-04-26 18:03 -0700 |
| Message-ID | <ljhl0t$vjp$1@usenet.stanford.edu> |
| In reply to | #43507 |
On 2014-04-24 07:09, BartC wrote: > > So you can apply const to elements, but not to arrays (at least not > without the trick that Martin posted). Yes you can, though it might be considered to be a mere word play: (6.7.3/9) "If the specification of an array type includes any type qualifiers, the element type is so-qualified, not the array type." (And the footnote specifically mentions it can occur through typedefs.) So you can apply const to arrays, but the language just automatically transfers it to the elements. -- Seungbeom Kim
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-27 02:33 +0100 |
| Message-ID | <0.47a92c8de3aa3a2dffd8.20140427023340BST.87y4yr4kuj.fsf@bsb.me.uk> |
| In reply to | #43627 |
Seungbeom Kim <musiphil@bawi.org> writes: > On 2014-04-24 07:09, BartC wrote: >> >> So you can apply const to elements, but not to arrays (at least not >> without the trick that Martin posted). > > Yes you can, though it might be considered to be a mere word play: > > (6.7.3/9) "If the specification of an array type includes any type > qualifiers, the element type is so-qualified, not the array type." > (And the footnote specifically mentions it can occur through > typedefs.) Thanks for posting this. After commenting on this topic I had a feeling that I'd once seen something like this, but I could not find it. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-24 07:49 -0700 |
| Message-ID | <lntx9iu6it.fsf@nuthaus.mib.org> |
| In reply to | #43506 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 04/24/2014 08:15 AM, BartC wrote:
> ...
>> I can't get CDECL to accept 'const array'. That might be a bug in CDECL, but
>> also in the C type syntax there doesn't seem anywhere to put a const for an
>> array.
>
> What does CDECL say about
>
> const int array[5];
It says "syntax error", but only because cdecl apparently treats "array"
as a reserved word (arguably a bug in cdecl).
cdecl> explain const int array[5]
syntax error
cdecl> explain const int arr[5]
declare arr as array 5 of const int
cdecl>
I believe that "const" does, at least syntactically, apply to the
element type, not to the array. But there's no practical difference; an
array value consists exactly of the values of the elements, and an array
is read-only if and only if its elements are read-only.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-25 03:03 +0100 |
| Message-ID | <0.22e0e338e7b918bd80ad.20140425030354BST.87lhuu6u7p.fsf@bsb.me.uk> |
| In reply to | #43510 |
Keith Thompson <kst-u@mib.org> writes: > James Kuyper <jameskuyper@verizon.net> writes: >> On 04/24/2014 08:15 AM, BartC wrote: >> ... >>> I can't get CDECL to accept 'const array'. That might be a bug in CDECL, but >>> also in the C type syntax there doesn't seem anywhere to put a const for an >>> array. >> >> What does CDECL say about >> >> const int array[5]; > > It says "syntax error", but only because cdecl apparently treats "array" > as a reserved word (arguably a bug in cdecl). > > cdecl> explain const int array[5] > syntax error > cdecl> explain const int arr[5] > declare arr as array 5 of const int > cdecl> > > I believe that "const" does, at least syntactically, apply to the > element type, not to the array. But there's no practical difference; an > array value consists exactly of the values of the elements, and an array > is read-only if and only if its elements are read-only. I suppose it depends on what is practical, but there is a difference: a const array and an array with const elements are not compatible types (at least that's how I read things). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-25 22:50 +0100 |
| Message-ID | <0.3fb0e29321ba14997d2c.20140425225051BST.874n1h6ptw.fsf@bsb.me.uk> |
| In reply to | #43536 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Keith Thompson <kst-u@mib.org> writes: > >> James Kuyper <jameskuyper@verizon.net> writes: >>> On 04/24/2014 08:15 AM, BartC wrote: >>> ... >>>> I can't get CDECL to accept 'const array'. That might be a bug in CDECL, but >>>> also in the C type syntax there doesn't seem anywhere to put a const for an >>>> array. >>> >>> What does CDECL say about >>> >>> const int array[5]; >> >> It says "syntax error", but only because cdecl apparently treats "array" >> as a reserved word (arguably a bug in cdecl). >> >> cdecl> explain const int array[5] >> syntax error >> cdecl> explain const int arr[5] >> declare arr as array 5 of const int >> cdecl> >> >> I believe that "const" does, at least syntactically, apply to the >> element type, not to the array. But there's no practical difference; an >> array value consists exactly of the values of the elements, and an array >> is read-only if and only if its elements are read-only. > > I suppose it depends on what is practical, but there is a difference: a > const array and an array with const elements are not compatible types > (at least that's how I read things). I am no longer so sure of this. Neither gcc nor clang object to passing typedef int iarray[3]; const iarray cia; f(&cia); to a function, f, with prototype void f(const int (*a)[3]); (I use pointers to arrays as the simplest way verify compatibility of types that decay in other contexts.) I've tried to give up the kind of close reading of the standard that would be required to unravel the validity of this so I'll leave it as something that has no practical consequences. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2014-04-24 20:20 -0600 |
| Message-ID | <1btx9ignee.fsf@snowball.wb.pfeifferfamily.net> |
| In reply to | #43510 |
Keith Thompson <kst-u@mib.org> writes: > James Kuyper <jameskuyper@verizon.net> writes: >> On 04/24/2014 08:15 AM, BartC wrote: >> ... >>> I can't get CDECL to accept 'const array'. That might be a bug in CDECL, but >>> also in the C type syntax there doesn't seem anywhere to put a const for an >>> array. >> >> What does CDECL say about >> >> const int array[5]; > > It says "syntax error", but only because cdecl apparently treats "array" > as a reserved word (arguably a bug in cdecl). > > cdecl> explain const int array[5] > syntax error > cdecl> explain const int arr[5] > declare arr as array 5 of const int > cdecl> > > I believe that "const" does, at least syntactically, apply to the > element type, not to the array. But there's no practical difference; an > array value consists exactly of the values of the elements, and an array > is read-only if and only if its elements are read-only. So... does anybody know what cdecl does with "array" that making it a reserved word makes sense? Or is it plain and simply a bug?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-24 23:31 -0700 |
| Message-ID | <lnd2g5udhx.fsf@nuthaus.mib.org> |
| In reply to | #43537 |
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> James Kuyper <jameskuyper@verizon.net> writes:
>>> On 04/24/2014 08:15 AM, BartC wrote:
>>> ...
>>>> I can't get CDECL to accept 'const array'. That might be a bug in CDECL, but
>>>> also in the C type syntax there doesn't seem anywhere to put a const for an
>>>> array.
>>>
>>> What does CDECL say about
>>>
>>> const int array[5];
>>
>> It says "syntax error", but only because cdecl apparently treats "array"
>> as a reserved word (arguably a bug in cdecl).
>>
>> cdecl> explain const int array[5]
>> syntax error
>> cdecl> explain const int arr[5]
>> declare arr as array 5 of const int
>> cdecl>
>>
>> I believe that "const" does, at least syntactically, apply to the
>> element type, not to the array. But there's no practical difference; an
>> array value consists exactly of the values of the elements, and an array
>> is read-only if and only if its elements are read-only.
>
> So... does anybody know what cdecl does with "array" that making it a
> reserved word makes sense? Or is it plain and simply a bug?
It's a reserved word in the English-like syntax it uses to explain
declarations:
cdecl> explain int arr[42]
declare arr as array 42 of int
cdecl> explain int array[42]
syntax error
cdecl>
This *shouldn't* cause it to be reserved for the C-like syntax it uses,
but apparently it treats it that way. I've never looked into the
internals, so I can't be sure what's going on.
The word "pointer" is also reserved, and "ptr" is a synonym for it.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-25 15:24 +0100 |
| Message-ID | <0.5dbd5bb614d3a0b21d4d.20140425152412BST.87eh0l7aib.fsf@bsb.me.uk> |
| In reply to | #43544 |
Keith Thompson <kst-u@mib.org> writes: > Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: <snip> >> So... does anybody know what cdecl does with "array" that making it a >> reserved word makes sense? Or is it plain and simply a bug? > > It's a reserved word in the English-like syntax it uses to explain > declarations: > > cdecl> explain int arr[42] > declare arr as array 42 of int > cdecl> explain int array[42] > syntax error > cdecl> > > This *shouldn't* cause it to be reserved for the C-like syntax it uses, > but apparently it treats it that way. I've never looked into the > internals, so I can't be sure what's going on. cdecl uses the same grammar for both "directions" of it's translation. 'array' is a keyword when used like this: cdecl> declare arr as array 42 of int int arr[42] so it's also one when reading an 'explain' command. You can't name your array "declare", "explain", "help" or any number of other words that are considered special. It's a shame, because the error that gets reported might be confusing. Is it really a syntax error in the declaration, or did you just use a keyword without knowing? Even when this is taken into account, cdecl is rather lax in admitting some things that are not valid C, and rejecting others that are (though the latter may just be that it has not kept up with recent standards). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-25 08:31 -0700 |
| Message-ID | <ln61lxtohf.fsf@nuthaus.mib.org> |
| In reply to | #43556 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> <snip>
>>> So... does anybody know what cdecl does with "array" that making it a
>>> reserved word makes sense? Or is it plain and simply a bug?
>>
>> It's a reserved word in the English-like syntax it uses to explain
>> declarations:
>>
>> cdecl> explain int arr[42]
>> declare arr as array 42 of int
>> cdecl> explain int array[42]
>> syntax error
>> cdecl>
>>
>> This *shouldn't* cause it to be reserved for the C-like syntax it uses,
>> but apparently it treats it that way. I've never looked into the
>> internals, so I can't be sure what's going on.
>
> cdecl uses the same grammar for both "directions" of it's translation.
> 'array' is a keyword when used like this:
>
> cdecl> declare arr as array 42 of int
> int arr[42]
>
> so it's also one when reading an 'explain' command. You can't name your
> array "declare", "explain", "help" or any number of other words that are
> considered special. It's a shame, because the error that gets reported
> might be confusing. Is it really a syntax error in the declaration, or
> did you just use a keyword without knowing?
>
> Even when this is taken into account, cdecl is rather lax in admitting
> some things that are not valid C, and rejecting others that are (though
> the latter may just be that it has not kept up with recent standards).
It would be an interesting project for someone to clean up cdecl and
release a new version. (Perhaps someone has already done so, but I see
no sign of it at cdecl.org.) I might play around with it myself, but I
honestly don't expect to produce anything worth releasing.
My suggestion: Rather than using a single grammar, recognize the first
word on a line ("declare", "explain", etc.) and use it to determine how
to parse the rest of the line. For bonus points, print more meaningful
error messages than "syntax error".
The source code can be downloaded from:
http://cdecl.org/files/cdecl-blocks-2.5.tar.gz
It apparently hasn't been updated since 1996.
As for licensing, here's an excerpt from the README file, written by
David R. Conrad:
You may well be wondering what the status of cdecl is. So am I.
It was twice posted to comp.sources.unix, but neither edition
carried any mention of copyright. This version is derived from
the second edition. I have no reason to believe there are any
limitations on its use, and strongly believe it to be in the
Public Domain. GNU readline is, of course, covered by the GNU
General Public License.
GNU readline isn't included in the distributed sources, but it links to
it if possible when it's built from source.
One interesting tidbit: cdecl 2.5 treats "noalias" as a keyword.
"noalias" was a proposed keyword, roughly an early attempt at what later
became "restrict", that never made it into the 1989 ANSI C standard.
Dennis Ritchie famously sent an official comment to X3J11 which included
the demand "Noalias must go. This is non-negotiable."
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-24 07:58 -0700 |
| Message-ID | <lnppk6u648.fsf@nuthaus.mib.org> |
| In reply to | #43504 |
"BartC" <bc@freeuk.com> writes:
[...]
> Maybe because 'array' doesn't really exist as an independent type,
> outside of a type-specification; the type of an expression can never
> start with 'array', so having 'const array' would have no benefit.
It's not true that array types don't exist as independent types, merely
that arrays decay to pointers in most contexts. The operand of unary
"sizeof" or "&" can be an expression of array type, and that expression
does not decay to a pointer.
But you're probably right about "const array" being unnecessary, since
"const" applies to the element type -- but it doesn't make much
difference.
An example:
const int arr[3] = { 10, 20, 30 };
&arr has type "pointer to array 3 of const int".
&arr[0] has type "pointer to const int".
--
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 | 2014-04-26 13:38 +0100 |
| Message-ID | <8ON6v.99033$_m3.98734@fx02.am4> |
| In reply to | #43498 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:ljath7$ulm$1@dont-email.me... > On 04/24/2014 05:37 AM, BartC wrote: >> (8) Implicit coercions from read-only to non-read-only versions of the >> same >> type (const T to T) raise a compiler diagnostic. > > More accurately, such conversions do not occur implicitly at all. The > diagnostic message is side-effect of the fact that the conversion did > NOT occur. It is the use of a const-qualified type in a context where it > is incompatible with the required type, that is the actual cause of the > constraint violation. My statement is not quite right in the case of matching function parameters. (I didn't follow your comments well enough to know if you are pointing out the same thing). It seems to be more of a problem to pass const T to T when T is some pointer type (const T* to T* when the pointer-ness is expressed directly). It's not an issue to pass a 'const int' argument to an 'int' parameter for example (otherwise a huge amount of code would run into problems.). Because the callee can do what it likes to its copy without affecting the caller's version. (This could finally be an example of a difference between const arrays and arrays of const, *if* arrays could be passed by value. A const array *could* be passed to a matching non-const array parameter as it would be immune from changes just like the const int argument is. But an array of const elements probably wouldn't match an array of non-consts; although the caller's version is safe, the array type would suggest that the elements cannot be assigned to; an implicit conversion to non-const would override that.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-26 11:50 -0700 |
| Message-ID | <lntx9gq61p.fsf@nuthaus.mib.org> |
| In reply to | #43597 |
"BartC" <bc@freeuk.com> writes:
[...]
> It's not an issue to pass a 'const int' argument to an 'int' parameter for
> example (otherwise a huge amount of code would run into problems.). Because
> the callee can do what it likes to its copy without affecting the caller's
> version.
Right -- because you *can't* pass a "const int" argument to a function.
An example:
void func(const int param0, const int param1) {
/* ... */
}
const int c = 10;
int nc = 20;
func(c, nc);
The "const" qualifiers on param0 and param1 mean only that func is not
allowed to modify its parameters, which are local objects; they have no
effect on callers.
The constness of c does not survive the evaluation of the expression
`c`. Evaluating the name of an object in a context that does
not require an lvalue yields the *value* of the object. Once the
expressions c and nc are evaluated, there is no further connection
to the objects whose values were extracted, and their constness or
non-constness is irrelevant.
N1570 6.3.2.1p2:
Except when it is the operand of the sizeof operator, the
_Alignof operator, the unary & operator, the ++ operator, the --
operator, or the left operand of the . operator or an assignment
operator, an lvalue that does not have array type is converted
to the value stored in the designated object (and is no longer
an lvalue); this is called *lvalue conversion*. If the lvalue
has qualified type, the value has the unqualified version of
the type of the lvalue [...]
(The reference to _Alignof was removed from the final C11 standard,
since _Alignof, for some unknown reason, cannot be applied to an
expression.)
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-24 07:42 -0700 |
| Message-ID | <lny4yuu6un.fsf@nuthaus.mib.org> |
| In reply to | #43497 |
"BartC" <bc@freeuk.com> writes:
[...]
> (11) Read-only attributes can be applied to scalars, structs and pointers,
> but not to arrays.
[...]
const int array[3] = { 10, 20, 30 };
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-24 08:43 -0700 |
| Message-ID | <lnlhuuu418.fsf@nuthaus.mib.org> |
| In reply to | #43508 |
Keith Thompson <kst-u@mib.org> writes:
> "BartC" <bc@freeuk.com> writes:
> [...]
>> (11) Read-only attributes can be applied to scalars, structs and pointers,
>> but not to arrays.
> [...]
>
> const int array[3] = { 10, 20, 30 };
Which (I think) actually applies the `const` to the element type, not to
the array type. I should have read the rest of the thread before
posting.
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-23 11:28 -0700 |
| Message-ID | <lnsip3vr2h.fsf@nuthaus.mib.org> |
| In reply to | #43437 |
"BartC" <bc@freeuk.com> writes:
[...]
> As someone said (maybe it was you, maybe Keith), you can taking a
> working program, edit all the 'const's out of it, and it should still
> compile and work. That doesn't sound like a feature that is
> indispensible!
It's not indispensible (C got along without it for a number of
years), but it's useful for catching errors.
Prior to the 1989 ANSI C standard, C did not distinguish between
const (read-only) and non-const (writable) data.
I've read about some oldish language, predating C, that didn't
distinguish between integer and floating-point data. It had separate
operators for integer and floating-point addition, likewise for
multiplication, et al. It was up to the programmer to keep track
of the "type" of a given variable and apply the correct operators.
C doesn't have those operators, nor does it let you declare
variables without specifying their type, but if it did, you could
take a working C program that uses both integers and floating point
and translate it to something that doesn't specify the types of
variables, and it would still work correctly. But if you modify
the resulting program, you'd have to be very careful to apply the
correct operators.
Would that be an improvement?
The distinctions C lets you make are useful, in that they let the
compiler diagnose errors for you.
What you want out of C might be different if you're generating code
by translating from some other language rather than programming
in C itself; you can do the error checking in your translator,
and nobody is expected to maintain, or probably even to read,
the generated C code. But C is designed primarily for writing and
maintaining code in C itself, and for that purpose, I like to have
the compiler do as much checking as it can.
--
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 | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-23 18:42 +0000 |
| Message-ID | <20140423113026.7@kylheku.com> |
| In reply to | #43449 |
On 2014-04-23, Keith Thompson <kst-u@mib.org> wrote: > "BartC" <bc@freeuk.com> writes: > [...] >> As someone said (maybe it was you, maybe Keith), you can taking a >> working program, edit all the 'const's out of it, and it should still >> compile and work. That doesn't sound like a feature that is >> indispensible! > > It's not indispensible (C got along without it for a number of > years), but it's useful for catching errors. > > Prior to the 1989 ANSI C standard, C did not distinguish between > const (read-only) and non-const (writable) data. > > I've read about some oldish language, predating C, that didn't > distinguish between integer and floating-point data. It had separate > operators for integer and floating-point addition, likewise for > multiplication, et al. It was up to the programmer to keep track > of the "type" of a given variable and apply the correct operators. > > C doesn't have those operators, nor does it let you declare > variables without specifying their type, but if it did, you could > take a working C program that uses both integers and floating point > and translate it to something that doesn't specify the types of > variables, and it would still work correctly. But if you modify > the resulting program, you'd have to be very careful to apply the > correct operators. That is not comparable to removing const; const is not involved in any decisions involving polymorphic dispatch. It does not provide type inference. In C++ it does, and so in C++ you cannot remove const from programs, in general, without turning them into a mess that requires a diagnostic. > Would that be an improvement? > > The distinctions C lets you make are useful, in that they let the > compiler diagnose errors for you. Except in the case of storage that is actually unmodifiable, like string literals, const *introduces* the error conditions which it helps diagnose. (Again, this is different from type declarations. Type declarations do not introduce type; type is already there, and applying the wrong type of operation on a value is already a bug.) A program might contain an instance of an object being modified unitentiontally, or surprisingly. In a program that is free of const, this doesn't require a diagnostic. It also, in and of itself, isn't an error at the language-construct level (it isn't undefined behavior) though it may be a software defect: one which causes the program to compute an incorrect result over correct inputs, and perhaps invoke undefined behavior elsewhere. The const qualifier can help catch some instances of unintended mutations. It helps most with those objects or object members which can be marked as not mutable by any code at all. When const is fastidiously applied throughout a code base (it adheres to "const correctness") then programmers are free to assume that if a function has a "const type *x" parameter, then the function does not modify *x. And, conversely, if the parameter is "type *x", there is a strong reason to suspect that the funtion does modify *x; because otherwise, in keeping with "const correctness", it would have been declared otherwise. This can be helpful, because it is quite important to know which functions parameters are pure, and which mutate. If the declaration, or a comment next to it, do not answer the question, the programmer has to waste time investigating this.
[toc] | [prev] | [next] | [standalone]
Page 11 of 14 — ← Prev page 1 … 9 10 [11] 12 13 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web