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 2 of 14 — ← Prev page 1 [2] 3 4 … 14 Next page →
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-19 23:32 +0100 |
| Message-ID | <RRC4v.19961$vB1.6512@fx36.am4> |
| In reply to | #43133 |
"Keith Thompson" <kst-u@mib.org> wrote in message news:lneh0t3wcs.fsf@nuthaus.mib.org... > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> This is the sort of thing that makes languages which attempt to be a >> safer C difficult to use. The programmer is constantly programming >> around the restrictions. > > So what's your solution? Would you drop "const" from the language? Am I allowed to say Yes? I don't think it would be missed. It's easy enough though to just not use it, or to remove const keywords with an editor (then maybe the code will be a lot clearer!). > Suppose you have a function that modifies a string, and you accidentally > pass it a string literal; do you not *want* the compiler to warn you? There are plenty of other things to worry about. If you are calling a function which does in-place modifications of an argument, then you need to know about it, as you might not want that to happen even if your string is writeable; you just don't want it written to by that function. Modification of a string literal at least has a chance of being detected by the hardware. Using 'const's might just be giving a false sense of security. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-19 23:38 +0000 |
| Message-ID | <20140419163444.761@kylheku.com> |
| In reply to | #43141 |
On 2014-04-19, BartC <bc@freeuk.com> wrote: > "Keith Thompson" <kst-u@mib.org> wrote in message > news:lneh0t3wcs.fsf@nuthaus.mib.org... >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >>> This is the sort of thing that makes languages which attempt to be a >>> safer C difficult to use. The programmer is constantly programming >>> around the restrictions. >> >> So what's your solution? Would you drop "const" from the language? > > Am I allowed to say Yes? I don't think it would be missed. Dennis Ritchie wasn't crazy about qualifiers either, so you wouldn't be in bad company. See http://www.lysator.liu.se/c/dmr-on-noalias.html "Let me begin by saying that I'm not convinced that even the pre-December qualifiers (`const' and `volatile') carry their weight; I suspect that what they add to the cost of learning and using the language is not repaid in greater expressiveness."
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-19 17:28 -0700 |
| Message-ID | <lnwqek3kv4.fsf@nuthaus.mib.org> |
| In reply to | #43141 |
"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lneh0t3wcs.fsf@nuthaus.mib.org...
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
>>> This is the sort of thing that makes languages which attempt to be a
>>> safer C difficult to use. The programmer is constantly programming
>>> around the restrictions.
>>
>> So what's your solution? Would you drop "const" from the language?
>
> Am I allowed to say Yes?
Certainly -- and I'm allowed to say that I completely disagree.
(Incidentally, the question was addressed to Malcolm, which in no way
implies that your input is unwelcome.)
> I don't think it would be missed. It's easy enough
> though to just not use it, or to remove const keywords with an editor (then
> maybe the code will be a lot clearer!).
>
>> Suppose you have a function that modifies a string, and you accidentally
>> pass it a string literal; do you not *want* the compiler to warn you?
>
> There are plenty of other things to worry about. If you are calling a
> function which does in-place modifications of an argument, then you need to
> know about it, as you might not want that to happen even if your string is
> writeable; you just don't want it written to by that function.
Exactly -- and you can express that by defining that function's
parameter as "const char*".
char s[] = "hello"; /* s is writable */
strlen(s); /* strlen() promises not to modify the string */
> Modification of a string literal at least has a chance of being detected by
> the hardware.
Yes, but not at compile time. I like to detect errors as early as
possible.
> Using 'const's might just be giving a false sense of security.
I might be hit by a meteorite; why bother to wear a seatbelt?
--
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-20 10:53 +0100 |
| Message-ID | <yPM4v.20078$_m3.11740@fx02.am4> |
| In reply to | #43152 |
"Keith Thompson" <kst-u@mib.org> wrote in message news:lnwqek3kv4.fsf@nuthaus.mib.org... > "BartC" <bc@freeuk.com> writes: >> There are plenty of other things to worry about. If you are calling a >> function which does in-place modifications of an argument, then you need >> to >> know about it, as you might not want that to happen even if your string >> is >> writeable; you just don't want it written to by that function. > > Exactly -- and you can express that by defining that function's > parameter as "const char*". That won't work: (1) The function *needs* to modify the thing pointed to by its argument (2) It might not be your function to modify Nothing to do with 'const' anymore, just awareness of the side-effects of a function. If you're going to pass it a writeable string that you don't want modified, then const is not going to help. (Maybe pass it a copy, use another function, or just be aware it could be modified. Or if it is a literal you're thinking of passing, to think twice about that!) > > char s[] = "hello"; /* s is writable */ > strlen(s); /* strlen() promises not to modify the string */ In the case of strlen(), a short note in the function docs can state the same thing. >> Modification of a string literal at least has a chance of being detected >> by >> the hardware. > > Yes, but not at compile time. I like to detect errors as early as > possible. But as I showed in my OP, potential errors such as 'char* q="ABC"' are not picked up unless using an obscure gcc option, which isn't included in -Wall and -Wextra, and in other compilers may not be detectable at all. >> Using 'const's might just be giving a false sense of security. > > I might be hit by a meteorite; why bother to wear a seatbelt? This is exactly my point: there might be so many signs everywhere warning about meteorites, that they obscure the more ordinary ones, like stop signs. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-20 14:29 -0700 |
| Message-ID | <lny4yz1yh4.fsf@nuthaus.mib.org> |
| In reply to | #43167 |
"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnwqek3kv4.fsf@nuthaus.mib.org...
>> "BartC" <bc@freeuk.com> writes:
>
>>> There are plenty of other things to worry about. If you are calling
>>> a function which does in-place modifications of an argument, then
>>> you need to know about it, as you might not want that to happen even
>>> if your string is writeable; you just don't want it written to by
>>> that function.
>>
>> Exactly -- and you can express that by defining that function's
>> parameter as "const char*".
>
> That won't work:
>
> (1) The function *needs* to modify the thing pointed to by its argument
Then I must have misunderstood. You said "you just don't want it
written to by that function". Can you clarify? Does the function
modify the string or not?
> (2) It might not be your function to modify
A function with a char* parameter pointing to a string *should* declare
that parameter as "const char*". If it doesn't, and if you're not able
to fix it, then you'll just have to deal with that.
[...]
>> char s[] = "hello"; /* s is writable */
>> strlen(s); /* strlen() promises not to modify the string */
>
> In the case of strlen(), a short note in the function docs can state the
> same thing.
Sure, but it doesn't have to, because we have "const".
>>> Modification of a string literal at least has a chance of being detected
>>> by
>>> the hardware.
>>
>> Yes, but not at compile time. I like to detect errors as early as
>> possible.
>
> But as I showed in my OP, potential errors such as 'char* q="ABC"' are not
> picked up unless using an obscure gcc option, which isn't included in -Wall
> and -Wextra, and in other compilers may not be detectable at all.
Right, that's one special case, already explained and repeatedly
acknowledged as a flaw in the language. The solution is to remember to
add the const yourself.
>>> Using 'const's might just be giving a false sense of security.
>>
>> I might be hit by a meteorite; why bother to wear a seatbelt?
>
> This is exactly my point: there might be so many signs everywhere warning
> about meteorites, that they obscure the more ordinary ones, like stop signs.
Are you suggesting that errors involving code that modifies things that
shouldn't be modified are comparable in rarity to meteorites?
--
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-20 23:41 +0100 |
| Message-ID | <94Y4v.71565$q95.37515@fx22.am4> |
| In reply to | #43193 |
"Keith Thompson" <kst-u@mib.org> wrote in message news:lny4yz1yh4.fsf@nuthaus.mib.org... > "BartC" <bc@freeuk.com> writes: >> "Keith Thompson" <kst-u@mib.org> wrote in message >> news:lnwqek3kv4.fsf@nuthaus.mib.org... >>> "BartC" <bc@freeuk.com> writes: >> >>>> There are plenty of other things to worry about. If you are calling >>>> a function which does in-place modifications of an argument, then >>>> you need to know about it, as you might not want that to happen even >>>> if your string is writeable; you just don't want it written to by >>>> that function. >>> >>> Exactly -- and you can express that by defining that function's >>> parameter as "const char*". >> >> That won't work: >> >> (1) The function *needs* to modify the thing pointed to by its argument > > Then I must have misunderstood. You said "you just don't want it > written to by that function". Can you clarify? Does the function > modify the string or not? Yes it does. I'm just saying there are plenty of situations where functions modify string arguments etc, but you don't want your data changed. 'const' is only of use in certain places. >>> strlen(s); /* strlen() promises not to modify the string */ >> >> In the case of strlen(), a short note in the function docs can state the >> same thing. > > Sure, but it doesn't have to, because we have "const". Which in this case, isn't very useful: you can pass writeable or read-only strings to it, just like you can to a function not using 'const'; what have we gained? (Maybe the compiler can find these useful hints to do help with optimising and stuff, but it doesn't do much for the clarity of the source code.) >>> I might be hit by a meteorite; why bother to wear a seatbelt? >> >> This is exactly my point: there might be so many signs everywhere warning >> about meteorites, that they obscure the more ordinary ones, like stop >> signs. > > Are you suggesting that errors involving code that modifies things that > shouldn't be modified are comparable in rarity to meteorites? Well, issues linked to const or non-const arguments are as rare as meteorite strikes in my programming. Take this fragment of code posted by Stefan Ram in 'question about scanf': char const * const string = "abc17"; char const * p = string; Maybe he was being deliberately obfuscatory here, or maybe not. But those consts do nothing for the clarity of the code (actually they make things worse: I didn't know you could write char const as well as const char; I thought I had that sussed). Maybe they will help trap any attempts to write via the pointer p, but then the code will likely not work anyway. But there are plenty of other ways to shoot yourself in the foot (running past the end of the string for example). All I know is the code is much easier on the eye without those consts. I mean, most people surely don't bother with marking arbitrary files in their file systems as read-only, why the need to do it with type-specs in a language? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-04-21 11:14 +1200 |
| Message-ID | <brj2n3F43uvU6@mid.individual.net> |
| In reply to | #43200 |
BartC wrote: > "Keith Thompson" <kst-u@mib.org> wrote in message > news:lny4yz1yh4.fsf@nuthaus.mib.org... >> "BartC" <bc@freeuk.com> writes: >>> "Keith Thompson" <kst-u@mib.org> wrote in message >>> news:lnwqek3kv4.fsf@nuthaus.mib.org... >>>> "BartC" <bc@freeuk.com> writes: >>> >>>>> There are plenty of other things to worry about. If you are calling >>>>> a function which does in-place modifications of an argument, then >>>>> you need to know about it, as you might not want that to happen even >>>>> if your string is writeable; you just don't want it written to by >>>>> that function. >>>> >>>> Exactly -- and you can express that by defining that function's >>>> parameter as "const char*". >>> >>> That won't work: >>> >>> (1) The function *needs* to modify the thing pointed to by its argument >> >> Then I must have misunderstood. You said "you just don't want it >> written to by that function". Can you clarify? Does the function >> modify the string or not? > > Yes it does. I'm just saying there are plenty of situations where functions > modify string arguments etc, but you don't want your data changed. 'const' > is only of use in certain places. The above is a very vexing parse! Care to elabourate? >>>> strlen(s); /* strlen() promises not to modify the string */ >>> >>> In the case of strlen(), a short note in the function docs can state the >>> same thing. >> >> Sure, but it doesn't have to, because we have "const". > > Which in this case, isn't very useful: you can pass writeable or read-only > strings to it, just like you can to a function not using 'const'; what have > we gained? Clarity without he need for a comment. In the C++ world (or with strong warnings with some C compilers), no diagnostic message. Lack of const in parameter declarations is a silent accident waiting to happen in C and a pain in the arse in C++. <snip> > Maybe they will help trap any attempts to write via the pointer p, but then > the code will likely not work anyway. But there are plenty of other ways to > shoot yourself in the foot (running past the end of the string for example). > All I know is the code is much easier on the eye without those consts. The are plenty of ways to get killed in a car crash, but are they valid reasons not to wear a seat belt? > I mean, most people surely don't bother with marking arbitrary files in > their file systems as read-only, why the need to do it with type-specs in a > language? Conscientious admins often do. We also mark whole filesystems as read only as a security measure. See the analogy? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-21 13:05 +0100 |
| Message-ID | <_R75v.39470$Y24.28756@fx03.am4> |
| In reply to | #43202 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:brj2n3F43uvU6@mid.individual.net... > BartC wrote: >> I mean, most people surely don't bother with marking arbitrary files in >> their file systems as read-only, why the need to do it with type-specs in >> a >> language? > > Conscientious admins often do. We also mark whole filesystems as read > only as a security measure. See the analogy? Does marking a top-level path as read-only protect also the paths and files lower down, whatever their individual attributes? (As write-protect might work with removable media.) If so, then that's not how const works in C. If you have a file F within a directory hierarchy like this: /A/B/C/F And A is read-only, while F is read-write, then in C, you could still modify F. You just couldn't change A itself. That's a complicated way of doing it; a single top-level attribute would have been better. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-21 11:11 -0700 |
| Message-ID | <ln4n1m1rjp.fsf@nuthaus.mib.org> |
| In reply to | #43223 |
"BartC" <bc@freeuk.com> writes:
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:brj2n3F43uvU6@mid.individual.net...
>> BartC wrote:
>>> I mean, most people surely don't bother with marking arbitrary files in
>>> their file systems as read-only, why the need to do it with type-specs in
>>> a
>>> language?
>>
>> Conscientious admins often do. We also mark whole filesystems as read
>> only as a security measure. See the analogy?
For example, system executables are typically under /bin and/or
/usr/bin, and are generally read-only for all but the root user.
I *hope* you wouldn't suggest allowing ordinary users to modify
files under /bin.
> Does marking a top-level path as read-only protect also the paths and files
> lower down, whatever their individual attributes? (As write-protect might
> work with removable media.)
Assuming we're talking about a Unix-like file system, no, it doesn't.
> If so, then that's not how const works in C. If you have a file F within a
> directory hierarchy like this:
>
> /A/B/C/F
>
> And A is read-only, while F is read-write, then in C, you could still modify
> F. You just couldn't change A itself.
Exactly.
> That's a complicated way of doing it; a single top-level attribute would
> have been better.
Unix-like systems allow you (at an administrative level) to mark
an entire file system as read-only. They also allow you (at a
user level) to mark individual files and directories as read-only.
You can read a file only if both the file system settings and the
permissions on the file permit it.
If you want to mark an entire hierarchy of files and directories
as read-only, you have to change the permissions for everything in
that hierarchy -- which is easy enough to do ("chmod -R -w ...").
A single top-level attribute would be much less flexible.
I'm not sure this is a useful analogy for C "const" semantics.
--
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-20 19:44 -0700 |
| Message-ID | <lnha5n1jv9.fsf@nuthaus.mib.org> |
| In reply to | #43200 |
"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lny4yz1yh4.fsf@nuthaus.mib.org...
>> "BartC" <bc@freeuk.com> writes:
>>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>> news:lnwqek3kv4.fsf@nuthaus.mib.org...
>>>> "BartC" <bc@freeuk.com> writes:
>>>
>>>>> There are plenty of other things to worry about. If you are calling
>>>>> a function which does in-place modifications of an argument, then
>>>>> you need to know about it, as you might not want that to happen even
>>>>> if your string is writeable; you just don't want it written to by
>>>>> that function.
>>>>
>>>> Exactly -- and you can express that by defining that function's
>>>> parameter as "const char*".
>>>
>>> That won't work:
>>>
>>> (1) The function *needs* to modify the thing pointed to by its argument
>>
>> Then I must have misunderstood. You said "you just don't want it
>> written to by that function". Can you clarify? Does the function
>> modify the string or not?
>
> Yes it does. I'm just saying there are plenty of situations where functions
> modify string arguments etc, but you don't want your data changed. 'const'
> is only of use in certain places.
I still honestly don't know what you're talking about.
If you don't want your data changed, don't pass it to a function that's
going to change it.
If you define your data as "const", and you're calling a function that
doesn't use "const" on its parameter declaration, then the compiler will
diagnose an attempt to call the function.
>>>> strlen(s); /* strlen() promises not to modify the string */
>>>
>>> In the case of strlen(), a short note in the function docs can state the
>>> same thing.
>>
>> Sure, but it doesn't have to, because we have "const".
>
> Which in this case, isn't very useful: you can pass writeable or read-only
> strings to it, just like you can to a function not using 'const'; what have
> we gained?
The "const" on strlen's parameter doesn't enforce any restriction on the
argument you pass it; rather, it allows you to pass either const or
non-const data. Removing the "const" (implying that strlen might modify
the string) would cause the compiler to diagnose any attempt to call the
function with a pointer to non-const data (with the previously discussed
loophole for string literals). For example, this requires a diagnostic:
void transmogrify(char *param) {
}
int main(void) {
const char arg[] = "hello";
transmogrify(arg);
}
Sure, you could avoid all those annoying diagnostics by removing "const"
from the language -- but then the compiler couldn't warn you about
incorrect code that modifies read-only data.
[...]
> Take this fragment of code posted by Stefan Ram in 'question about scanf':
>
> char const * const string = "abc17";
> char const * p = string;
>
> Maybe he was being deliberately obfuscatory here, or maybe not. But those
> consts do nothing for the clarity of the code (actually they make things
> worse: I didn't know you could write char const as well as const char; I
> thought I had that sussed).
The flexibility in where "const" can be placed is admittedly
unfortunate. But each of the three occurrences of "const" in that code
is a compiler-enforced assertion that something won't be modified.
> Maybe they will help trap any attempts to write via the pointer p, but then
> the code will likely not work anyway. But there are plenty of other ways to
> shoot yourself in the foot (running past the end of the string for example).
> All I know is the code is much easier on the eye without those consts.
If my code isn't going to work, I'd much rather find out about it when I
try to compile it.
Personally, I think C and most other languages got this whole thing
backwards. If I were designing a new language from scratch, with no
concern for backward compatibility, I'd make everything read-only by
default, with an explicit qualifier (perhaps "var") to mark objects as
writable. Of course that can't be done for C.
> I mean, most people surely don't bother with marking arbitrary files in
> their file systems as read-only, why the need to do it with type-specs in a
> language?
--
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-21 10:51 +0100 |
| Message-ID | <kT55v.39457$Y24.3511@fx03.am4> |
| In reply to | #43206 |
"Keith Thompson" <kst-u@mib.org> wrote in message news:lnha5n1jv9.fsf@nuthaus.mib.org... > "BartC" <bc@freeuk.com> writes: >> Yes it does. I'm just saying there are plenty of situations where >> functions >> modify string arguments etc, but you don't want your data changed. >> 'const' >> is only of use in certain places. "Ian Collins" <ian-news@hotmail.com> wrote in message news:brj2n3F43uvU6@mid.individual.net... > The above is a very vexing parse! Care to elabourate? "Keith Thompson" <kst-u@mib.org> wrote: > I still honestly don't know what you're talking about. Take any function F having a T* parameter (any sort of pointer). Take any call passing it a T* argument. 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. You might try casting the argument to (const T*), but then you just get a compiler error here; what good will that do? You need to call F, so a solution has to be found. And you wouldn't have deliberately put in this cast unless you'd already researched the side-effects of F, in which case you don't need the compiler to tell you what you already know! Or maybe you routinely just use (const T*) casts everywhere you ever pass a pointer to anything, but then I wouldn't want to have to read your code! Actually I can't see point of using 'const T*' as any function parameter type, since it will accept both const and non-const arguments (but see below). Using T* for a parameter and 'const T*' for the argument, I can sort of see the point of, for the small number cases where the caller's data genuinely is read-only (but one of the most common examples of such data, a string constant, is let through.) > If you don't want your data changed, don't pass it to a function that's > going to change it. The function may need to write to the data to do its job. (The alternative might be for it to allocate memory, copy the data, then de-allocate, all extra overhead and extra memory.) Provided the side-effects are documented, this might be acceptable to some callers. Otherwise the caller can choose to provide a copy. >> Which in this case, isn't very useful: you can pass writeable or >> read-only >> strings to it, just like you can to a function not using 'const'; what >> have >> we gained? > > The "const" on strlen's parameter doesn't enforce any restriction on the > argument you pass it; rather, it allows you to pass either const or > non-const data. Removing the "const" (implying that strlen might modify > the string) would cause the compiler to diagnose any attempt to call the > function with a pointer to non-const data (with the previously discussed > loophole for string literals). Then you also get rid of the compiler checks at the same time. (Don't forget in this sub-thread we were discussing removing 'const' from the language.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-21 13:29 -0400 |
| Message-ID | <5355557F.9070206@verizon.net> |
| In reply to | #43222 |
On 04/21/2014 05:51 AM, BartC wrote: ... > Take any function F having a T* parameter (any sort of pointer). > > Take any call passing it a T* argument. > > 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. Error messages are precisely the kind of help that is provided as a result of using 'const'. If you prefer not to be informed about the fact that a given line of code attempts to modify something that should not be modified, don't use it. > You might try casting the argument to (const T*), but then you just get a > compiler error here; what good will that do? You need to call F, so a > solution has to be found. Yes, either find an alternative to F that doesn't modify the data, or copy the data to a location where it doesn't matter if the data is modified, and pass the modified location to F. Correct use of 'const' results in a warning that you need to choose one of these alternatives. Never using 'const' means you get no such warning. > Or maybe you routinely just use (const T*) casts everywhere you ever pass a > pointer to anything, but then I wouldn't want to have to read your code! It's hard to come up with a situation where (const T*) is needed, since a T* value can be used just about anywhere that a const T* is called for. It's the opposite direction where a cast is needed: if you have a const T*, and you need to pass it to a function which will not be modifying it, but the function declares the corresponding parameter as a T*. Such casts are dangerous, because you're placing your trust in the author of that function to not attempt to modify the object pointed at. If he doesn't understand C well enough to understand why the parameter should have been declared 'const T*', there's a serious risk that such trust is not deserved. > Actually I can't see point of using 'const T*' as any function parameter > type, since it will accept both const and non-const arguments (but see > below). It should only be used for a given function parameter when the function will NOT be modifying anything by dereferencing the pointer. If that's the case, it's equally safe to pass either a const T* or a T* through that parameter - why shouldn't it be allowed? it's the other way around that is the dangerous case that should not be allowed, and is therefore a constraint violation. > Using T* for a parameter and 'const T*' for the argument, I can sort of see > the point of, Such code is in fact pointless: if the parameter is T*, that means the thing it points at might get modified. If the corresponding argument is const T*, that means that the thing it points at should not be modified. Passing such an argument through such a parameter is necessarily a logic error: it puts something that should not be modified at risk of being modified. That's why such code is a constraint violation. Mandating that a diagnostic be produced in this case is one of the key purposes for using 'const'. Thinking that such code has a point betrays a complete misunderstanding of what 'const' is for. I'm having a lot of trouble figuring out what the nature of your misunderstanding is. >> If you don't want your data changed, don't pass it to a function that's >> going to change it. > > The function may need to write to the data to do its job. Which is why data that should NOT be written to should not be passed to to the function. Guaranteeing that attempting to do so will generate a diagnostic is the advantage that is obtained by declaring the argument 'const'. > (The alternative > might be for it to allocate memory, copy the data, then de-allocate, all > extra overhead and extra memory.) Provided the side-effects are documented, > this might be acceptable to some callers. Otherwise the caller can choose to > provide a copy. Declaring the corresponding parameter without 'const', and declaring the data with 'const', and getting a diagnostic message when the discrepancy is detected, is far more reliable than counting upon users to remember the documented requirements.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-21 11:04 -0700 |
| Message-ID | <ln8uqy1rva.fsf@nuthaus.mib.org> |
| In reply to | #43222 |
"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnha5n1jv9.fsf@nuthaus.mib.org...
>> "BartC" <bc@freeuk.com> writes:
>
>>> Yes it does. I'm just saying there are plenty of situations where
>>> functions
>>> modify string arguments etc, but you don't want your data changed.
>>> 'const'
>>> is only of use in certain places.
>
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:brj2n3F43uvU6@mid.individual.net...
>
>> The above is a very vexing parse! Care to elabourate?
>
> "Keith Thompson" <kst-u@mib.org> wrote:
>
>> I still honestly don't know what you're talking about.
>
> Take any function F having a T* parameter (any sort of pointer).
>
> Take any call passing it a T* argument.
>
> 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. If the caller correctly
declares its data as "const", then the compiler will warn about any
attempt to pass it to F.
> You might try casting the argument to (const T*), but then you just get a
> compiler error here; what good will that do? You need to call F, so a
> solution has to be found. And you wouldn't have deliberately put in this
> cast unless you'd already researched the side-effects of F, in which case
> you don't need the compiler to tell you what you already know!
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).
> Or maybe you routinely just use (const T*) casts everywhere you ever pass a
> pointer to anything, but then I wouldn't want to have to read your code!
>
> Actually I can't see point of using 'const T*' as any function parameter
> type, since it will accept both const and non-const arguments (but see
> below).
Yes, a function with a "const T*" parameter will accept both "T*" and
"const T*" arguments. A function with a "T* parameter will accept "T*"
argument, but *not* "const T*" arguments -- because by defining the
argument as "const T*", you're saying you don't want the data modified,
but the function, by not using "const", does not promise not to modify
it.
If you take a correct program and remove all occurrences of "const"
(including those in the standard library), you'll still have a correct
program.
The purpose of "const" is entirely to detect logical errors at
compilation time. You have to use it consistently and correctly to
enable it to do so.
> Using T* for a parameter and 'const T*' for the argument, I can sort of see
> the point of, for the small number cases where the caller's data genuinely
> is read-only (but one of the most common examples of such data, a string
> constant, is let through.)
>
>> If you don't want your data changed, don't pass it to a function that's
>> going to change it.
>
> The function may need to write to the data to do its job.
Then you can't call it with data that you don't want modified.
[...]
>> The "const" on strlen's parameter doesn't enforce any restriction on the
>> argument you pass it; rather, it allows you to pass either const or
>> non-const data. Removing the "const" (implying that strlen might modify
>> the string) would cause the compiler to diagnose any attempt to call the
>> function with a pointer to non-const data (with the previously discussed
>> loophole for string literals).
>
> Then you also get rid of the compiler checks at the same time.
Right, which is exactly why removing the "const" on strlen's parameter
would be a bad idea.
> (Don't forget
> in this sub-thread we were discussing removing 'const' from the language.)
I'm talking about the problems that would be caused if "const" were
removed from the language; briefly, it would become more difficult to
write correct code. I've never advocated removing "const" from the
language. Are you advocating that?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-22 11:31 +0100 |
| Message-ID | <Yyr5v.88516$q95.40464@fx22.am4> |
| In reply to | #43240 |
"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). > 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) 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. 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. 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. 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 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. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2014-04-22 06:24 -0500 |
| Message-ID | <lj5jh3$s1j$1@dont-email.me> |
| In reply to | #43272 |
On 4/22/2014 5:31 AM, 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). There are many ways to get the job done otherwise. Call something that does what F does but doesn't modify the string. Make a copy of the string and pass that to F. Find a way to get the larger task done that doesn't need to call F. Etc. Another possibility is that the attempt to call F was a mistake on the programmer's part. Personally, I think C made the right choice in assuming that the attempt to call F was a mistake on the programmer's part. By doing so, and warning the programmer during the compilation, the programmer has the ability to fix the problem. If you where to have the compiler automatically create a copy and pass it to F, then the program would silently be wrong if that wasn't the correct way to get the job done. >> 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) Of course you don't case at every single call. Usually when something needs to be unchanged, you either create the object as a const or you extract the portion of the code into a function that has a pointer to const as a parameter. No casts are needed. > 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. > > 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. So pass a copy. I don't see what the problem is here. > 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. > > 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 by warning you if you mistakenly pass it something that shouldn't be changed. > > 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. > Such as? Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-22 13:34 +0100 |
| Message-ID | <bnt5v.82426$AI5.17629@fx32.am4> |
| In reply to | #43275 |
"Martin Shobe" <martin.shobe@yahoo.com> wrote in message
news:lj5jh3$s1j$1@dont-email.me...
>> 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 by warning you if you mistakenly pass it something that shouldn't
> be changed.
Take this code:
/* somewhere in an external library */
void show_inverted(Image_t bm) {
.....
}
/* In your code */
Image_t img;
.... hundreds of lines later...
show_inverted(img);
But you understand that either (1) show_inverted() requires the image to be
writeable, but is unchanged at the end; or (2) show_inverted() will corrupt
the image. How best to make use of 'const' here?
Maybe, you change all these calls (if you have many dozens of them scattered
everywhere) so that they look like this:
show_inverted((const Image_t)img);
But a few problems with this:
(1) It's very ugly.
(2) With more elaborate calls the casts will dominate the names of the
arguments, increasing the possibility of error.
(3) If you have N calls to show_inverted() in your code for each name 'img',
then instead of one 'Image_t', you now have N+1 to maintain. And with
complex code you have to go and look for the actual type. You might also
make some typos on those N extra casts, resulting in one that will still
compile, but is now wrong.
(4) You may not have enough information about 'Image_t' to establish whether
just sticking a 'const' in front will actually do the trick. For example, if
Image_t is just a struct, which is passed by value anyway, then a const
qualifier on the argument is a waste of time.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-22 09:19 -0400 |
| Message-ID | <lj5q87$8v7$1@dont-email.me> |
| In reply to | #43280 |
On 04/22/2014 08:34 AM, BartC wrote:
> "Martin Shobe" <martin.shobe@yahoo.com> wrote in message
> news:lj5jh3$s1j$1@dont-email.me...
>
>>> 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 by warning you if you mistakenly pass it something that shouldn't
>> be changed.
>
> Take this code:
>
> /* somewhere in an external library */
> void show_inverted(Image_t bm) {
> .....
> }
You've just declared show_inverted as taking bm by value. If
show_inverted is going to contain a copy of the original image, then no
problem occurs if it modifies that copy, and there is therefore no
reason why you need to use const.
If, on the other hand, "Image_t" is a typedef for a pointer, such as
"struct Image*", then this provides a prime example why it's a bad idea
to define such typedefs. What you need, in order to properly protect
certain pieces of code, is the ability to declare some pointers as
"const struct Image*", and you can't construct such a type using that
typedef. "const Image_t" is equivalent to "Image_t const" - both mean
"struct Image * const", which is a very different type from "struct
Image const *". "struct Image * const" means that the pointer value
should not be written to, whereas "struct Image const*" means the same
thing as "const struct Image*", which is that the object pointed at
should not be written to.
> /* In your code */
> Image_t img;
>
> .... hundreds of lines later...
>
> show_inverted(img);
>
> But you understand that either (1) show_inverted() requires the image to be
> writeable, but is unchanged at the end; or (2) show_inverted() will corrupt
> the image. How best to make use of 'const' here?
>
> Maybe, you change all these calls (if you have many dozens of them scattered
> everywhere) so that they look like this:
>
> show_inverted((const Image_t)img);
>
> But a few problems with this:
(0) It has no useful effect.
It's possible to declare objects as 'const' in themselves, but only if
they never need to be modified after initialization, which is fairly
unusual, especially for large objects, (such as those that might contain
an entire image). More commonly, 'const' is used in 'const T*', to mark
the object pointed at as something that should not be modified. A
pointer to a non-const object will end up being converted to "const T*",
but almost never by explicit conversion. It usually is done by passing a
"T*" argument to a function declared as taking a "const T*" parameter -
precisely the situation you complained about being allowed in an earlier
message. Allowing such implicit conversions is a key part of what makes
'const' useful - saying that the reverse conversion can NOT occur
implicitly is another key part.
It's also feasible to do such an implicit conversion without a function
call:
struct Image img;
// code that fills in img
const struct Image *cpimg = &img;
// Code that uses cpimg to do thing that should not modify 'img'.
Within the scope of a "const T*" declaration, the 'const' ensures that
attempts to modify the pointed-at object through that pointer will be
constraint violations, guaranteeing that you will be warned of the
necessity of re-writing your code to avoid that problem. Such code is
problematic, whether or not 'const' is used. 'const' serves only to
enable warnings about such code.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-22 15:00 +0100 |
| Message-ID | <MCu5v.82427$AI5.2818@fx32.am4> |
| In reply to | #43283 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message
news:lj5q87$8v7$1@dont-email.me...
> On 04/22/2014 08:34 AM, BartC wrote:
>> "Martin Shobe" <martin.shobe@yahoo.com> wrote in message
>> news:lj5jh3$s1j$1@dont-email.me...
>>
>>>> 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 by warning you if you mistakenly pass it something that
>>> shouldn't
>>> be changed.
>>
>> Take this code:
>>
>> /* somewhere in an external library */
>> void show_inverted(Image_t bm) {
>> .....
>> }
>
> You've just declared show_inverted as taking bm by value. If
> show_inverted is going to contain a copy of the original image, then no
> problem occurs if it modifies that copy, and there is therefore no
> reason why you need to use const.
> If, on the other hand, "Image_t" is a typedef for a pointer, such as
> "struct Image*", then this provides a prime example why it's a bad idea
> to define such typedefs. What you need, in order to properly protect
> certain pieces of code, is the ability to declare some pointers as
> "const struct Image*", and you can't construct such a type using that
> typedef. "const Image_t" is equivalent to "Image_t const" - both mean
> "struct Image * const", which is a very different type from "struct
> Image const *". "struct Image * const" means that the pointer value
> should not be written to, whereas "struct Image const*" means the same
> thing as "const struct Image*", which is that the object pointed at
> should not be written to.
This is more a prime example of why const is of limited use.
Image_t is supposed to be an opaque type, in reality probably some sort of
handle implemented as a pointer (to a descriptor which itself points to the
data) or struct, which implements the descriptor.
It might happen that a pointer directly points to the image data, but that
would be unusual; that might be the case at a lower level where you have to
pass dimensions, image depth etc. explicitly.
But with all these possibilities:
* A typedef-ed pointer to a descriptor
* A typedef-ed descriptor struct
* Some typedef-ed index into a table of image descriptors
* Even a typedef-ed pointer to raw image data
* Etc.
You can't protect the data with a simple const cast. That only works with a
simple non-typedef-ed pointer to image data (where you have to deal with
other details of the image that you would not need to bother with, using the
opaque type).
And without having this knowledge, const would be useless. (And even with
the knowledge, it's a bad idea to use const, as the idea of using an opaque
type is that the implemention could change, but ought to still work, after
recompiling.)
>> But a few problems with this:
>
> (0) It has no useful effect.
You finally agree with me!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-22 07:53 -0700 |
| Message-ID | <lnbnvtza8o.fsf@nuthaus.mib.org> |
| In reply to | #43287 |
"BartC" <bc@freeuk.com> writes:
> "James Kuyper" <jameskuyper@verizon.net> wrote in message
> news:lj5q87$8v7$1@dont-email.me...
>> On 04/22/2014 08:34 AM, BartC wrote:
>>> "Martin Shobe" <martin.shobe@yahoo.com> wrote in message
>>> news:lj5jh3$s1j$1@dont-email.me...
>>>
>>>>> 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 by warning you if you mistakenly pass it something that
>>>> shouldn't be changed.
>>>
>>> Take this code:
>>>
>>> /* somewhere in an external library */
>>> void show_inverted(Image_t bm) {
>>> .....
>>> }
[...]
>
> This is more a prime example of why const is of limited use.
>
> Image_t is supposed to be an opaque type, in reality probably some sort of
> handle implemented as a pointer (to a descriptor which itself points to the
> data) or struct, which implements the descriptor.
>
> It might happen that a pointer directly points to the image data, but that
> would be unusual; that might be the case at a lower level where you have to
> pass dimensions, image depth etc. explicitly.
>
> But with all these possibilities:
>
> * A typedef-ed pointer to a descriptor
> * A typedef-ed descriptor struct
> * Some typedef-ed index into a table of image descriptors
> * Even a typedef-ed pointer to raw image data
> * Etc.
>
> You can't protect the data with a simple const cast. That only works with a
> simple non-typedef-ed pointer to image data (where you have to deal with
> other details of the image that you would not need to bother with, using the
> opaque type).
The "simple const cast" you keep talking about *doesn't do anything*.
If you don't understand that, we're not going to get anywhere.
The functions declared in <stdio.h> are similar to what you're talking
about. FILE is an opaque type, and the functions take FILE* arguments.
They can modify the contents of the FILE object. None of those
functions take a "const FILE*" argument. The caller doesn't need to
know what's inside the FILE object.
You can write code that doesn't use "const" if it makes sense to do so,
and the existence of "const" doesn't make it inconvenient to do so.
> And without having this knowledge, const would be useless. (And even with
> the knowledge, it's a bad idea to use const, as the idea of using an opaque
> type is that the implemention could change, but ought to still work, after
> recompiling.)
>
>>> But a few problems with this:
>>
>> (0) It has no useful effect.
>
> You finally agree with me!
The cast that you introduced to this discussion makes no sense. It's a
misuse of "const" and of casting.
This:
func((const char*)arg);
is effectively equivalent to this:
func(arg);
regardless of how func defines its parameter. This does not constitute
an argument against proper use of "const".
--
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-22 12:48 -0400 |
| Message-ID | <53569D47.5000705@verizon.net> |
| In reply to | #43287 |
On 04/22/2014 10:00 AM, BartC wrote:
> "James Kuyper" <jameskuyper@verizon.net> wrote in message
> news:lj5q87$8v7$1@dont-email.me...
>> On 04/22/2014 08:34 AM, BartC wrote:
...
>>> /* somewhere in an external library */
>>> void show_inverted(Image_t bm) {
>>> .....
>>> }
>>
>> You've just declared show_inverted as taking bm by value. If
>> show_inverted is going to contain a copy of the original image, then no
>> problem occurs if it modifies that copy, and there is therefore no
>> reason why you need to use const.
>
>> If, on the other hand, "Image_t" is a typedef for a pointer, such as
>> "struct Image*", then this provides a prime example why it's a bad idea
>> to define such typedefs. What you need, in order to properly protect
>> certain pieces of code, is the ability to declare some pointers as
>> "const struct Image*", and you can't construct such a type using that
>> typedef. "const Image_t" is equivalent to "Image_t const" - both mean
>> "struct Image * const", which is a very different type from "struct
>> Image const *". "struct Image * const" means that the pointer value
>> should not be written to, whereas "struct Image const*" means the same
>> thing as "const struct Image*", which is that the object pointed at
>> should not be written to.
>
> This is more a prime example of why const is of limited use.
>
> Image_t is supposed to be an opaque type,
The following is a fully opaque type:
typedef struct Image Image_t;
You should generally avoid hiding the fact that something is a pointer
or an array by using a typedef. C provides several syntactic features
(pointers to qualified types is just one example) that can lead to
considerable confusion if the use of a typedef is not aware of the fact
that it is a pointer or an array.
...
>>> But a few problems with this:
>>
>> (0) It has no useful effect.
>
> You finally agree with me!
No, you believe that 'const' has no useful effect. I believe that
misusing 'const' in the way you've suggested serves no useful effect,
while 'const', properly used, can be very useful. The fact that you
suggested misusing 'const' in that fashion suggests an extremely severe
misunderstanding of what 'const' means, that calls into question the
validity of all of your judgements about its usefulness.
[toc] | [prev] | [next] | [standalone]
Page 2 of 14 — ← Prev page 1 [2] 3 4 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web