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 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-22 07:28 -0400 |
| Message-ID | <lj5jpi$tmt$1@dont-email.me> |
| In reply to | #43272 |
On 04/22/2014 06:31 AM, BartC wrote: > "Keith Thompson" <kst-u@mib.org> wrote in message > news:ln8uqy1rva.fsf@nuthaus.mib.org... ... >> If F modifies the caller's data, and the caller doesn't want it to be >> modified, then the caller shouldn't call F. > > How is it going to get the job done otherwise? If changing the passed data > is a problem for the caller, then it arranges for it not to be a problem > (such as passing a copy of the data). And proper use of const (which means, in this case, that the function which will modify the pointed at data declares the pointer as 'T*', and the data which should not be modified is declared 'const') guarantees a diagnostic message warning you about the necessity of performing such a work-around. ... > This must occur everywhere where function parameters do not have 'const' in > their types. Does every single call to such functions always apply a (const > char*) or equivalent cast to each argument just in case it might write to > it? (Which would be lying anyway as it wouldn't be read-only, but a weak > attempt to apply write-protection) No. No such cast is needed, it would have no useful effect. Why do you even suggest such a thing? > But usually you would have some clue as to what each function did and how it > worked. 'const' helps protect against the case where you've forgotten the clue you once had, or simple typing errors which result in passing the right argument to the wrong function, or the wrong argument to the right function, or passing the arguments in the wrong order. If you claim that you never make such mistakes, then never using 'const' might make sense for you. However, having seen your messages on this newgroup, I would be very skeptical of any such claim. > Otherwise, for 'const' to be any use at all, you would have to blindly apply > it just about everywhere. Applying it blindly would be useless. It would render it impossible to get anything done. The sole justification for declaring something const is to ensure that any code which might modify the thing so-declared is a constraint violation which will generate a warning message indicating that such code should not be written. Applying 'const' to anything other than something which should not be written to is pointless, and would usually prevent the code from even compiling. Why are you suggesting that such ridiculous coding practices would be necessary? > As for an example, this is derived from an actual project: you have a > tokeniser function F which takes a string representing a source file, and > generates a list of tokens. String/name tokens might make use of pointers > (ie. slices) into the caller's string. > > But it may be necessary for the caller's string to be modified (convert to > lower case, convert string const escapes, add 0-terminators etc) for this to > work. Such a function should use 'T*', NOT 'const T*', thereby ensuring a diagnostic message if someone makes the mistake of passing it a const T*, indicating memory which should not be written to. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-22 05:46 -0700 |
| Message-ID | <40f62968-e5d2-4354-90a6-aca35132596f@googlegroups.com> |
| In reply to | #43276 |
On Tuesday, April 22, 2014 12:28:49 PM UTC+1, James Kuyper wrote: > > Applying it blindly would be useless. It would render it impossible to > get anything done. The sole justification for declaring something const > is to ensure that any code which might modify the thing so-declared is a > constraint violation which will generate a warning message indicating > that such code should not be written. Applying 'const' to anything other > than something which should not be written to is pointless, and would > usually prevent the code from even compiling. Why are you suggesting > that such ridiculous coding practices would be necessary? > Some people use const to document that a pointer is input rather than output. Say we've got an employee with an embedded pointer giving his name. Say we also write the function char *employee_surnameincaps(const Employee *employee); that tells a reasonably intelligent caller that employee_surnameincaps is going to construct a temporary string with the employee's surname capitalised, either dynamically allocated or a static buffer. It's not going to modify his surname in place. We're not actually enforcing that, however.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-22 07:45 -0700 |
| Message-ID | <lnfvl5zalv.fsf@nuthaus.mib.org> |
| In reply to | #43272 |
"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:ln8uqy1rva.fsf@nuthaus.mib.org...
>> "BartC" <bc@freeuk.com> writes:
>>> doesn't want it to be modified, then using const is not going to
>>> help any. You can't use it for the parameter, because then a
>>> compiler error is raised within F.
>>
>> If F modifies the caller's data, and the caller doesn't want it to be
>> modified, then the caller shouldn't call F.
>
> How is it going to get the job done otherwise? If changing the passed data
> is a problem for the caller, then it arranges for it not to be a problem
> (such as passing a copy of the data).
What "job" are you talking about? Please provide a concrete example.
If you have data that you don't want modified, and you have a function
that would modify that data, then don't pass that data to that function.
If you "need" to do so, then there's something wrong with your design,
something that won't be corrected by removing "const".
>> What do you mean "you need to call F"? F is going to modify the data,
>> which you've already says you don't want it to do.
>>
>> Perhaps you could provide an example of what you're talking about; your
>> description isn't helping (at least it's not helping me).
>
> This must occur everywhere where function parameters do not have 'const' in
> their types. Does every single call to such functions always apply a (const
> char*) or equivalent cast to each argument just in case it might write to
> it? (Which would be lying anyway as it wouldn't be read-only, but a weak
> attempt to apply write-protection)
No, of course not; such a cast would be pointless (which is why nobody
has suggested casting arguments to const char*).
Do you need to apply a cast when passing a non-const argument to
strlen()?
The "const" goes on the parameter declaration, not on the call. Adding
"const" allows the function to be called with either const or non-const
data. The only case that's forbidden is passing const data to a
function with a non-const parameter.
void no_change(const char *param);
void change(char *param);
char modifiable[LEN];
char read_only[LEN];
no_change(modifiable); /* ok */
no_change(read_only); /* ok */
change(modifiable); /* ok */
change(read_only); /* error, caught by compiler */
> But usually you would have some clue as to what each function did and how it
> worked.
>
> Otherwise, for 'const' to be any use at all, you would have to blindly apply
> it just about everywhere.
No, you don't apply it to anything that you want to be writable. Don't
apply const blindly; apply it intelligently (which requires
understanding what it means).
> As for an example, this is derived from an actual project: you have a
> tokeniser function F which takes a string representing a source file, and
> generates a list of tokens. String/name tokens might make use of pointers
> (ie. slices) into the caller's string.
>
> But it may be necessary for the caller's string to be modified (convert to
> lower case, convert string const escapes, add 0-terminators etc) for this to
> work.
>
> That's fine if the caller agrees, otherwise (because it needs to preserve
> the original for error reports, or it doesn't own the data) then it might
> just pass a copy.
strtok() is an example of this. You can pass a pointer to a modifiable
string to strtok(), and it will be modified. You can't pass a pointer
to a non-modifiable (const) string to strtok(). If you need to use
strtok() on read-only data, you need to make a copy of it.
That's how the language works right now. Without "const", the only
difference would be that the compiler wouldn't warn you if you pass a
pointer to a read-only string, because you'd have no way to tell the
compiler that a string is read-only.
How is this an argument against "const"?
> Another example (contrived this one), you have a function F that needs to
> invert, reverse, or do some operation to some data (string or image for
> example) in order to display the result or whatever. But the operation is
> reversible. After the call, the caller's data is unchanged, but it needs to
> be writeable.
Right, "const" doesn't handle cases where a function needs to
temporarily modify data and then change it back to its original state.
I don't think that's a common case, certainly not comon enough to
justify throwing away the benefits of "const" in other cases.
> Or maybe F needs to do some irreversible operation, and it is simplest to do
> it in-place (like my first example). Maybe that's OK for the caller, maybe
> not. But /how is const going to help in specifying such a function/? It
> won't. That's why I say it's not of vital importance to the language.
It helps because it prevents the caller from performing an irreversible
operation on read-only data. If the caller needs to change the data,
then the caller *shouldn't have declared that data "const".
The existence of "const" doesn't prevent you from writing and calling
functions that modify data. You just don't use "const" for those cases.
> It might be of help in the odd place, but that's offset by the extra clutter
> that can make it harder to see real bugs.
--
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 | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2014-04-22 16:34 +0000 |
| Message-ID | <slrn3vfslld6g6.rub.ike@iceland.freeshell.org> |
| In reply to | #43293 |
On 2014-04-22, Keith Thompson <kst-u@mib.org> wrote: > void no_change(const char *param); > void change(char *param); > > char modifiable[LEN]; > char read_only[LEN]; There seems to be a 'const' missing here. > no_change(modifiable); /* ok */ > no_change(read_only); /* ok */ > change(modifiable); /* ok */ > change(read_only); /* error, caught by compiler */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-22 10:10 -0700 |
| Message-ID | <lnr44pxpc9.fsf@nuthaus.mib.org> |
| In reply to | #43302 |
Ike Naar <ike@iceland.freeshell.org> writes:
> On 2014-04-22, Keith Thompson <kst-u@mib.org> wrote:
>> void no_change(const char *param);
>> void change(char *param);
>>
>> char modifiable[LEN];
>> char read_only[LEN];
>
> There seems to be a 'const' missing here.
Yes.
>> no_change(modifiable); /* ok */
>> no_change(read_only); /* ok */
>> change(modifiable); /* ok */
>> change(read_only); /* error, caught by compiler */
Corrected example:
void no_change(const char *param);
void change(char *param);
char modifiable[LEN];
const char read_only[LEN];
no_change(modifiable); /* ok */
no_change(read_only); /* ok */
change(modifiable); /* ok */
change(read_only); /* error, caught by compiler */
--
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 | 2014-04-22 11:50 -0500 |
| Message-ID | <lj66ko$8sh$1@dont-email.me> |
| In reply to | #43272 |
On 22-Apr-14 05:31, BartC wrote: > "Keith Thompson" <kst-u@mib.org> wrote in message > news:ln8uqy1rva.fsf@nuthaus.mib.org... >> "BartC" <bc@freeuk.com> writes: > >>> I'm saying that if F does modify the caller's data, and the >>> caller doesn't want it to be modified, then using const is not >>> going to help any. You can't use it for the parameter, because >>> then a compiler error is raised within F. >> >> If F modifies the caller's data, and the caller doesn't want it to >> be modified, then the caller shouldn't call F. > > How is it going to get the job done otherwise? If changing the passed > data is a problem for the caller, then it arranges for it not to be a > problem (such as passing a copy of the data). It'd be annoying if every time we called a function, we had to make a copy of all the data just in case that function tried to modify it; in most cases, the function won't so that effort is wasted. If only there were a way for a function to indicate that it won't do so, which compilers could then enforce for us... Oh wait, there is; it's called "const"! Also, what about the functions we use to copy our data? _They_ might modify the original data as well, so now you've got an infinite loop! Gosh, maybe that's why memcpy(), strcpy(), et al use const for the source arguments! >> What do you mean "you need to call F"? F is going to modify the >> data, which you've already says you don't want it to do. >> >> Perhaps you could provide an example of what you're talking about; >> your description isn't helping (at least it's not helping me). > > This must occur everywhere where function parameters do not have > 'const' in their types. Does every single call to such functions > always apply a (const char*) or equivalent cast to each argument just > in case it might write to it? (Which would be lying anyway as it > wouldn't be read-only, but a weak attempt to apply write-protection) You can't pass a (const char *) argument to a function taking (char *); that's the entire point. You _can_ pass a (char *) argument to a function taking (const char *). > But usually you would have some clue as to what each function did > and how it worked. And one of those clues is whether the arguments are const; that clearly indicates to both programmer and compiler that the argument won't be changed by the function. Yes, malicious programmers can cast away the constness, but if you have to worry about that, then you have far bigger problems to worry about. > Otherwise, for 'const' to be any use at all, you would have to > blindly apply it just about everywhere. > > As for an example, this is derived from an actual project: you have > a tokeniser function F which takes a string representing a source > file, and generates a list of tokens. String/name tokens might make > use of pointers (ie. slices) into the caller's string. > > But it may be necessary for the caller's string to be modified > (convert to lower case, convert string const escapes, add > 0-terminators etc) for this to work. > > That's fine if the caller agrees, otherwise (because it needs to > preserve the original for error reports, or it doesn't own the data) > then it might just pass a copy. You have two choices in that case; either the function makes copies and returns those, or it documents that it modifies its input and the caller has to make the copy. Examples of both can be seen in the wild. > Another example (contrived this one), you have a function F that > needs to invert, reverse, or do some operation to some data (string > or image for example) in order to display the result or whatever. But > the operation is reversible. After the call, the caller's data is > unchanged, but it needs to be writeable. Such a function should put the inverted/reversed/etc. data in its own temporary buffer, which gets destroyed on exit, leaving the original unchanged. > Or maybe F needs to do some irreversible operation, and it is > simplest to do it in-place (like my first example). Maybe that's OK > for the caller, maybe not. But /how is const going to help in > specifying such a function/? It won't. That's why I say it's not of > vital importance to the language. If the function is going to modify its input, simply don't specify the argument as const. If the caller needs to preserve its data, it will make a temporary copy of its data to pass to the function. > It might be of help in the odd place, but that's offset by the extra > clutter that can make it harder to see real bugs. No, const helps _prevent_ and _diagnose_ real bugs. 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 | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-22 18:48 +0100 |
| Message-ID | <kYx5v.117760$Ey6.66211@fx24.am4> |
| In reply to | #43307 |
"Stephen Sprunk" <stephen@sprunk.org> wrote in message news:lj66ko$8sh$1@dont-email.me... > On 22-Apr-14 05:31, BartC wrote: >> "Keith Thompson" <kst-u@mib.org> wrote in message >> news:ln8uqy1rva.fsf@nuthaus.mib.org... >>> "BartC" <bc@freeuk.com> writes: >> >>>> I'm saying that if F does modify the caller's data, and the >>>> caller doesn't want it to be modified, then using const is not >>>> going to help any. You can't use it for the parameter, because >>>> then a compiler error is raised within F. >>> >>> If F modifies the caller's data, and the caller doesn't want it to >>> be modified, then the caller shouldn't call F. >> >> How is it going to get the job done otherwise? If changing the passed >> data is a problem for the caller, then it arranges for it not to be a >> problem (such as passing a copy of the data). > > It'd be annoying if every time we called a function, we had to make a > copy of all the data just in case that function tried to modify it; in > most cases, the function won't so that effort is wasted. If only there > were a way for a function to indicate that it won't do so, which > compilers could then enforce for us... Oh wait, there is; it's called > "const"! OK. How would that work with the Image_t example I gave in another post? Image_t is a type which specifies an image, but doesn't go into any details as to its implementation. You want to call an external function SomeFunction(Image_t) which does not modify the image it is passed. How would that be expressed using const? > No, const helps _prevent_ and _diagnose_ real bugs. If you say so. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-22 14:02 -0400 |
| Message-ID | <5356AEBC.4020509@verizon.net> |
| In reply to | #43319 |
On 04/22/2014 01:48 PM, BartC wrote: ... > You want to call an external function SomeFunction(Image_t) which does not > modify the image it is passed. How would that be expressed using const? typedef struct Image Image_t; // struct Image is an opague type. somereturntype SomeFunction(const Image_t *);
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-22 19:48 +0100 |
| Message-ID | <kRy5v.120930$Ey6.22221@fx24.am4> |
| In reply to | #43320 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:5356AEBC.4020509@verizon.net... > On 04/22/2014 01:48 PM, BartC wrote: > ... >> You want to call an external function SomeFunction(Image_t) which does >> not >> modify the image it is passed. How would that be expressed using const? > > typedef struct Image Image_t; > // struct Image is an opague type. > > somereturntype SomeFunction(const Image_t *); Nice try, but: * As you have it, Image_t is now not so opaque; you've introduced a struct and a pointer * As written, the const here doesn't stop SomeFunction from changing the image data (it might make it harder to change details in the descriptor, *if* implemented as a pointer to a struct). I suppose you could consider this 'const' to be just a token, informal way of telling a human reader that it will not modify the image data. But in that case a comment would do just as well. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-22 15:28 -0400 |
| Message-ID | <5356C2E9.1030405@verizon.net> |
| In reply to | #43331 |
On 04/22/2014 02:48 PM, BartC wrote: > > > "James Kuyper" <jameskuyper@verizon.net> wrote in message > news:5356AEBC.4020509@verizon.net... >> On 04/22/2014 01:48 PM, BartC wrote: >> ... >>> You want to call an external function SomeFunction(Image_t) which does >>> not >>> modify the image it is passed. How would that be expressed using const? >> >> typedef struct Image Image_t; >> // struct Image is an opague type. >> >> somereturntype SomeFunction(const Image_t *); > > Nice try, but: > > * As you have it, Image_t is now not so opaque; you've introduced a struct > and a pointer If it's not opaque, how many members does it have? What are their names and types, and in what order are they allocated? Keep in mind that no more information need be given to the compiler, than I've already given you, in order to write code that passes around Image_t* values. The fact that I've used a struct is not something the user needs to know about - it could just as easily have been a union or an arithmetic type (though it would have to be a pretty small image to fit in a single object of a standard arithmetic type - a long double _Complex would typically not be large enough for anything more than a 16x10 b/w image). If you need more opacity than that, you'll have to explain why. Hiding the fact that it's a pointer behind a typedef is TOO MUCH opacity, because it can cause things to be syntax errors that don't look like syntax errors (and vice versa). If you want to use an array type, you can store it inside the struct. Making Image_t itself an array type would cause it to be unexpectedly treated as a pointer in some contexts. > * As written, the const here doesn't stop SomeFunction from changing the > image data (it might make it harder to change details in the descriptor, > *if* implemented as a pointer to a struct). As written, it is a pointer to a struct, and therefore requires SomeFunction() to cast away the 'const' in order to change the value of any member of that struct. I always treat casts with suspicion, as something that should be avoided, so that's sufficient to be useful (though I'd prefer a new language feature that would cause such casts to be constraint violations). This approach can't do anything about structs that contain pointers to the actual data managed by the struct, or indices into arrays that are not part of the struct. That reduces the value of using 'const' for this purpose, but it does not eliminate that value - it doesn't even come close to doing so. Rather, it reduces (but does not eliminate) the value of using such structures for managing the data. > I suppose you could consider this 'const' to be just a token, informal way > of telling a human reader that it will not modify the image data. But in > that case a comment would do just as well. For the purposes of my response, consider: someotherreturntype SomeOtherFunction(Image_t *); A comment in place of the 'const' in the declaration of SomeFunction() would not cause a mandatory diagnostic if SomeFunction() attempts to modify the object pointed at, including, as a special case, any attempt to pass that pointer to SomeOtherFunction(). Therefore, a comment is not an adequate substitute for 'const'.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2014-04-22 19:48 -0500 |
| Message-ID | <lj72kd$bot$1@dont-email.me> |
| In reply to | #43331 |
On 22-Apr-14 13:48, BartC wrote: > "James Kuyper" <jameskuyper@verizon.net> wrote in message > news:5356AEBC.4020509@verizon.net... >> On 04/22/2014 01:48 PM, BartC wrote: >> ... >>> You want to call an external function SomeFunction(Image_t) which >>> does not >>> modify the image it is passed. How would that be expressed using const? >> >> typedef struct Image Image_t; >> // struct Image is an opague type. >> >> somereturntype SomeFunction(const Image_t *); > > Nice try, but: > > * As you have it, Image_t is now not so opaque; you've introduced a > struct and a pointer A pointer-to-incomplete-struct is idiomatic for opaque data in C. > * As written, the const here doesn't stop SomeFunction from changing the > image data (it might make it harder to change details in the descriptor, > *if* implemented as a pointer to a struct). That wasn't the point; the point was to allow passing both const and non-const images to SomeFunction(), which promised to not modify the image by marking its argument as const. The implementation of SomeFunction() could do all sorts of nasty things to break that promise, e.g. casting away the constness of its argument. C doesn't prevent doing that, nor would such be desirable because there are (rare) cases where that is actually the right thing to do. 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 | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-23 11:56 +0100 |
| Message-ID | <f1N5v.69493$kp2.49299@fx01.am4> |
| In reply to | #43397 |
"Stephen Sprunk" <stephen@sprunk.org> wrote in message
news:lj72kd$bot$1@dont-email.me...
> On 22-Apr-14 13:48, BartC wrote:
>> * As written, the const here doesn't stop SomeFunction from changing the
>> image data (it might make it harder to change details in the descriptor,
>> *if* implemented as a pointer to a struct).
>
> That wasn't the point; the point was to allow passing both const and
> non-const images to SomeFunction(), which promised to not modify the
> image by marking its argument as const.
So, const now is only being used as a kind of gentleman's agreement between
caller and callee, to make certain promises about whether the internal data
will be protected or not. Because you can't fully protect the data without
having const attributes buried deep inside the opaque type; a top-level
'const' is being used as a guard.
(Which is similar to what I suggested in other thread, to avoid crazy
constructions such as 'const int * const (* const x)[]')
That's fine, maybe it can become number (3) on jacob navia's list of
different categories of 'const' (I can think of one or two more).
However, when I try and use such a guard to suggest that a file-handling
function will not modify the file I'm passing it, I run into problems:
void dont_update_the_file(const FILE* f) {
fseek(f,0,SEEK_SET);
}
The fseek() call generates a warning. So it needs every single function,
that might take such a parameter, to cooperate with the scheme.
But do people actually make use of const when working with file-processing
functions? If not, then they might well find that not bothering with const
works elsewhere too!
> The implementation of SomeFunction() could do all sorts of nasty things
> to break that promise, e.g. casting away the constness of its argument.
It doesn't have to do anything nasty at all. In the code below,
dont_write_to_image() manages to populate the image data without any
complaint from the compiler:
#include <stdio.h>
#include <stdlib.h>
typedef struct {
int dimx,dimy;
char* data;
} imgdescr;
void dont_write_to_image(const imgdescr* bm){
int i;
for (i=0; i<bm->dimx*bm->dimy; ++i)
bm->data[i]=rand()&1?'1':'0';
}
int main (void) {
imgdescr bm = {16,16,NULL};
imgdescr* ibm=&bm;
ibm->data = malloc(ibm->dimx*ibm->dimy);
dont_write_to_image(ibm);
}
There *would* be a complaint if, instead, it used a setpixel() routine which
didn't have the const guard. So some sort of protection might work, but it
requires considerable extra effort, and is much harder if many of the
functions involved are not yours and haven't implemented the same scheme.
TBH, I would much rather accept responsibility for my own programming errors
if I inadvertently call the wrong functions on my data, than waste time
building a protection scheme based on a half-baked language feature, that is
of doubtful benefit anyway.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-23 12:59 +0100 |
| Message-ID | <0.1bf5c9ba6541421460de.20140423125917BST.87bnvs9rze.fsf@bsb.me.uk> |
| In reply to | #43412 |
"BartC" <bc@freeuk.com> writes:
> "Stephen Sprunk" <stephen@sprunk.org> wrote in message
> news:lj72kd$bot$1@dont-email.me...
>> On 22-Apr-14 13:48, BartC wrote:
>
>>> * As written, the const here doesn't stop SomeFunction from changing the
>>> image data (it might make it harder to change details in the descriptor,
>>> *if* implemented as a pointer to a struct).
>>
>> That wasn't the point; the point was to allow passing both const and
>> non-const images to SomeFunction(), which promised to not modify the
>> image by marking its argument as const.
>
> So, const now is only being used as a kind of gentleman's agreement
> between caller and callee, to make certain promises about whether the
> internal data will be protected or not.
Yes, that's it. Casts (and a few other historical oddities) allow you
to circumvent the type system in C.
<snip>
> That's fine, maybe it can become number (3) on jacob navia's list of
> different categories of 'const' (I can think of one or two more).
Jacob's classification was an invention. It does not describe cont as
the C defines it where it has (as far as I can tell) one meaning: that
you can't modify an object using an expression whose type is const
qualified. It really not complicated.
> However, when I try and use such a guard to suggest that a
> file-handling function will not modify the file I'm passing it, I run
> into problems:
>
> void dont_update_the_file(const FILE* f) {
> fseek(f,0,SEEK_SET);
> }
>
> The fseek() call generates a warning. So it needs every single
> function, that might take such a parameter, to cooperate with the
> scheme.
Of course. fseek can't make the promise that won't modify the FILE
object so you can't use in a function like dont_update_the_file that
does make such a promise.
I think your objection stems from the fact that const is either not what
you thought it was, or not what you would like it to be.
You offer an example that demonstrates this:
> In the code below,
> dont_write_to_image() manages to populate the image data without any
> complaint from the compiler:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> typedef struct {
> int dimx,dimy;
> char* data;
> } imgdescr;
>
> void dont_write_to_image(const imgdescr* bm){
> int i;
> for (i=0; i<bm->dimx*bm->dimy; ++i)
> bm->data[i]=rand()&1?'1':'0';
> }
I don't know whether you are surprised or disappointed here (i.e. I
don't know if you thought the "const" would prevent this, or if you
thought it should prevent it) but I am neither. const imgdescr* bm just
means that *bm is not a modifiable lvalue expression. It does not mean
that the function can't modify the object (as Jacob claimed) since there
may be some other way to get at it, not does it mean that all of the
expression derived from *bm (like bm->data[i]) are not modifiable.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-23 08:21 -0400 |
| Message-ID | <lj8b8m$65v$1@dont-email.me> |
| In reply to | #43414 |
On 04/23/2014 07:59 AM, Ben Bacarisse wrote: > "BartC" <bc@freeuk.com> writes: > >> "Stephen Sprunk" <stephen@sprunk.org> wrote in message >> news:lj72kd$bot$1@dont-email.me... >>> On 22-Apr-14 13:48, BartC wrote: ... > Jacob's classification was an invention. It does not describe cont as > the C defines it where it has (as far as I can tell) one meaning: that > you can't modify an object using an expression whose type is const > qualified. It really not complicated. That's Jacob's first meaning. This is an example of Jacob's second meaning: const int i=5; *(int *)&i = 6; // Undefined behavior (6.7.3p6) -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-23 14:09 +0100 |
| Message-ID | <0.d97dae420382e8343117.20140423140958BST.87ppk88a55.fsf@bsb.me.uk> |
| In reply to | #43416 |
James Kuyper <jameskuyper@verizon.net> writes: > On 04/23/2014 07:59 AM, Ben Bacarisse wrote: >> "BartC" <bc@freeuk.com> writes: >> >>> "Stephen Sprunk" <stephen@sprunk.org> wrote in message >>> news:lj72kd$bot$1@dont-email.me... >>>> On 22-Apr-14 13:48, BartC wrote: > ... >> Jacob's classification was an invention. It does not describe cont as >> the C defines it where it has (as far as I can tell) one meaning: that >> you can't modify an object using an expression whose type is const >> qualified. It really not complicated. > > That's Jacob's first meaning. This is an example of Jacob's second meaning: > > const int i=5; > *(int *)&i = 6; // Undefined behavior (6.7.3p6) That helps, thanks. His wording (referring to ROM) threw me a bit. He wants to distinguish between the effect on expressions and the effect on objects. There may be some benefit to making that distinction explicit, but I don't really have a strong opinion on the matter. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-23 14:19 +0100 |
| Message-ID | <0.ffdd7b9e7c09a2a76248.20140423141923BST.87k3ag89pg.fsf@bsb.me.uk> |
| In reply to | #43416 |
James Kuyper <jameskuyper@verizon.net> writes: > On 04/23/2014 07:59 AM, Ben Bacarisse wrote: >> "BartC" <bc@freeuk.com> writes: >> >>> "Stephen Sprunk" <stephen@sprunk.org> wrote in message >>> news:lj72kd$bot$1@dont-email.me... >>>> On 22-Apr-14 13:48, BartC wrote: > ... >> Jacob's classification was an invention. It does not describe cont as >> the C defines it where it has (as far as I can tell) one meaning: that >> you can't modify an object using an expression whose type is const >> qualified. It really not complicated. > > That's Jacob's first meaning. This is an example of Jacob's second meaning: > > const int i=5; > *(int *)&i = 6; // Undefined behavior (6.7.3p6) Further clarification... I think your example would be UB even without 6.7.3 p6 because of the rules about effective types and object accesses. A more pointed example would have been *(char *)&i = 6; because that is UB only because of the const qualification on the object named i. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-23 08:40 -0400 |
| Message-ID | <lj8cbq$daj$1@dont-email.me> |
| In reply to | #43412 |
On 04/23/2014 06:56 AM, BartC wrote:
....
> However, when I try and use such a guard to suggest that a file-handling
> function will not modify the file I'm passing it, I run into problems:
>
> void dont_update_the_file(const FILE* f) {
> fseek(f,0,SEEK_SET);
> }
>
> The fseek() call generates a warning. So it needs every single function,
> that might take such a parameter, to cooperate with the scheme.
It's supposed to generate a warning. That's precisely what the 'const'
is intended to achieve - preventing you from doing anything that would
modify *f. Since fseek() needs to update some of the members of the FILE
that it is passed, (specifically, the ones that keep track of the
current position in the file), the fact that a diagnostic message is
required for that call is how the 'const' achieves precisely that effect.
Your mistake lies in assuming that the 'const' protects the file managed
by the FILE object. It only protects the FILE object itself. Since some
elements of that object may need to be updated any time you write to the
file managed by that structure, protecting the FILE object does in fact
prevent you from modifying the file that it manages. However, it also
prevents you from doing a lot of other things that don't modify the
file, such as reading it. I think that the only operations that could,
in principle, be carried out on a FILE without modifying it are feof()
and ferror(). However, those functions are both defined as taking
"FILE*" rather than "const FILE*" parameters. That's probably because a
'const FILE*' is so nearly useless it never occurred to anyone that
there might be any point in using it for those two functions.
> > The implementation of SomeFunction() could do all sorts of nasty things
>> to break that promise, e.g. casting away the constness of its argument.
>
> It doesn't have to do anything nasty at all. In the code below,
> dont_write_to_image() manages to populate the image data without any
> complaint from the compiler:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> typedef struct {
> int dimx,dimy;
> char* data;
> } imgdescr;
>
> void dont_write_to_image(const imgdescr* bm){
> int i;
> for (i=0; i<bm->dimx*bm->dimy; ++i)
> bm->data[i]=rand()&1?'1':'0';
> }
The 'const' only protects the members of 'bm'; expecting anything else
to be protected (such as data pointed by one of the members of 'bm') is
a mistake. If data had been an array, rather than a pointer, that code
would have been a constraint violation.
I've already acknowledged this issue, without accepting your claim that
it renders 'const' useless.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-23 11:56 -0400 |
| Message-ID | <5357E2AB.5020105@verizon.net> |
| In reply to | #43417 |
On 04/23/2014 08:40 AM, James Kuyper wrote: ... > file, such as reading it. I think that the only operations that could, > in principle, be carried out on a FILE without modifying it are feof() > and ferror(). However, those functions are both defined as taking > "FILE*" rather than "const FILE*" parameters. That's probably because a > 'const FILE*' is so nearly useless it never occurred to anyone that > there might be any point in using it for those two functions. I should have added ftell() and fgetpos() to that list. Neither of them takes a "const FILE*" parameter, either - but I believe that they could have.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-23 11:10 -0700 |
| Message-ID | <lnwqefvrvk.fsf@nuthaus.mib.org> |
| In reply to | #43435 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 04/23/2014 08:40 AM, James Kuyper wrote:
> ...
>> file, such as reading it. I think that the only operations that could,
>> in principle, be carried out on a FILE without modifying it are feof()
>> and ferror(). However, those functions are both defined as taking
>> "FILE*" rather than "const FILE*" parameters. That's probably because a
>> 'const FILE*' is so nearly useless it never occurred to anyone that
>> there might be any point in using it for those two functions.
>
> I should have added ftell() and fgetpos() to that list. Neither of them
> takes a "const FILE*" parameter, either - but I believe that they could
> have.
Quite possibly -- but the standard says so little about the contents
of a FILE object that I'm not sure making those parameters const
would have been helpful.
FILE objects are (normally) created only by calling library
functions, and are manipulated only via FILE* pointers.
An implementation could make FILE itself an integer type, an
index into a table, which would allow *all* FILE* arguments to be
defined as "const FILE *f". Another could keep additional tracking
information in the FILE object itself, so ftell() and friends might
actually update the FILE object.
A hypothetical declaration like:
long int ftell(const FILE *stream);
tells client code that the FILE object won't be modified --
but there's nothing that any portable client code can do with
that information. (And it constrains implementations, perhaps
unnecessarily.)
Opaque types don't make much of an argument either for or against
"const".
For non-opaque types, where client code actually cares about the
internals of an object, "const" can catch bugs.
--
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 | 2014-04-23 19:19 -0500 |
| Message-ID | <lj9lan$c9l$1@dont-email.me> |
| In reply to | #43448 |
On 23-Apr-14 13:10, Keith Thompson wrote: > FILE objects are (normally) created only by calling library > functions, and are manipulated only via FILE* pointers. > An implementation could make FILE itself an integer type, an > index into a table, which would allow *all* FILE* arguments to be > defined as "const FILE *f". Another could keep additional tracking > information in the FILE object itself, so ftell() and friends might > actually update the FILE object. Why might ftell() need to "update" the FILE object? In theory, all it needs to do is extract the current file offset and return it. 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]
Page 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web