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 12 of 14 — ← Prev page 1 … 10 11 [12] 13 14 Next page →
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2014-04-24 14:03 -0500 |
| Message-ID | <ljbn6d$ofk$1@dont-email.me> |
| In reply to | #43452 |
On 23-Apr-14 13:42, Kaz Kylheku wrote: > On 2014-04-23, Keith Thompson <kst-u@mib.org> wrote: >> "BartC" <bc@freeuk.com> writes: [...] >>> As someone said (maybe it was you, maybe Keith), you can taking a >>> working program, edit all the 'const's out of it, and it should >>> still compile and work. That doesn't sound like a feature that is >>> indispensible! >> >> It's not indispensible (C got along without it for a number of >> years), but it's useful for catching errors. >> >> Prior to the 1989 ANSI C standard, C did not distinguish between >> const (read-only) and non-const (writable) data. >> >> I've read about some oldish language, predating C, that didn't >> distinguish between integer and floating-point data. It had >> separate operators for integer and floating-point addition, >> likewise for multiplication, et al. It was up to the programmer >> to keep track of the "type" of a given variable and apply the >> correct operators. >> >> C doesn't have those operators, nor does it let you declare >> variables without specifying their type, but if it did, you could >> take a working C program that uses both integers and floating point >> and translate it to something that doesn't specify the types of >> variables, and it would still work correctly. But if you modify >> the resulting program, you'd have to be very careful to apply the >> correct operators. > > That is not comparable to removing const; const is not involved in > any decisions involving polymorphic dispatch. It does not provide > type inference. > > In C++ it does, and so in C++ you cannot remove const from programs, > in general, without turning them into a mess that requires a > diagnostic. Without references, any non-trivial C++ program would infinitely recurse at the first copy constructor it encountered, and references are unsafe without const. Once C++ needed const for references, it needed them for pointers since that's how references are implemented, and extending const to the rest of the type system was obvious. Then const migrated to C, for consistency and (most importantly) headers that are compiled in both languages. > When const is fastidiously applied throughout a code base (it > adheres to "const correctness") then programmers are free to assume > that if a function has a "const type *x" parameter, then the function > does not modify *x. And, conversely, if the parameter is "type *x", > there is a strong reason to suspect that the funtion does modify *x; > because otherwise, in keeping with "const correctness", it would have > been declared otherwise. > > This can be helpful, because it is quite important to know which > functions parameters are pure, and which mutate. If the declaration, > or a comment next to it, do not answer the question, the programmer > has to waste time investigating this. Also, if a function takes a const argument, then it can only pass it to other functions taking a const argument. This often results in what is known as "const poisoning": if one function uses const, it ends up spreading across the entire codebase. OTOH, this process tends to uncover latent bugs, so it's actually good for you in the end. 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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-23 20:49 +0000 |
| Message-ID | <lj991d$90s$1@speranza.aioe.org> |
| In reply to | #43437 |
BartC <bc@freeuk.com> wrote: (snip, someone wrote) >> Your mistake lies in assuming that the 'const' protects the >> file managed by the FILE object. It only protects the FILE >> object itself. > I don't care about modifying the FILE object. Only about the file. Depending on buffering, it might be that only fclose() actually modifies the file. Many people aren't good at checking the return values from file write operations, especially fclose(). You might be surprised sometime. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-23 21:21 +0000 |
| Message-ID | <20140423141404.483@kylheku.com> |
| In reply to | #43461 |
On 2014-04-23, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > BartC <bc@freeuk.com> wrote: > > (snip, someone wrote) >>> Your mistake lies in assuming that the 'const' protects the >>> file managed by the FILE object. It only protects the FILE >>> object itself. > >> I don't care about modifying the FILE object. Only about the file. > > Depending on buffering, it might be that only fclose() actually > modifies the file. Many people aren't good at checking the return > values from file write operations, especially fclose(). fclose is sometimes called in inconvenient situations, like the finalization of an object that no part of the program "cares" about any more, which happens to hold a stream resource. A failure in fclose cannot be handled in any reasonable way because it is a failure in an object that nobody cares about. The trick is to flush the output while the object still matters, and perhaps even do the fclose earlier, so that by the time the object is finalized, the stream is already gone (indicated by a null FILE * pointer or whatever). Anyway, if you've done fflush on the stream successfully, and fclose fails, there probably isn't any need to take any action, so why bother checking. At least for regular files. On some devices, like network sockets, closing may initiate a communication handshake which is separate from previously transmitted data. Moreover, a fflush doesn't necessarily indicate that the data have been transmitted to the remote host and acknowledged. A naive "close and forget" can trigger an abort, causing not all the previously data to be transmitted, in spite of an fflush. This isn't a problem that can be easily solved with some combination of calls to the standard library (if you're wrapping sockets with that, which is both possible and convenient). Basically, you need an application level acknowledgement that everything has been received. If you have that, and do not send any more data, you can fclose the connection and ignore the return value.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2014-04-23 10:50 -0500 |
| Message-ID | <lj8ngl$sn6$1@dont-email.me> |
| In reply to | #43412 |
On 23-Apr-14 05:56, BartC wrote:
> "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.
Well, I'd classify it as a guard against accidents, not malice.
> 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 generates a warning because fseek() modifies the FILE object,
specifically the current offset into the file. This is correct.
OTOH, ftell() should accept a const argument since it _doesn't_ modify
the FILE object.
Do you not see the difference?
> But do people actually make use of const when working with
> file-processing functions?
I've never seen it done, but I also can't think of a context where that
would make sense anyway.
> If not, then they might well find that not
> bothering with const works elsewhere too!
C got along okay for years without "const"; it's not critical to making
code work, but it helps find many bugs (sooner) when used correctly.
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 | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2014-04-22 19:41 -0500 |
| Message-ID | <lj7288$9m2$1@dont-email.me> |
| In reply to | #43319 |
On 22-Apr-14 12:48, BartC wrote:
> "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...
>>>> 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?
// image.h
typedef /* something */ Image_t;
SomeFunction(const Image_t *img);
// caller.c
#include "image.h"
void myfunc(void) {
Image_t *x = /* something */;
const Image_t *y = x;
SomeFunction(x); // no error
SomeFunction(y); // no error
}
If SomeFunction() needs to modify the image passed, then SomeFunction(y)
can't take a const argument. So, you would modify the interface like this:
// image.h
typedef /* something */ Image_t;
CopyImage(Image_t *dst, const Image_t *src);
SomeFunction(Image_t *img);
// caller.c
#include "image.h"
void myfunc(void) {
Image_t *x = /* something */, *y;
CopyImage(y, x);
SomeFunction(x); // no error
SomeFunction(y); // no error
}
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-22 09:43 -0700 |
| Message-ID | <lnvbu1xqkf.fsf@nuthaus.mib.org> |
| In reply to | #43222 |
"BartC" <bc@freeuk.com> writes:
[...]
> 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).
[...]
More briefly (since this point may have been lost in previous walls of
text):
If you think that casting a T* argument to (const T*) does anything
at all, or if you think that anyone else in this discussion has
advocated such casts, then I submit that you do not properly
understand what "const" means in C as it's currently defined.
I advise you to correct that gap in your knowledge before criticizing
the current language definition. I'll be happy to help with any
questions.
A concrete example:
char message[] = "hello";
strlen(message);
message is non-const. strlen has a const char* parameter. No cast is
needed on the call, and adding such a cast would do nothing.
--
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 18:19 +0100 |
| Message-ID | <Exx5v.286719$H82.181892@fx23.am4> |
| In reply to | #43304 |
"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnvbu1xqkf.fsf@nuthaus.mib.org...
> "BartC" <bc@freeuk.com> writes:
> [...]
>> 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).
> [...]
>
> More briefly (since this point may have been lost in previous walls of
> text):
>
> If you think that casting a T* argument to (const T*) does anything
> at all, or if you think that anyone else in this discussion has
> advocated such casts, then I submit that you do not properly
> understand what "const" means in C as it's currently defined.
You think so?
My remark was about casting a T* argument to const T*, when passed to a
function taking a T* parameter.
It doesn't exactly do nothing:
strcpy("abc","def");
generates no warnings from gcc, but applying a cast does:
strcpy((const char*)"abc","def");
A bit of an imposition though to add everywhere.
> I advise you to correct that gap in your knowledge before criticizing
> the current language definition. I'll be happy to help with any
> questions.
> A concrete example:
>
> char message[] = "hello";
> strlen(message);
>
> message is non-const. strlen has a const char* parameter. No cast is
> needed on the call, and adding such a cast would do nothing.
Indeed. But that is not what I said, which was more along the lines of the
const in the 'const char*' formal parameter type of strlen() doing nothing,
in terms of generating warnings. (Although I will admit it might help out
the compiler with its optimising.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-22 11:45 -0700 |
| Message-ID | <lneh0pxkx0.fsf@nuthaus.mib.org> |
| In reply to | #43314 |
"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnvbu1xqkf.fsf@nuthaus.mib.org...
>> "BartC" <bc@freeuk.com> writes:
>> [...]
>>> 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).
>> [...]
>>
>> More briefly (since this point may have been lost in previous walls of
>> text):
>>
>> If you think that casting a T* argument to (const T*) does anything
>> at all, or if you think that anyone else in this discussion has
>> advocated such casts, then I submit that you do not properly
>> understand what "const" means in C as it's currently defined.
>
> You think so?
Yes.
> My remark was about casting a T* argument to const T*, when passed to a
> function taking a T* parameter.
>
> It doesn't exactly do nothing:
>
> strcpy("abc","def");
>
> generates no warnings from gcc, but applying a cast does:
>
> strcpy((const char*)"abc","def");
That's caused by string literals not being const, which I've already
acknowledged is a flaw in the language (but an unavoidable one).
I think you'll find fewer string literals in production code than in
demo code and code written by students. String data is more commonly
taken from command-line arguments, files, and so forth. And any data
that shouldn't be modified should be defined as "const" in the first
place, so no cast is needed.
For non-toy programs, rather than using a string literal directly, you
can use it as the initializer for a "const char*" or "const char[]"
object.
const char *target = "abc";
const char *source = "def";
strcpy(target, source); /* triggers a diagnostic */
> A bit of an imposition though to add everywhere.
Nobody has suggested adding casts "everywhere". Casts might be
necessary in some *rare* cases where you actually need to override
const.
Do you have an example not involving string literals?
>> I advise you to correct that gap in your knowledge before criticizing
>> the current language definition. I'll be happy to help with any
>> questions.
>
>> A concrete example:
>>
>> char message[] = "hello";
>> strlen(message);
>>
>> message is non-const. strlen has a const char* parameter. No cast is
>> needed on the call, and adding such a cast would do nothing.
>
> Indeed. But that is not what I said, which was more along the lines of the
> const in the 'const char*' formal parameter type of strlen() doing nothing,
> in terms of generating warnings. (Although I will admit it might help out
> the compiler with its optimising.)
The "const" on the definition of strlen's parameter does not result
in any additional warnings. Omitting the "const" *would* result
in additional warnings.
For example:
size_t hypothetical_strlen(char *s);
const char *message = "hello";
strlen(message); /* ok */
hypothetical_strlen(message); /* triggers a diagnostic */
The diagnostic occurs because, even though hypothetical_strlen()
presumably won't attempt to modify the string, its author failed to
specify that.
Now you could omit the const on the definition of "message" (and in fact
that was the only option before const was added to the language by the
1989 ANSI C standard). But then you would have no way to assert that an
object will not be modified, or that a function will not attempt to
modify an object whose address is passed to it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-22 20:01 +0100 |
| Message-ID | <51z5v.133010$_t1.21324@fx31.am4> |
| In reply to | #43330 |
"Keith Thompson" <kst-u@mib.org> wrote in message
news:lneh0pxkx0.fsf@nuthaus.mib.org...
> "BartC" <bc@freeuk.com> writes:
> Do you have an example not involving string literals?
void change_array(int* a) { a[0]=9999999;}
....
int data[]={10,20,30,40};
data[2]=rand();
change_array(data);
change_array((const int*)data);
The latter call generates a warning, the former doesn't.
You said this:
"If you think that casting a T* argument to (const T*) does anything
at all, or if you think that anyone else in this discussion has
advocated such casts, then I submit that you do not properly
understand what "const" means in C as it's currently defined."
Obviously applying such a cast can be made to do something.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-22 12:19 -0700 |
| Message-ID | <ln38h5xjc7.fsf@nuthaus.mib.org> |
| In reply to | #43334 |
"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lneh0pxkx0.fsf@nuthaus.mib.org...
>> "BartC" <bc@freeuk.com> writes:
>
>> Do you have an example not involving string literals?
>
> void change_array(int* a) { a[0]=9999999;}
> ....
> int data[]={10,20,30,40};
>
> data[2]=rand();
> change_array(data);
> change_array((const int*)data);
>
> The latter call generates a warning, the former doesn't.
>
> You said this:
>
> "If you think that casting a T* argument to (const T*) does anything
> at all, or if you think that anyone else in this discussion has
> advocated such casts, then I submit that you do not properly
> understand what "const" means in C as it's currently defined."
>
> Obviously applying such a cast can be made to do something.
You're right, my mistake. Adding a (const int*) cast to an argument
when the parameter is defined as "int*" does trigger a warning.
(I was thinking of the case where the parameter is defined as
"const int*".) I apologize for the confusion.
But why would you add such a cast in the first place?
I think you introduced the idea of adding numerous (const something*)
casts to function arguments as a way to fix or work around some
perceived problem.
--
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 11:01 -0500 |
| Message-ID | <lj8o58$206$1@dont-email.me> |
| In reply to | #43334 |
On 22-Apr-14 14:01, BartC wrote:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lneh0pxkx0.fsf@nuthaus.mib.org...
>> Do you have an example not involving string literals?
>
> void change_array(int* a) { a[0]=9999999;}
> .....
> int data[]={10,20,30,40};
>
> data[2]=rand();
> change_array(data);
> change_array((const int*)data);
>
> The latter call generates a warning, the former doesn't.
>
> You said this:
>
> "If you think that casting a T* argument to (const T*) does anything
> at all, or if you think that anyone else in this discussion has
> advocated such casts, then I submit that you do not properly
> understand what "const" means in C as it's currently defined."
>
> Obviously applying such a cast can be made to do something.
Well, yes, but it's a contrived example because nobody sane would ever
cast a non-const object to const in the first place.
In the real world, most objects get their constness via the type in the
argument list: the function promises not to modify them. If such a
function then calls a function that requires a non-const argument
(because it will modify the object), the compiler will generate a
warning/error to flag that mistake. No casts required.
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 | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2014-04-22 15:21 -0500 |
| Message-ID | <lj6ivk$93p$1@dont-email.me> |
| In reply to | #43314 |
On 22-Apr-14 12:19, BartC wrote:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnvbu1xqkf.fsf@nuthaus.mib.org...
>> If you think that casting a T* argument to (const T*) does
>> anything at all, or if you think that anyone else in this
>> discussion has advocated such casts, then I submit that you do not
>> properly understand what "const" means in C as it's currently
>> defined.
>
> You think so?
>
> My remark was about casting a T* argument to const T*, when passed to
> a function taking a T* parameter.
>
> It doesn't exactly do nothing:
>
> strcpy("abc","def");
>
> generates no warnings from gcc, but applying a cast does:
>
> strcpy((const char*)"abc","def");
>
> A bit of an imposition though to add everywhere.
That particular case is due to string literals not being const in C for
historical reasons, as has been previously explained to you. If they
were const (as in C++, AIUI), you wouldn't need the cast to get an error.
>> I advise you to correct that gap in your knowledge before
>> criticizing the current language definition. I'll be happy to help
>> with any questions.
>
>> A concrete example:
>>
>> char message[] = "hello";
>> strlen(message);
>>
>> message is non-const. strlen has a const char* parameter. No cast
>> is needed on the call, and adding such a cast would do nothing.
>
> Indeed. But that is not what I said, which was more along the lines
> of the const in the 'const char*' formal parameter type of strlen()
> doing nothing, in terms of generating warnings. (Although I will
> admit it might help out the compiler with its optimising.)
strlen() doesn't take a const argument to generate warnings; it does so
to allow passing a const argument _without_ generating a warning. You
can always pass a non-const argument if a const one is expected.
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 | Richard <rgrdev_@gmail.com> |
|---|---|
| Date | 2014-04-20 11:08 +0100 |
| Message-ID | <87ppkcb9e8.fsf@gmail.com> |
| In reply to | #43152 |
Keith Thompson <kst-u@mib.org> writes: > "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? Wowa. Something I agree with. Use it properly. And who cares what Richie says either. Kernighan's quote about debuggers is as worthless in this day and age. Times change. Tools change. hw changes. -- "Avoid hyperbole at all costs, its the most destructive argument on the planet" - Mark McIntyre in comp.lang.c
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-22 02:26 -0700 |
| Message-ID | <239efccc-e49f-4a96-9df4-d94c6afbeb51@googlegroups.com> |
| In reply to | #43133 |
On Saturday, April 19, 2014 9:20:03 PM UTC+1, Keith Thompson wrote: > > So what's your solution? Would you drop "const" from the language? > 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? > (C compilers typically won't warn in that case, but I don't think that's > an argument for loosening the const rules.) > Of course if you specify that string literals shall be read-only, and you try to write to one, you should have a warning. But an essential problem of language design is that people who design languages tend to take easy-to-identify programmer mistakes like that, and use them to drive the language design. In reality, if a function modifies a string, the caller is going to want to use the result. So as long as he knows that string literals are not writeable, he's unlikely to pass one, except maybe in experimental diagnostic programming. Even if he doesn't know that string literals are not writeable, only rarely will he want to modify one in place. So it's just a slight issue, which will trip up a programmer occasionally, but not very often, remembering that there will be hundreds of other logic and other errors he makes in the same program whilst it's under development. I don't have an easy answer, but essentially const makes the wrong distinction, which is between opaque and transparent pointers, not between writeable and non-writeable ones. Normally it's none of caller's business whether a subroutine is setting flags in a structure passed to it or not.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-04-22 21:36 +1200 |
| Message-ID | <brmrgnF43uvU9@mid.individual.net> |
| In reply to | #43266 |
Malcolm McLean wrote: > On Saturday, April 19, 2014 9:20:03 PM UTC+1, Keith Thompson wrote: >> >> So what's your solution? Would you drop "const" from the >> language? 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? (C compilers typically won't warn in that >> case, but I don't think that's an argument for loosening the const >> rules.) >> > Of course if you specify that string literals shall be read-only, and > you try to write to one, you should have a warning. But an essential > problem of language design is that people who design languages tend > to take easy-to-identify programmer mistakes like that, and use them > to drive the language design. In reality, if a function modifies a > string, the caller is going to want to use the result. So as long as > he knows that string literals are not writeable, he's unlikely to > pass one, except maybe in experimental diagnostic programming. Even > if he doesn't know that string literals are not writeable, only > rarely will he want to modify one in place. So it's just a slight > issue, which will trip up a programmer occasionally, but not very > often, remembering that there will be hundreds of other logic and > other errors he makes in the same program whilst it's under > development. Maybe at one level, but it's not that simple if your are in a function that passes on a parameter. Then there's no way of telling whether the input data is writable or not. > I don't have an easy answer, but essentially const makes the wrong > distinction, which is between opaque and transparent pointers, not > between writeable and non-writeable ones. Normally it's none of > caller's business whether a subroutine is setting flags in a > structure passed to it or not. Do what? Are you happy to check the state of said structure after every call to see if it has been changed? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-22 13:14 +0100 |
| Message-ID | <9nt5v.82425$AI5.28996@fx32.am4> |
| In reply to | #43266 |
"Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message news:239efccc-e49f-4a96-9df4-d94c6afbeb51@googlegroups.com... >Normally it's > none of caller's business whether a subroutine is setting flags in a > structure passed to it or not. Assuming you mean a structure passed by reference, then I think it is! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-22 07:25 -0700 |
| Message-ID | <lnk3ahzbis.fsf@nuthaus.mib.org> |
| In reply to | #43266 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> I don't have an easy answer, but essentially const makes the wrong
> distinction, which is between opaque and transparent pointers, not
> between writeable and non-writeable ones. Normally it's none of
> caller's business whether a subroutine is setting flags in a structure
> passed to it or not.
I'm not sure what you mean by "opaque" vs. "transparent".
The caller "owns" the structure, and needs to control whether it's
modified. Should a function that prints a structure, or that sends its
value somewhere, modify it? Should the owner of a structure not have a
way to specify that its value should not be modified?
In some cases, you might have fields within a structure that can be
modified without changing the *logical* value. C++ has mechanisms (the
"mutable" keyword) for dealing with that; C does not.
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-22 08:29 -0700 |
| Message-ID | <0caf6232-32f4-4f59-a262-422e4a1aca3c@googlegroups.com> |
| In reply to | #43289 |
On Tuesday, April 22, 2014 3:25:47 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > I'm not sure what you mean by "opaque" vs. "transparent". > An opaque structure is one which has a documented name, and it's got functions which operate on it and have documented behaviour. But the members aren't documented and are subject to change. An example is the options parser on my website. You create one by passing argv and argc to a constructor function. Then you call functions with a scanf-like interface to extract the options. Then you call an error function to check for any errors, and a destructor to destroy it. In fact it caches the data. So if the user calls a program with a path, there will be one copy in argv, another held internally, and third passed back to caller. But there's no reason to know that, and if it became necessary to avoid the overhead it could be changed so that it holds onto argv directly. Whilst getting options is basically a read operation, it reports if user tries to specify an option which isn't read. So it needs to store a flag to indicate that an option has been read, and so presumably is supported. That's to make it easier to use, caller doesn't have to pass in a list of supported options then go through the list again extracting them.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-22 09:35 -0700 |
| Message-ID | <lnzjjdxqyg.fsf@nuthaus.mib.org> |
| In reply to | #43298 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Tuesday, April 22, 2014 3:25:47 PM UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> I'm not sure what you mean by "opaque" vs. "transparent".
>>
> An opaque structure is one which has a documented name, and it's got
> functions which operate on it and have documented behaviour. But the
> members aren't documented and are subject to change.
Right, I know what "opaque" means; I just didn't understand the way you
used it in this context.
Upthread, you wrote:
> I don't have an easy answer, but essentially const makes the wrong
> distinction, which is between opaque and transparent pointers, not
> between writeable and non-writeable ones. Normally it's none of
> caller's business whether a subroutine is setting flags in a
> structure passed to it or not.
I agree that "const" does not always deal well with opaque data
structures. It enforces component-wise (effectively bitwise)
read-only semantics, not necessarily logical read-only semantics.
(As I've mentioned, C++ adds "mutable" to deal with this; I'm not
sure whether adding "mutable" to C would be a good idea.)
But I find that "const" does deal well with transparent data
structures (such as the ones used to implement opaque data
structures).
The fact that "const" is not necessarily suitable for *all* cases
where you want to specify read-only semantics doesn't argue against
continuing to use it where it makes sense.
Your statement that const makes the distinction between opaque and
transparent pointers doesn't make much sense to me. Is that really
what you meant?
[...]
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-22 09:54 -0700 |
| Message-ID | <2e3998a8-131a-43a0-8553-ec2d09ec5606@googlegroups.com> |
| In reply to | #43303 |
On Tuesday, April 22, 2014 5:35:19 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > I don't have an easy answer, but essentially const makes the wrong > > distinction, which is between opaque and transparent pointers, not > > between writeable and non-writeable ones. Normally it's none of > > caller's business whether a subroutine is setting flags in a > > structure passed to it or not. > > Your statement that const makes the distinction between opaque and > transparent pointers doesn't make much sense to me. Is that really > what you meant? > I accidentally wrote nonsense. The distinction we really need to draw is between opaque and transparent pointers. const doesn't do that, it distinguishes between writeable and non-writeable ones, and even that not very well, because it doesn't struck to nested pointers embedded within the structure. const isn't appropriate for an opaque pointer, because the whole point is that caller doesn't need to know whether its being modified internally or not. With transparent pointers, it does have a purpose, but a pretty minor one, because normally if a transparent pointer is modified, then the purpose of the call is to create that modification and examine it or use it in some way. If it's not modified, then the purpose of the structure is to provide input parameters for the call. So "const" isn't especially helpful - not to say there won't be a few situations where it's very helpful, but as a general rule it's a reminder you don't need.
[toc] | [prev] | [next] | [standalone]
Page 12 of 14 — ← Prev page 1 … 10 11 [12] 13 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web