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 4 of 14 — ← Prev page 1 2 3 [4] 5 6 … 14 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-23 19:19 -0700 |
| Message-ID | <ln38h3v58v.fsf@nuthaus.mib.org> |
| In reply to | #43477 |
Stephen Sprunk <stephen@sprunk.org> writes:
> On 23-Apr-14 13:10, Keith Thompson wrote:
>> FILE objects are (normally) created only by calling library
>> functions, and are manipulated only via FILE* pointers.
>> An implementation could make FILE itself an integer type, an
>> index into a table, which would allow *all* FILE* arguments to be
>> defined as "const FILE *f". Another could keep additional tracking
>> information in the FILE object itself, so ftell() and friends might
>> actually update the FILE object.
>
> Why might ftell() need to "update" the FILE object? In theory, all it
> needs to do is extract the current file offset and return it.
Just for the heck of it?
I can imagine that an implementation might want to keep track of when
the most recent operation on the file was performed; ftell() might
update a timestamp.
I don't suggest that that's particularly plausible. What is plausible
is that the authors of the standard didn't think it was worth the time
and effort to determine exactly which functions might or might not need
to modify the FILE object (at the risk of imposing unnecessary
restrictions on implementations).
--
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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2014-04-23 23:53 -0500 |
| Message-ID | <i63hl9hjeuuh2kn9jeq66e7nh20q856hnc@4ax.com> |
| In reply to | #43477 |
On Wed, 23 Apr 2014 19:19:34 -0500, Stephen Sprunk <stephen@sprunk.org> wrote: >On 23-Apr-14 13:10, Keith Thompson wrote: >> FILE objects are (normally) created only by calling library >> functions, and are manipulated only via FILE* pointers. >> An implementation could make FILE itself an integer type, an >> index into a table, which would allow *all* FILE* arguments to be >> defined as "const FILE *f". Another could keep additional tracking >> information in the FILE object itself, so ftell() and friends might >> actually update the FILE object. > >Why might ftell() need to "update" the FILE object? In theory, all it >needs to do is extract the current file offset and return it. At least hypothetically, ftell might be returning a handle to an allocated structure on systems where the notion of position in a text file is more complex than the stream-of-bytes model*. In that case it might be necessary to track the allocated structures so they can be discarded when the file is closed. *I was thinking specifically of a Q/BSAM (sequential) zOS file opened as a text file. A position would be a combination of the output from an NOTE macro (which effective will return the relative track and record number), plus a position within that record. That is neither a simple byte offset, nor small enough to fit into a long. In practice IBM limits the usefulness of ftell to files with considerable restrictions on size** (or at least to the beginning of large files), and requires using ftello if you want to work with large files (and then the off_t is large enough to hold the complete position), so this isn't a real problem in that situation. **Which, depending on how the file is defined, and the release of the OS/runtime, might be as little as a few megabytes (an unblocked file of 80 byte records, for example, would cause ftell to fail if there's more than about 10MB of data, at least on older versions).
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-24 11:55 +0000 |
| Message-ID | <ljau3k$t9e$1@speranza.aioe.org> |
| In reply to | #43485 |
Robert Wessel <robertwessel2@yahoo.com> wrote: (snip, someone wrote) >>Why might ftell() need to "update" the FILE object? In theory, all it >>needs to do is extract the current file offset and return it. > At least hypothetically, ftell might be returning a handle to an > allocated structure on systems where the notion of position in a text > file is more complex than the stream-of-bytes model*. In that case it > might be necessary to track the allocated structures so they can be > discarded when the file is closed. > *I was thinking specifically of a Q/BSAM (sequential) zOS file opened > as a text file. A position would be a combination of the output from > an NOTE macro (which effective will return the relative track and > record number), plus a position within that record. That is neither a > simple byte offset, nor small enough to fit into a long. In practice > IBM limits the usefulness of ftell to files with considerable > restrictions on size** (or at least to the beginning of large files), > and requires using ftello if you want to work with large files (and > then the off_t is large enough to hold the complete position), so this > isn't a real problem in that situation. As well as I remember, there are four combinations to consider: Opened as either text file or binary file, and either fixed (F or FB) or variable (V, VB) length records. The file system keeps track of the block, and the library the offset into the block. I believe for FB opened in binary mode, it computes the byte offset (BLKSIZE*relative block number + offset), and for the other combinations, 32768*relative block number+offset, for some version of a C library. If you need the actual byte offset for a VB file, you have to read from the beginning while counting the size of each block. (The OS actually keeps track of track numbers, and blocks within a track. An actual disk address is an eight byte value of the form MBBCCHHR where CC is the cylinder number, HH head within the cylinder, and R record within the track.) > **Which, depending on how the file is defined, and the release of the > OS/runtime, might be as little as a few megabytes (an unblocked file > of 80 byte records, for example, would cause ftell to fail if there's > more than about 10MB of data, at least on older versions). The library routines could keep a table of offsets vs. block number. and ftell() might update that table. There is also the CMS emulation of OS files, which might work a little differently. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2014-04-24 11:27 -0500 |
| Message-ID | <ljbe1n$kog$1@dont-email.me> |
| In reply to | #43485 |
On 23-Apr-14 23:53, Robert Wessel wrote: > On Wed, 23 Apr 2014 19:19:34 -0500, Stephen Sprunk > <stephen@sprunk.org> wrote: >> On 23-Apr-14 13:10, Keith Thompson wrote: >>> FILE objects are (normally) created only by calling library >>> functions, and are manipulated only via FILE* pointers. An >>> implementation could make FILE itself an integer type, an index >>> into a table, which would allow *all* FILE* arguments to be >>> defined as "const FILE *f". Another could keep additional >>> tracking information in the FILE object itself, so ftell() and >>> friends might actually update the FILE object. >> >> Why might ftell() need to "update" the FILE object? In theory, all >> it needs to do is extract the current file offset and return it. > > At least hypothetically, ftell might be returning a handle to an > allocated structure on systems where the notion of position in a > text file is more complex than the stream-of-bytes model*. In that > case it might be necessary to track the allocated structures so they > can be discarded when the file is closed. I thought of that. It seems easier to keep said structure within the FILE object itself since there will can only be one valid one at a given time; the reading functions would update it to keep it current, so ftell() still just has to extract its value (perhaps after some computation). Allocating a new structure every time someone calls ftell() seems wasteful and inefficient; it would monotonically consume more and more memory until they eventually call fclose(). 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-24 20:03 +0000 |
| Message-ID | <ljbqmq$9je$1@speranza.aioe.org> |
| In reply to | #43516 |
Stephen Sprunk <stephen@sprunk.org> wrote: > On 23-Apr-14 23:53, Robert Wessel wrote: (snip) >> At least hypothetically, ftell might be returning a handle to an >> allocated structure on systems where the notion of position in a >> text file is more complex than the stream-of-bytes model*. In that >> case it might be necessary to track the allocated structures so they >> can be discarded when the file is closed. > I thought of that. It seems easier to keep said structure within the > FILE object itself since there will can only be one valid one at a given > time; the reading functions would update it to keep it current, so > ftell() still just has to extract its value (perhaps after some > computation). If the structure was a list of block offsets, it would slowly increase as the file got longer. There are at least a few different ways of storing such a table, some of which might modify the FILE struct. > Allocating a new structure every time someone calls ftell() seems > wasteful and inefficient; it would monotonically consume more and more > memory until they eventually call fclose(). Not every time, but some of the times. If you read from the beginning, counting bytes, for each ftell(), you might at least want to cache the previous value. That would be one write to the FILE struct, but it wouldn't get bigger. Or cache a small number of offsets. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2014-04-24 17:16 -0500 |
| Message-ID | <ljc2gc$c1j$1@dont-email.me> |
| In reply to | #43524 |
On 24-Apr-14 15:03, glen herrmannsfeldt wrote: > Stephen Sprunk <stephen@sprunk.org> wrote: >> On 23-Apr-14 23:53, Robert Wessel wrote: >>> At least hypothetically, ftell might be returning a handle to an >>> allocated structure on systems where the notion of position in a >>> text file is more complex than the stream-of-bytes model*. In that >>> case it might be necessary to track the allocated structures so they >>> can be discarded when the file is closed. >> >> I thought of that. It seems easier to keep said structure within the >> FILE object itself since there will can only be one valid one at a given >> time; the reading functions would update it to keep it current, so >> ftell() still just has to extract its value (perhaps after some >> computation). > > If the structure was a list of block offsets, it would slowly increase > as the file got longer. There are at least a few different ways of > storing such a table, some of which might modify the FILE struct. Wouldn't that only happen during reads or writes to the file, though, which obviously require a non-const FILE? ftell() would just read the tables, which could be done with a const FILE. >> Allocating a new structure every time someone calls ftell() seems >> wasteful and inefficient; it would monotonically consume more and more >> memory until they eventually call fclose(). > > Not every time, but some of the times. > > If you read from the beginning, counting bytes, for each ftell(), > you might at least want to cache the previous value. That would > be one write to the FILE struct, but it wouldn't get bigger. > Or cache a small number of offsets. Caching is one justification for casting away constness. Since we're talking about implementation internals, one could take advantage of knowledge that doing so is "safe" on that implementation. (AIUI, C++ allows this for const objects via mutable members.) S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-23 17:39 +0100 |
| Message-ID | <02S5v.55118$iZ5.28539@fx17.am4> |
| In reply to | #43417 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message
news:lj8cbq$daj$1@dont-email.me...
> On 04/23/2014 06:56 AM, BartC wrote:
> ....
>> However, when I try and use such a guard to suggest that a file-handling
>> function will not modify the file I'm passing it, I run into problems:
>>
>> void dont_update_the_file(const FILE* f) {
>> fseek(f,0,SEEK_SET);
>> }
>>
>> The fseek() call generates a warning. So it needs every single function,
>> that might take such a parameter, to cooperate with the scheme.
>
> It's supposed to generate a warning. That's precisely what the 'const'
> is intended to achieve - preventing you from doing anything that would
> modify *f. Since fseek() needs to update some of the members of the FILE
> that it is passed, (specifically, the ones that keep track of the
> current position in the file), the fact that a diagnostic message is
> required for that call is how the 'const' achieves precisely that effect.
>
> Your mistake lies in assuming that the 'const' protects the file managed
> by the FILE object. It only protects the FILE object itself.
I don't care about modifying the FILE object. Only about the file.
If I did want a scheme to mark functions that write the to the actual files
they are passed, and those that don't, then using const might not be viable.
Since there are at least two areas that may be written to, the FILE
descriptor, and the file data itself.
The same thing can occur with other data accessed indirectly, even my image
descriptor may have attributes I want some functions to change, but I don't
want them to touch the actual pixel data.
The const attribute is too crude a feature to use reliably for this stuff. I
acknowledge it can be of use in certain cases (probably lower level and with
simpler data than my examples), but not in general.
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!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-23 13:06 -0400 |
| Message-ID | <5357F31E.1090105@verizon.net> |
| In reply to | #43437 |
On 04/23/2014 12:39 PM, BartC wrote: > > > "James Kuyper" <jameskuyper@verizon.net> wrote in message > news:lj8cbq$daj$1@dont-email.me... ... >> 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. Too bad. 'const' only protects the former. That doesn't mean it's useless, only that it can't be used to do what you want to do. ... > 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 a feature whose entire purpose is to mandate the generation of diagnostic messages if certain kinds of errors are committed. Of course it can be removed from a working program without causing any changes - the program must have been compiled at least once without generating any of those diagnostics, or it wouldn't be considered "working", so you can be sure it doesn't contain any errors of those kinds. If you are certain that you'll never write code containing the kinds of errors that 'const' can help you detect, then you'll never need it. If you claim that this exception applies to you, I'll assume you're wrong - you don't even understand what 'const' does; you couldn't possibly be relied upon to correctly evaluate whether or not you'll make a mistake of the kind it could have helped you avoid. It's also clearly not indispensable - C did without it for many years. The errors it helps you discover can also be discovered by other, less convenient methods. It's helpful, very much so, but no one has ever claimed it's indispensable. You could re-write any C program to do the same thing it currently does without making any use of functions (other than main() and the C standard library), the increment or decrement operators, compound assignment operators, the conditional operator, the comma operator, switch statements, iteration statements, arithmetic types other than 'int', structures or unions. None of those are indispensable - that doesn't mean they're not useful.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-23 10:25 -0700 |
| Message-ID | <b7c98cc8-5358-4053-b4b8-e9a09cc5535a@googlegroups.com> |
| In reply to | #43441 |
On Wednesday, April 23, 2014 6:06:38 PM UTC+1, James Kuyper wrote: > It's helpful, very much so, but no one has ever claimed it's indispensable. > It's not very helpful. It protects largely against errors you're unlikely to make in a real program. You're unlikely to pass a read-only variable to a function which modifies it, because if the function modifies it, normally caller will want to use that modification in some way, and people have a bit of sense. That's not to say there aren't a few circumstances where it will catch bugs early.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-23 11:30 -0700 |
| Message-ID | <lnoazrvqza.fsf@nuthaus.mib.org> |
| In reply to | #43444 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, April 23, 2014 6:06:38 PM UTC+1, James Kuyper wrote:
>> It's helpful, very much so, but no one has ever claimed it's indispensable.
>>
> It's not very helpful. It protects largely against errors you're
> unlikely to make in a real program. You're unlikely to pass a
> read-only variable to a function which modifies it, because if the
> function modifies it, normally caller will want to use that
> modification in some way, and people have a bit of sense. That's not
> to say there aren't a few circumstances where it will catch bugs
> early.
You're not likely to take the square root of a string either, but I'm
glad the compiler will diagnose any attempt to do so.
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-23 20:55 +0000 |
| Message-ID | <lj99cb$90s$2@speranza.aioe.org> |
| In reply to | #43450 |
Keith Thompson <kst-u@mib.org> wrote: (snip) > You're not likely to take the square root of a string either, > but I'm glad the compiler will diagnose any attempt to do so. Maybe not in C, but if it has the right value PL/I will do it. (and in double precision, too!) -- glen
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-23 21:53 -0700 |
| Message-ID | <40868d50-619b-4299-90ca-b8f2bd027191@googlegroups.com> |
| In reply to | #43450 |
On Wednesday, April 23, 2014 7:30:01 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > You're not likely to take the square root of a string either, but I'm > glad the compiler will diagnose any attempt to do so. > You are quite likely to get the order of arguments the wrong way round for some non-core function. But a lot of modern languages won't diagnose the attempt to take the square root of a string. They have dynamic typing. Sometimes strings which can be converted to numbers will be processed as numbers, sometimes they will throw a runtime error. I find dynamic typing harder to use, because few real functions are genuinely generic - you have to rely on often sloppy documentation to know what you can pass and expect back. But a lot of people think otherwise.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-04-24 17:05 +1200 |
| Message-ID | <brrkcmF43v1U11@mid.individual.net> |
| In reply to | #43486 |
Malcolm McLean wrote: > On Wednesday, April 23, 2014 7:30:01 PM UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> You're not likely to take the square root of a string either, but I'm >> glad the compiler will diagnose any attempt to do so. >> > You are quite likely to get the order of arguments the wrong way round for > some non-core function. Which is one case where const can save you from strange errors. Consider memcpy for example. I think you have just contradicted your previous argument... -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-24 00:59 -0700 |
| Message-ID | <dc9e7f93-69f6-4840-8e94-c95646d99b54@googlegroups.com> |
| In reply to | #43488 |
On Thursday, April 24, 2014 6:05:26 AM UTC+1, Ian Collins wrote: > Malcolm McLean wrote: > > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > You are quite likely to get the order of arguments the wrong way round for > > some non-core function. > > Which is one case where const can save you from strange errors. > Consider memcpy for example. > > I think you have just contradicted your previous argument... > A copy function which takes two matching pointers is a case where const is helpful, I agree. But still not all that helpful. void copy_employee(Employee *dest, const Employee *src) ... copy_employee(&topay, &paid); is that call right or wrong?
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-23 18:39 +0100 |
| Message-ID | <9WS5v.52882$hB4.38502@fx20.am4> |
| In reply to | #43441 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:5357F31E.1090105@verizon.net... > On 04/23/2014 12:39 PM, BartC wrote: >> 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! > If you are certain that you'll never write code containing the kinds of > errors that 'const' can help you detect, then you'll never need it. If > you claim that this exception applies to you, I'll assume you're wrong - > you don't even understand what 'const' does; you couldn't possibly be > relied upon to correctly evaluate whether or not you'll make a mistake > of the kind it could have helped you avoid. I think I have a pretty good idea what it does, just questioning its usefulness. I have thought a few times about re-implementing the same feature elsewhere, but have never been convinced it's worth the effort. > You could re-write any C program to do the > same thing it currently does without making any use of functions (other > than main() and the C standard library), the increment or decrement > operators, compound assignment operators, the conditional operator, the > comma operator, switch statements, iteration statements, arithmetic > types other than 'int', structures or unions. None of those are > indispensable - that doesn't mean they're not useful. const is different from any of those because: (1) Removing it almost as easy as using global replace in a text editor (you just have to watch out for embedded consts). All those others involve rewriting code. (2) The resulting code will generally be less cluttered and easier to read. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-23 14:53 -0400 |
| Message-ID | <53580C34.2030709@verizon.net> |
| In reply to | #43445 |
On 04/23/2014 01:39 PM, BartC wrote: > "James Kuyper" <jameskuyper@verizon.net> wrote in message > news:5357F31E.1090105@verizon.net... >> On 04/23/2014 12:39 PM, BartC wrote: > >>> 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! > >> If you are certain that you'll never write code containing the kinds of >> errors that 'const' can help you detect, then you'll never need it. If >> you claim that this exception applies to you, I'll assume you're wrong - >> you don't even understand what 'const' does; you couldn't possibly be >> relied upon to correctly evaluate whether or not you'll make a mistake >> of the kind it could have helped you avoid. > > I think I have a pretty good idea what it does, You have proven time and again, by your comments about it, that you have some very radical misconceptions about what it does. It's not at all clear what those misconceptions are, only that they've led to reach some incorrect conclusions. I'm not referring to your judgements of the value of 'const' - those are inherently subjective. I'm talking about your (incorrect) statements of fact about the use of 'const'. The most prominent of those were your suggestion that there was some reason why use of 'const' would require insertion of numerous (const T*) casts. Those misconceptions have been pointed out to you, but you've never responded to those messages in any way that suggests that now understand what you used to misunderstand. Nor have your responses given us any reason to believe that your apparent misunderstanding was due to us incorrectly interpreting what you said, nor to you expressing yourself poorly. >> You could re-write any C program to do the >> same thing it currently does without making any use of functions (other >> than main() and the C standard library), the increment or decrement >> operators, compound assignment operators, the conditional operator, the >> comma operator, switch statements, iteration statements, arithmetic >> types other than 'int', structures or unions. None of those are >> indispensable - that doesn't mean they're not useful. > > const is different from any of those because: > > (1) Removing it almost as easy as using global replace in a text editor (you > just have to watch out for embedded consts). All those others involve > rewriting code. That's completely irrelevant to the value provided by 'const'. It improves error checking - as such, the fact that it can be removed from error-free code without changing the required behavior is no indication that it is useless That 'const' is easy to remove, and has no effect on the required behavior of correct code, is also true of 'restrict' and 'register'. You could also, in many cases, remove 'inline' and add 'static' (if it wasn't already there) without affecting the required behavior of a program. That doesn't mean that any of those features are useless. It's arguably the case that 'register' is useless in modern compilers; the last time I bothered using it was about 30 years ago. However, I gather that when C first came out it was useful for improving the results produced by the early compilers. The value provided by 'restrict' is at least as subtle as that of 'const', and I don't expect you to accept that value any more easily than you accept the value of 'const'. It enables optimizations by declaring undefined behavior that would otherwise be defined - I'd prefer that it make the corresponding code a constraint violation, but that wouldn't be feasible in the general case. > (2) The resulting code will generally be less cluttered and easier to read. If you feel that way, then I recommend using such a filter when reading C code; but not when writing or compiling it.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-23 21:09 +0100 |
| Message-ID | <W5V5v.121811$Ey6.118144@fx24.am4> |
| In reply to | #43453 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:53580C34.2030709@verizon.net... > On 04/23/2014 01:39 PM, BartC wrote: >> I think I have a pretty good idea what it does, > I'm talking about your > (incorrect) statements of fact about the use of 'const'. The most > prominent of those were your suggestion that there was some reason why > use of 'const' would require insertion of numerous (const T*) casts. What was wrong with that idea? It's one way of having 'const' make itself useful, by effectively providing a write-protect guard on data being passed to functions that might be writing to the data. int mydata[...]; SomeFunction(mydata); This could presumably write all over my data. But: SomeFunction((const int*)mydata); This will give a warning, if SomeFunction doesn't have a matching const (we don't even need to know this). Actually I wasn't advocating doing this, just complaining that you'd have to go to these lengths in order for const to be useful. Nevertheless adding this cast /will/ have that effect. Now you're saying I am wrong about that? > That 'const' is easy to remove, and has no effect on the required > behavior of correct code, is also true of 'restrict' and 'register'. You > could also, in many cases, remove 'inline' and add 'static' (if it > wasn't already there) without affecting the required behavior of a > program. That doesn't mean that any of those features are useless. I think static does make a significant difference to how the code will work. Those other features used to be just compiler hints; I thought const was in a different class to those, operating on types so that 'const T' was distinct from 'T'. > The value provided by > 'restrict' is at least as subtle as that of 'const', and I don't expect > you to accept that value any more easily than you accept the value of > 'const'. 'restrict' I don't understand and don't want to. But mercifully you don't see it in code very often, unlike const that some people like to put in at every opportunity, something I've never had a need for. (And C compilers don't seem to discourage over-use; the following works with several of them: const const const const const const const const const const int const const const const const const const const const const b; somewhere in there you might see the actual type.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-23 19:23 -0400 |
| Message-ID | <53584B6E.6030908@verizon.net> |
| In reply to | #43458 |
On 04/23/2014 04:09 PM, BartC wrote: > "James Kuyper" <jameskuyper@verizon.net> wrote in message > news:53580C34.2030709@verizon.net... ... >> I'm talking about your >> (incorrect) statements of fact about the use of 'const'. The most >> prominent of those were your suggestion that there was some reason why >> use of 'const' would require insertion of numerous (const T*) casts. > > What was wrong with that idea? The idea that it's a common necessity - in particular, the idea that you expressed, that it would have to be done almost everywhere. In almost all contexts in programs that make proper use of 'const', there is little or no need for such casts. Either the object itself will be declared const, so that &identifier or array_name automatically has the type "const T*", or conversion from "T*" to "const T*" occurs automatically a side-effect of assignment, or of other constructs that follow the same rules as assignment (such as passing an argument to a function, or returning a value from a function). Assignment allows the left operand to have more qualifiers than the right operand. >> That 'const' is easy to remove, and has no effect on the required >> behavior of correct code, is also true of 'restrict' and 'register'. You >> could also, in many cases, remove 'inline' and add 'static' (if it >> wasn't already there) without affecting the required behavior of a >> program. That doesn't mean that any of those features are useless. > > I think static does make a significant difference to how the code will work. That's often not the case for functions declared 'inline'; it's only such cases that I was referring to. > Those other features used to be just compiler hints; I thought const was in > a different class to those, operating on types so that 'const T' was > distinct from 'T'. 'const' shares a key feature with the compiler hints: it doesn't change the required behavior to remove 'const' from code that is correct. Adding 'const' can, in some cases, change correct code into incorrect code; and that is a feature it also shares with the compiler hints, (such cases are admittedly more common with 'const' than they are with 'register', 'restrict' or 'inline'). In some cases 'const' allows certain optimizations (such as use of read-only memory), but it doesn't mandate them.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2014-04-25 10:52 -0500 |
| Message-ID | <lje0bm$tva$1@dont-email.me> |
| In reply to | #43458 |
On 23-Apr-14 15:09, BartC wrote: > "James Kuyper" <jameskuyper@verizon.net> wrote in message > news:53580C34.2030709@verizon.net... >> On 04/23/2014 01:39 PM, BartC wrote: >>> I think I have a pretty good idea what it does, >> >> I'm talking about your (incorrect) statements of fact about the use >> of 'const'. The most prominent of those were your suggestion that >> there was some reason why use of 'const' would require insertion of >> numerous (const T*) casts. > > What was wrong with that idea? It's one way of having 'const' make > itself useful, by effectively providing a write-protect guard on data > being passed to functions that might be writing to the data. > > int mydata[...]; > > SomeFunction(mydata); > > This could presumably write all over my data. But: > > SomeFunction((const int*)mydata); > > This will give a warning, if SomeFunction doesn't have a matching > const (we don't even need to know this). Actually I wasn't advocating > doing this, just complaining that you'd have to go to these lengths > in order for const to be useful. No, you just have to look at the prototype for SomeFunction(), which you have to do anyway to know how to properly call it, and see whether its argument is const or not. If so, you know it won't modify your data; if not, it might. There is no need for a cast either way. > Nevertheless adding this cast /will/ have that effect. Now you're > saying I am wrong about that? No, but that cast is pointless and nobody (sane) actually does that. > Those other features used to be just compiler hints; I thought const > was in a different class to those, operating on types so that 'const > T' was distinct from 'T'. It is, but if you have a program that works correctly with const, then it would continue to work correctly without const--just like register. The point is that most programs are _not_ correct, at least at first, and const helps you find where the problems are--at compile time, rather than months later when you're trying to debug a program over the phone with a customer. 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-23 19:36 -0500 |
| Message-ID | <lj9m9q$hjh$1@dont-email.me> |
| In reply to | #43445 |
On 23-Apr-14 12:39, BartC wrote: > "James Kuyper" <jameskuyper@verizon.net> wrote in message > news:5357F31E.1090105@verizon.net... >> On 04/23/2014 12:39 PM, BartC wrote: >>> 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! >> >> If you are certain that you'll never write code containing the >> kinds of errors that 'const' can help you detect, then you'll never >> need it. If you claim that this exception applies to you, I'll >> assume you're wrong - you don't even understand what 'const' does; >> you couldn't possibly be relied upon to correctly evaluate whether >> or not you'll make a mistake of the kind it could have helped you >> avoid. > > I think I have a pretty good idea what it does, Your responses in this thread seem to indicate otherwise. At minimum, you don't have a "pretty good idea" of how to use it. >> You could re-write any C program to do the same thing it currently >> does without making any use of functions (other than main() and the >> C standard library), the increment or decrement operators, compound >> assignment operators, the conditional operator, the comma operator, >> switch statements, iteration statements, arithmetic types other >> than 'int', structures or unions. None of those are indispensable - >> that doesn't mean they're not useful. > > const is different from any of those because: > ... > (2) The resulting code will generally be less cluttered and easier to > read. ... but more likely to contain hidden bugs. Your main/only interest in C seems to be as an intermediate language generated by a compiler for some other language. In that case, once you have established your code is correct, const probably adds nothing. For C's primary audience, i.e. humans, const is quite helpful. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
Page 4 of 14 — ← Prev page 1 2 3 [4] 5 6 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web