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 1 of 14 [1] 2 3 … 14 Next page →
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-18 11:45 +0100 |
| Subject | Constant strings |
| Message-ID | <On74v.12687$sa2.3320@fx33.am4> |
As far as I can gather from my experiment below, a string constant in source
code has a 'char*' type, not 'const char*'. Why is that?
Here, I can't get a compiler to complain about passing a string constant as
a char* parameter where it is clearly going to be modified. But it doesn't
like the q=p line which does the same. The q="Bart" line shows up the issue
more simply:
char* change_initial(char* s,char c){
*s=c;
return s;
}
int main (void) {
const char *p;
char* q;
change_initial("Bart",'C');
q=p;
q="Bart";
*q='C';
}
--
Bartc
[toc] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2014-04-18 07:34 -0400 |
| Message-ID | <g584v.37663$ZB7.34687@en-nntp-16.dc1.easynews.com> |
| In reply to | #43061 |
On 4/18/14, 6:45 AM, BartC wrote: > As far as I can gather from my experiment below, a string constant in > source > code has a 'char*' type, not 'const char*'. Why is that? > History! C had string literals before it had const, and when they added const it would have broken too much existing code to change the type of a string literal. A good C compiler can be set to at least give an warning if you put the address of a string literal into a char*.
[toc] | [prev] | [next] | [standalone]
| From | G G <gdotone@gmail.com> |
|---|---|
| Date | 2014-04-18 05:23 -0700 |
| Message-ID | <4c8d5c06-768f-444c-95f6-257169122709@googlegroups.com> |
| In reply to | #43061 |
On Friday, April 18, 2014 6:45:23 AM UTC-4, Bart wrote:
> As far as I can gather from my experiment below, a string constant in source
> char* change_initial(char* s,char c)
{
*s=c;
return s;
}
int main (void)
{
const char *p;
char* q;
change_initial("Bart",'C');
q=p;
q="Bart";
*q='C';
}
> --
> Bartc
i'm learning but, i have a question about the code. (that's the alert, i'll be no real help, sorry)
the program calls a function,
change_initial("Bart",'C');
change_initial("Bart",'C'); is to return a char *, but the return value is not assigned to anything.
so, well, not looking at intent, i quess?, q is just asked to point to another char * that is const.
then q is ask to point to a character string, q is not defined as a constant so shouldn't it be allowed to change and point to another char *?
another question please, in practice when a const char * is declare should it not also defined.
or it really doesn't make a difference, because when it is latter defined it can then not be changed.
using my compiler is does issue a warning.
thanks everyones for taking time out to teach a bit.
g.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-18 17:16 +0100 |
| Message-ID | <8ec4v.69386$eU3.52769@fx25.am4> |
| In reply to | #43063 |
"G G" <gdotone@gmail.com> wrote in message
news:4c8d5c06-768f-444c-95f6-257169122709@googlegroups.com...
> On Friday, April 18, 2014 6:45:23 AM UTC-4, Bart wrote:
>> As far as I can gather from my experiment below, a string constant in
>> source
>
>> char* change_initial(char* s,char c) {...}
> change_initial("Bart",'C');
>
> the program calls a function,
>
> change_initial("Bart",'C');
>
> change_initial("Bart",'C'); is to return a char *, but the return value
> is not assigned to anything.
It did do. But the I code I posted was simplified to remove any
processing/display of the result (because it was tested with a writeable
string before passing the const string, when it didn't return anyway because
it had crashed.)
The return value of char* allows it to be used like this:
printf("New string = %s\n",change_initial("bart etc",'C'));
Not using it for some calls doesn't matter (not using it ever, then perhaps
the return value could be eliminated).
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-18 11:08 -0700 |
| Message-ID | <lny4z24ijq.fsf@nuthaus.mib.org> |
| In reply to | #43083 |
"BartC" <bc@freeuk.com> writes:
[...]
> The return value of char* allows it to be used like this:
>
> printf("New string = %s\n",change_initial("bart etc",'C'));
>
> Not using it for some calls doesn't matter (not using it ever, then perhaps
> the return value could be eliminated).
And the int value returned by printf is discarded.
Ignoring the value returned by a function is quite common. Many
functions return a value that's likely to be ignored more often than not
(memset, for example).
--
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 | G G <gdotone@gmail.com> |
|---|---|
| Date | 2014-04-18 13:11 -0700 |
| Message-ID | <7a1bc703-e58b-4c5e-8bdd-06bac0c576d9@googlegroups.com> |
| In reply to | #43083 |
On Friday, April 18, 2014 12:16:59 PM UTC-4, Bart wrote:
> ...
> It did do. But the I code I posted was simplified to remove any
> processing/display of the result (because it was tested with a writeable
> string before passing the const string, when it didn't return anyway because
> it had crashed.)
> The return value of char* allows it to be used like this:
> printf("New string = %s\n",change_initial("bart etc",'C'));
> Not using it for some calls doesn't matter (not using it ever, then perhaps
> the return value could be eliminated).
> --
> Bartc
ok. thanks Bartc.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-18 10:21 -0400 |
| Message-ID | <lircdb$j0t$1@dont-email.me> |
| In reply to | #43061 |
On 04/18/2014 06:45 AM, BartC wrote:
> As far as I can gather from my experiment below, a string constant in source
> code has a 'char*' type, not 'const char*'. Why is that?
That's not quite correct. A string literal actually has the type "array
of char of length n", where n is the number of characters in the string
literal plus 1 for the terminating null character. However, in most
contexts, lvalue expressions of array type get automatically converted
into a pointer to the first element of the array, giving the impression
that string literals have the type "char*". The only two contexts where
that is not the case are sizeof("string"), which is equivalent to
sizeof(char[7]), and
char array[] = "array_initializer";
which would be a constraint violation if the string literal actually had
the type "char*".
The fact that the type is not "array of const char of length n", like
many other poorly designed features of C, was the result of the fact
that it was not all designed at the same time, combined with the need
for backwards compatibility. 'const' was not added to C until long after
string literals were, and giving string literals that type would have
broken an unacceptably large amount of existing code. I don't think
there's anyone who'd recommend copying this feature in a new language
that didn't require backwards compatibility with C.
Even C++, for which compatibility with C was a major design goal,
corrected this one error. There really was no choice about that: with
the correct overloaded function being automatically chosen based upon
the argument's type, C++ couldn't afford to allow string literals to
have the wrong type.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-18 08:45 -0700 |
| Message-ID | <lnk3am63q6.fsf@nuthaus.mib.org> |
| In reply to | #43069 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 04/18/2014 06:45 AM, BartC wrote:
>> As far as I can gather from my experiment below, a string constant in source
>> code has a 'char*' type, not 'const char*'. Why is that?
>
> That's not quite correct. A string literal actually has the type "array
> of char of length n", where n is the number of characters in the string
> literal plus 1 for the terminating null character. However, in most
> contexts, lvalue expressions of array type get automatically converted
> into a pointer to the first element of the array, giving the impression
> that string literals have the type "char*". The only two contexts where
> that is not the case are sizeof("string"), which is equivalent to
> sizeof(char[7]), and
>
> char array[] = "array_initializer";
>
> which would be a constraint violation if the string literal actually had
> the type "char*".
[...]
There's a third context: &"hello" is a pointer value of type char(*)[6]
(pointer to array 6 of char).
--
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-18 16:48 +0100 |
| Message-ID | <xQb4v.11435$Xl1.3416@fx09.am4> |
| In reply to | #43069 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:lircdb$j0t$1@dont-email.me... > On 04/18/2014 06:45 AM, BartC wrote: >> As far as I can gather from my experiment below, a string constant in >> source >> code has a 'char*' type, not 'const char*'. Why is that? > The fact that the type is not "array of const char of length n", like > many other poorly designed features of C, was the result of the fact > that it was not all designed at the same time, combined with the need > for backwards compatibility. 'const' was not added to C until long after > string literals were, and giving string literals that type would have > broken an unacceptably large amount of existing code. I don't think > there's anyone who'd recommend copying this feature in a new language > that didn't require backwards compatibility with C. OK, but I would have expected some warning at least to have been added over the last few decades, considering the number of minor matters that compilers do pounce on. I've used gcc -Wall -Wpedantic -Wextra, and not a peep out of it! (Apparently, -Wwrite-strings is needed to enable the warning; I only discovered that by running g++ which does warn.) (I'm not that concerned, just wondering how seriously compilers take the issue of const qualifiers. Because if I can write: char* q; q="ABC"; *q='X'; /* Crashes in Windows and Linux */ with nothing at all emitted by the compiler unless I go considerably out of my way, then the answer seems to be not very. It just seems a gaping loop-hole in the const-qualifier system.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-18 09:21 -0700 |
| Message-ID | <ln7g6m6223.fsf@nuthaus.mib.org> |
| In reply to | #43077 |
"BartC" <bc@freeuk.com> writes:
> "James Kuyper" <jameskuyper@verizon.net> wrote in message
> news:lircdb$j0t$1@dont-email.me...
>> On 04/18/2014 06:45 AM, BartC wrote:
>>> As far as I can gather from my experiment below, a string constant in
>>> source
>>> code has a 'char*' type, not 'const char*'. Why is that?
>
>> The fact that the type is not "array of const char of length n", like
>> many other poorly designed features of C, was the result of the fact
>> that it was not all designed at the same time, combined with the need
>> for backwards compatibility. 'const' was not added to C until long after
>> string literals were, and giving string literals that type would have
>> broken an unacceptably large amount of existing code. I don't think
>> there's anyone who'd recommend copying this feature in a new language
>> that didn't require backwards compatibility with C.
>
> OK, but I would have expected some warning at least to have been added over
> the last few decades, considering the number of minor matters that compilers
> do pounce on.
The standard does not specify warnings. It requires *diagnostics* in
many cases, but in all those cases the diagnostics are permitted to be
fatal error messages.
Individual compilers may issue whatever additional warnings they like.
The gcc documentation explains the rationale for not warning about
non-const pointers to string literals by default:
These warnings will help you find at compile time code that can try
to write into a string constant, but only if you have been very
careful about using `const' in declarations and prototypes.
Otherwise, it will just be a nuisance. This is why we did not make
`-Wall' request these warnings.
(Personally, I think programmers *should* be very careful about using
"const", but that doesn't mean a compiler should enforce it by default.)
> I've used gcc -Wall -Wpedantic -Wextra, and not a peep out of it!
> (Apparently, -Wwrite-strings is needed to enable the warning; I only
> discovered that by running g++ which does warn.)
>
> (I'm not that concerned, just wondering how seriously compilers take the
> issue of const qualifiers. Because if I can write:
>
> char* q;
>
> q="ABC";
> *q='X'; /* Crashes in Windows and Linux */
>
> with nothing at all emitted by the compiler unless I go considerably out of
> my way, then the answer seems to be not very. It just seems a gaping
> loop-hole in the const-qualifier system.)
Yes, it's a gaping loophole in the const-qualifier system.
It's unfortunate that it wasn't practical to close it when "const"
was added to the language by the 1989 ANSI C standard, but we're
stuck with it.
The strchr() and memchr() functions can also be used to violate
const-correctness, since they can quietly return a non-const pointer
into a const array. That could have been fixed by splitting both
functions into a const version and a non-const version. (C++
uses overloading to do that.)
I'm not aware of any other such loopholes, but I could be missing
something.
There's not much point in arguing that this is a flaw in the
language; I think everyone here agrees with you. We're not defending
the rule, we're merely explaining why it (unfortunately) exists.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-04-19 09:09 +1200 |
| Message-ID | <brdil0F43uvU1@mid.individual.net> |
| In reply to | #43077 |
BartC wrote:
>
> OK, but I would have expected some warning at least to have been added over
> the last few decades, considering the number of minor matters that compilers
> do pounce on.
>
> I've used gcc -Wall -Wpedantic -Wextra, and not a peep out of it!
> (Apparently, -Wwrite-strings is needed to enable the warning; I only
> discovered that by running g++ which does warn.)
>
> (I'm not that concerned, just wondering how seriously compilers take the
> issue of const qualifiers. Because if I can write:
>
> char* q;
>
> q="ABC";
> *q='X'; /* Crashes in Windows and Linux */
>
> with nothing at all emitted by the compiler unless I go considerably out of
> my way, then the answer seems to be not very. It just seems a gaping
> loop-hole in the const-qualifier system.)
Maybe you should start compiling your C with a C++ compiler? The const
rules in C++ are much closer to what you are expecting.
cat /tmp/x.c
int main()
{
char* q="ABC";
}
g++ /tmp/x.c
/tmp/x.c: In function ‘int main()’:
/tmp/x.c:3:11: warning: deprecated conversion from string constant to
‘char*’
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-18 23:53 +0100 |
| Message-ID | <X1i4v.65788$Ey6.29028@fx24.am4> |
| In reply to | #43101 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:brdil0F43uvU1@mid.individual.net... > BartC wrote: >> (I'm not that concerned, just wondering how seriously compilers take the >> issue of const qualifiers. Because if I can write: >> >> char* q; >> >> q="ABC"; >> *q='X'; /* Crashes in Windows and Linux */ >> >> with nothing at all emitted by the compiler unless I go considerably out >> of >> my way, then the answer seems to be not very. It just seems a gaping >> loop-hole in the const-qualifier system.) > > Maybe you should start compiling your C with a C++ compiler? The const > rules in C++ are much closer to what you are expecting. This particular issue isn't bothering me at the minute. I was just intrigued at the more rigorous enforcement of const types on one hand, compared with the lax approach used with string constants. It's never really come up before because I refuse to use 'const' anywhere. (And I have tried using g++ to compile my code (with a view to simplifying using libraries only having a C++ interface), but it's even more of a nightmare getting it to compile my C code, most of which is auto-generated in various ways.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-18 23:06 +0000 |
| Message-ID | <20140418155718.971@kylheku.com> |
| In reply to | #43103 |
On 2014-04-18, BartC <bc@freeuk.com> wrote:
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:brdil0F43uvU1@mid.individual.net...
>> BartC wrote:
>
>>> (I'm not that concerned, just wondering how seriously compilers take the
>>> issue of const qualifiers. Because if I can write:
>>>
>>> char* q;
>>>
>>> q="ABC";
>>> *q='X'; /* Crashes in Windows and Linux */
>>>
>>> with nothing at all emitted by the compiler unless I go considerably out
>>> of
>>> my way, then the answer seems to be not very. It just seems a gaping
>>> loop-hole in the const-qualifier system.)
>>
>> Maybe you should start compiling your C with a C++ compiler? The const
>> rules in C++ are much closer to what you are expecting.
>
> This particular issue isn't bothering me at the minute. I was just intrigued
> at the more rigorous enforcement of const types on one hand, compared with
> the lax approach used with string constants. It's never really come up
> before because I refuse to use 'const' anywhere.
Although C++ has "const char *" string literals, that was a relatively late
decision in in the history of C++.
C++ has the function overloading tools to make this nicer.
In C, a the safety benefits go out the window as soon as you use a function
like:
char *strchr(const char *str, int c);
the function returns a pointer with the const qualifier stripped.
In C++, the #include <cstring> compatibility library provides overloads:
const char *strchr(const char *str, int c);
char *strchr(char *str, int c);
A const char * argument selects the first overload; a char * argument
selects the second overload.
You can benefit from these overloads if you write in "Clean C": the hybrid
dialect which compiles as C or C++. Just put this somewhere:
#ifdef __cplusplus
#include <cstring>
#else
#include <string.h>
#endif
Suddenly your strchr calls and whatnot are more type safe, with situations
like:
char *t = strchr("abc", x);
being nicely diagnosed your C++ compiler. (Here, the const char * returning
overload is selected because of "abc", and so the initialization of t strips
qualifiers, which requires a diagnostic.)
> (And I have tried using g++ to compile my code (with a view to simplifying
> using libraries only having a C++ interface), but it's even more of a
> nightmare getting it to compile my C code, most of which is auto-generated
> in various ways.)
That wouldn't be a problem if your auto-generator spits out "Clean C".
"Clean C" isn't formalized anywhere: if you know C and C++ well (or at
least the C-like subset of C++ well), you can write in it.
The name "Clean C" was coined in _C: A Reference Manual_ by Harbison and
Steele.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-19 03:57 -0700 |
| Message-ID | <9fd76d44-6d6b-466e-8515-0b3a806854cd@googlegroups.com> |
| In reply to | #43104 |
On Saturday, April 19, 2014 12:06:38 AM UTC+1, Kaz Kylheku wrote: > On 2014-04-18, BartC <bc@freeuk.com> wrote: > > Although C++ has "const char *" string literals, that was a relatively late > decision in in the history of C++. > > In C, a the safety benefits go out the window as soon as you use a function > like: > > char *strchr(const char *str, int c); > And you very rarely want to call strchr with an explicit string literal, but you quite often want to parse a string literal passed from above. The poor rules for string literals are seldom much of a practical problem, because if in a real program a function modifies a string passed to it, the caller is going to want to examine the result. So he can't pass a string literal. const rules mean that you have to have two versions of strchr, which isn't too bad. But they also mean that anyone writing a strchr-like function to parse a string needs to write two versions. That's unacceptable.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-04-19 23:41 +1200 |
| Message-ID | <brf5o3F43uvU3@mid.individual.net> |
| In reply to | #43117 |
Malcolm McLean wrote: > On Saturday, April 19, 2014 12:06:38 AM UTC+1, Kaz Kylheku wrote: >> On 2014-04-18, BartC <bc@freeuk.com> wrote: >> >> Although C++ has "const char *" string literals, that was a relatively late >> decision in in the history of C++. >> >> In C, a the safety benefits go out the window as soon as you use a function >> like: >> >> char *strchr(const char *str, int c); >> > And you very rarely want to call strchr with an explicit string literal, but > you quite often want to parse a string literal passed from above. > The poor rules for string literals are seldom much of a practical problem, > because if in a real program a function modifies a string passed to it, the > caller is going to want to examine the result. So he can't pass a string > literal. > const rules mean that you have to have two versions of strchr, which isn't > too bad. But they also mean that anyone writing a strchr-like function to > parse a string needs to write two versions. That's unacceptable. No, they don't. They would only need two versions if one were to modify the input. If that were the case, two functions with different names would be in order. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-19 06:21 -0700 |
| Message-ID | <c7838705-6bd7-45b4-8437-83998879cb52@googlegroups.com> |
| In reply to | #43119 |
On Saturday, April 19, 2014 12:41:55 PM UTC+1, Ian Collins wrote: > Malcolm McLean wrote: > > > const rules mean that you have to have two versions of strchr, which isn't > > too bad. But they also mean that anyone writing a strchr-like function to > > parse a string needs to write two versions. That's unacceptable. > > No, they don't. > > They would only need two versions if one were to modify the input. If > that were the case, two functions with different names would be in order. > Take the following function char *getnextcsvfield(char *str) Csv files are basically list of numbers or strings separated by commas, however there are rules for quotes and escapes which make the function not entirely trivial to write. Now the vast majority of people are going to get the line, use the function to iterate over the fields, and call strtod or similar to extract the data. But just occasionally you'll get someone who wants to modify the field in place. That's legitimate. So if the function is specified const char *getnextcsvfield(const char *str) He's got to cast the constness away. Allowed, but driving a coach and horses though the system. If the functions specified char *getnexcsvfield(char *str) we can't pass it a string literal. Not that in reality anyone would want to do that anyway, except for testing. But a nuisance. So the only option is two functions, one taking a cost and one not. That's also unacceptable. 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.
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2014-04-19 10:04 -0700 |
| Message-ID | <pta5l9h73t6nlc6smstpa6n7vv0h14oueo@4ax.com> |
| In reply to | #43121 |
On Sat, 19 Apr 2014 06:21:57 -0700 (PDT), Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >On Saturday, April 19, 2014 12:41:55 PM UTC+1, Ian Collins wrote: >> Malcolm McLean wrote: >> >> > const rules mean that you have to have two versions of strchr, which isn't >> > too bad. But they also mean that anyone writing a strchr-like function to >> > parse a string needs to write two versions. That's unacceptable. >> >> No, they don't. >> >> They would only need two versions if one were to modify the input. If >> that were the case, two functions with different names would be in order. >> >Take the following function > >char *getnextcsvfield(char *str) > >Csv files are basically list of numbers or strings separated by commas, however >there are rules for quotes and escapes which make the function not entirely >trivial to write. >Now the vast majority of people are going to get the line, use the function >to iterate over the fields, and call strtod or similar to extract the data. >But just occasionally you'll get someone who wants to modify the field in >place. That's legitimate. >So if the function is specified > >const char *getnextcsvfield(const char *str) A function named get... should never modify whatever source data it is processing. A function which can modify the source data should never deceive the user with a const. -- Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2014-04-19 16:54 -0700 |
| Message-ID | <k436l9l8b8md6bm2sr456dgoquo6qh3p65@4ax.com> |
| In reply to | #43131 |
On 19 Apr 2014 20:54:03 GMT, ram@zedat.fu-berlin.de (Stefan Ram) wrote: >Barry Schwarz <schwarzb@dqel.com> writes: >>A function named get... should never modify whatever source data it is >>processing. > > »getc«, »getchar« and »gets« (»gets_s«) all seem to advances > the associated file position indicator for the stream used. But they don't alter the data extracted from the stream. -- Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Seungbeom Kim <musiphil@bawi.org> |
|---|---|
| Date | 2014-04-19 17:54 -0700 |
| Message-ID | <liv5s2$sn7$1@usenet.stanford.edu> |
| In reply to | #43131 |
On 2014-04-19 10:04, Barry Schwarz wrote: > On Sat, 19 Apr 2014 06:21:57 -0700 (PDT), Malcolm McLean > <malcolm.mclean5@btinternet.com> wrote: >> But just occasionally you'll get someone who wants to modify the field in >> place. That's legitimate. >> So if the function is specified >> >> const char *getnextcsvfield(const char *str) > > A function named get... should never modify whatever source data it is > processing. And we're not talking about such a function that does; it's just a matter of allowing the *caller* to modify the source data through the return value. -- Seungbeom Kim
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-19 13:20 -0700 |
| Message-ID | <lneh0t3wcs.fsf@nuthaus.mib.org> |
| In reply to | #43121 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, April 19, 2014 12:41:55 PM UTC+1, Ian Collins wrote:
>> Malcolm McLean wrote:
>>
>> > const rules mean that you have to have two versions of strchr, which isn't
>> > too bad. But they also mean that anyone writing a strchr-like function to
>> > parse a string needs to write two versions. That's unacceptable.
>>
>> No, they don't.
>>
>> They would only need two versions if one were to modify the input.
Or if one were to permit the caller to modify the input.
>> If that were the case, two functions with different names would be in
>> order.
>>
> Take the following function
>
> char *getnextcsvfield(char *str)
>
> Csv files are basically list of numbers or strings separated by commas, however
> there are rules for quotes and escapes which make the function not entirely
> trivial to write.
> Now the vast majority of people are going to get the line, use the function
> to iterate over the fields, and call strtod or similar to extract the data.
> But just occasionally you'll get someone who wants to modify the field in
> place. That's legitimate.
> So if the function is specified
>
> const char *getnextcsvfield(const char *str)
>
> He's got to cast the constness away. Allowed, but driving a coach and horses
> though the system.
> If the functions specified
> char *getnexcsvfield(char *str)
>
> we can't pass it a string literal. Not that in reality anyone would want to do
> that anyway, except for testing. But a nuisance.
Well, in C you *can* pass it a string literal, because string literals
aren't const, but yes, if string literals were const (which I personally
would greatly prefer), then you wouldn't be able to pass a string
literal.
If the intent of the function is to allow the string to be modified, why
*should* you be able to pass a string literal to it?
> So the only option is two functions, one taking a cost and one
> not. That's also unacceptable.
One function that lets you modify the string you pass to it, and another
that doesn't. Two different functions *with significantly different
semantics*. What's unacceptable about that?
And how often are you going to want to modify data in place in a string
containing CSV data? You can only do that if the replacement data is
exactly the same length as the original data; you can't change
"...,9,..." to "...,10,..." without shifting the rest of the string and
perhaps allocating extra memory. I'd say it's perfectly acceptable in
this case to provide *only* a function that doesn't let you modify
anything. (And if you really need to modify the string, you can either
write that second function or *carefully* use casts to override the
"const".)
> 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?
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.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 1 of 14 [1] 2 3 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web