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 14 of 14 — ← Prev page 1 … 12 13 [14]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-24 00:52 +0100 |
| Message-ID | <AnY5v.95960$Kq1.31282@fx07.am4> |
| In reply to | #43473 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:brqulgF43v1U9@mid.individual.net... > Ben Bacarisse wrote: >> Interesting. What does it (the C compiler) warn about? A compiler can >> warn about anything it likes, of course, I'm just curious to know what >> it's pointing out. > > The same thing g++ considers to be an error: > > "Warning: parameter type involves pointer to array of unknown size." With C, I think its concern is that it doesn't have enough information to increment such a pointer, for example. But so long as I don't actually do that, why would g++ take it more seriously? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-24 01:04 +0000 |
| Message-ID | <20140423180039.111@kylheku.com> |
| In reply to | #43476 |
On 2014-04-23, BartC <bc@freeuk.com> wrote:
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:brqulgF43v1U9@mid.individual.net...
>> Ben Bacarisse wrote:
>
>>> Interesting. What does it (the C compiler) warn about? A compiler can
>>> warn about anything it likes, of course, I'm just curious to know what
>>> it's pointing out.
>>
>> The same thing g++ considers to be an error:
>>
>> "Warning: parameter type involves pointer to array of unknown size."
>
> With C, I think its concern is that it doesn't have enough information to
> increment such a pointer, for example.
C allows pointers to incomplete types, and these are front-and-centre in a very
commonly occuring programming technique:
struct opaque;
struct opaque *opaque_thing_construct(int arg, char *other_arg);
void opaque_thing_destroy(struct opaque *);
An array of unknown size is an incomplete type. Such an object can be
declared.
struct driver device_table[]; /* in header file: incomplete array */
/* in driver.c */
struct driver device_table[] = { /* entries ... */ };
C++ is highly compatible with this.
> But so long as I don't actually do that, why would g++ take it more
> seriously?
It's just a warning, just like "suggest parentheses around assignment
used as a condition".
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-04-24 13:16 +1200 |
| Message-ID | <brr6ujF43v1U10@mid.individual.net> |
| In reply to | #43479 |
Kaz Kylheku wrote:
> On 2014-04-23, BartC <bc@freeuk.com> wrote:
>> "Ian Collins" <ian-news@hotmail.com> wrote in message
>> news:brqulgF43v1U9@mid.individual.net...
>>> Ben Bacarisse wrote:
>>
>>>> Interesting. What does it (the C compiler) warn about? A compiler can
>>>> warn about anything it likes, of course, I'm just curious to know what
>>>> it's pointing out.
>>>
>>> The same thing g++ considers to be an error:
>>>
>>> "Warning: parameter type involves pointer to array of unknown size."
>>
>> With C, I think its concern is that it doesn't have enough information to
>> increment such a pointer, for example.
>
> C allows pointers to incomplete types, and these are front-and-centre in a very
> commonly occuring programming technique:
>
> struct opaque;
>
> struct opaque *opaque_thing_construct(int arg, char *other_arg);
> void opaque_thing_destroy(struct opaque *);
>
> An array of unknown size is an incomplete type. Such an object can be
> declared.
>
> struct driver device_table[]; /* in header file: incomplete array */
>
>
> /* in driver.c */
>
> struct driver device_table[] = { /* entries ... */ };
>
> C++ is highly compatible with this.
>
>> But so long as I don't actually do that, why would g++ take it more
>> seriously?
>
> It's just a warning, just like "suggest parentheses around assignment
> used as a condition".
That's his problem here: with g++ its an error, not a warning as expected.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-23 19:14 -0700 |
| Message-ID | <ln7g6fv5gi.fsf@nuthaus.mib.org> |
| In reply to | #43476 |
"BartC" <bc@freeuk.com> writes:
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:brqulgF43v1U9@mid.individual.net...
>> Ben Bacarisse wrote:
>
>>> Interesting. What does it (the C compiler) warn about? A compiler can
>>> warn about anything it likes, of course, I'm just curious to know what
>>> it's pointing out.
>>
>> The same thing g++ considers to be an error:
>>
>> "Warning: parameter type involves pointer to array of unknown size."
>
> With C, I think its concern is that it doesn't have enough information to
> increment such a pointer, for example.
>
> But so long as I don't actually do that, why would g++ take it more
> seriously?
Because it's explicitly illegal in C++.
Quoting the 2011 C++ standard, section 8.3.5 [dcl.fct] paragraph 8:
If the type of a parameter includes a type of the form "pointer to
array of unknown bound of T", [...] the program is ill-formed.
C doesn't have that rule.
This is a case where valid C code is not valid C++ code -- and not one
that I've seen in any lists of such features.
If you're curious about the rationale for this restriction, I suggest
asking in one of the C++ newsgroups.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-24 03:41 +0100 |
| Message-ID | <0.d7d81f4189fc7b6eb804.20140424034141BST.87wqef78ka.fsf@bsb.me.uk> |
| In reply to | #43473 |
Ian Collins <ian-news@hotmail.com> writes:
> Ben Bacarisse wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>
>>> Ben Bacarisse wrote:
>>>> Ian Collins <ian-news@hotmail.com> writes:
>>>>
>>>>> BartC wrote:
<snip>
>>>>>> static void testfn(i32 (*a)[]) {
>>>>>
>>>>> I'm surprised gcc doesn't issue a warning about the null dimension.
>>>>
>>>> (int (*)[]) and (int (*)[5]) are compatible types so there is nothing
>>>> reasonable to warn about.
>>>
>>> As I said, it was the acceptance of "int (*)[]" as a function
>>> parameter that surprised me.
>>
>> Ah, sorry, so not the compatibility but the type itself, at least in
>> that context. What did you think gcc should/might complain about? It
>> acts, I think, just like a pointer to any other incomplete type, so I'd
>> be surprised if there were a complaint.
>>
>>> I just tried compiling the code and sure
>>> enough, gcc silently accepts it while g++ considers it an error. The
>>> Sun compilers issue a warning for both C and C++.
>>
>> Interesting. What does it (the C compiler) warn about? A compiler can
>> warn about anything it likes, of course, I'm just curious to know what
>> it's pointing out.
>
> The same thing g++ considers to be an error:
>
> "Warning: parameter type involves pointer to array of unknown size."
Thanks. I wonder why the authors felt the need to point that out.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-23 16:04 -0700 |
| Message-ID | <lnbnvrve96.fsf@nuthaus.mib.org> |
| In reply to | #43471 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Ian Collins <ian-news@hotmail.com> writes:
>> Ben Bacarisse wrote:
>>> Ian Collins <ian-news@hotmail.com> writes:
[...]
>>>> I'm surprised gcc doesn't issue a warning about the null dimension.
>>>
>>> (int (*)[]) and (int (*)[5]) are compatible types so there is nothing
>>> reasonable to warn about.
>>
>> As I said, it was the acceptance of "int (*)[]" as a function
>> parameter that surprised me.
>
> Ah, sorry, so not the compatibility but the type itself, at least in
> that context. What did you think gcc should/might complain about? It
> acts, I think, just like a pointer to any other incomplete type, so I'd
> be surprised if there were a complaint.
>
>> I just tried compiling the code and sure
>> enough, gcc silently accepts it while g++ considers it an error. The
>> Sun compilers issue a warning for both C and C++.
>
> Interesting. What does it (the C compiler) warn about? A compiler can
> warn about anything it likes, of course, I'm just curious to know what
> it's pointing out.
>
> <snip>
With this sample program:
#include <stdio.h>
void foo(int elems, int (*param)[]) { /* LINE 3 */
int i;
for (i = 0; i < elems; i ++) {
printf("%d%c", (*param)[i], i == elems-1 ? '\n' : ' ');
}
}
int main(void) {
int arr[] = { 10, 20, 30, 40, 50 };
foo(5, &arr);
return 0;
}
gcc doesn't issue any warnings (even with -Wall -Wextra), but Sun C 5.9
warns:
"c.c", line 3: warning: null dimension: param
Both produce the expected output:
10 20 30 40 50
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-18 08:53 -0700 |
| Message-ID | <lnfvla63dm.fsf@nuthaus.mib.org> |
| In reply to | #43061 |
"BartC" <bc@freeuk.com> writes:
> 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.
If you happen to be using gcc, the "-Wwrite-strings" option causes
string literals to be treated as if they were const. This causes gcc to
be non-conforming if you use it along with "-pedantic-errors", but it's
useful for detecting certain potential errors.
Why is it non-conforming? Because this program:
#include <stdio.h>
void print(char *s) { /* "const char *s" would be better */
puts(s);
}
int main(void) {
print("hello");
}
is perfectly legal because it doesn't actually attempt to modify the
string literal, but it would be illegal if string literals were const
(as they are in C++).
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2014-04-20 16:02 -0700 |
| Message-ID | <kfn7g6jli4d.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #43078 |
Keith Thompson <kst-u@mib.org> writes:
> "BartC" <bc@freeuk.com> writes:
>> 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.
>
> If you happen to be using gcc, the "-Wwrite-strings" option
> causes string literals to be treated as if they were const.
> This causes gcc to be non-conforming if you use it along with
> "-pedantic-errors", [because then the messages associated with
> violations are errors rather than warnings, and so forth].
I found this consequence of -pedantic-errors -Wwrite-strings a
little suprising, although personally it doesn't bother me. At
some level, however, I would call it a bug in gcc, because how
the option is specified (ie, using -W) would seem to imply a
distinct condition, but gcc lumps it in with other pointer
conversion problems. For example, I believe most people would
expect, based on the gcc documentation, that the combination of
compiler options
-Werror -Wwrite-strings -Wno-error=write-strings
would give only warnings in such cases, by analogy with, eg,
-Werror -Wunused-variable -Wno-error=unused-variable
but on trying them with gcc I found the second set worked but the
first set didn't. And the reason why seems obvious, namely, that
by the time the violation has been detected gcc has forgotten
that it arose as a result of -Wwrite-strings.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-18 16:13 +0000 |
| Message-ID | <20140418082333.779@kylheku.com> |
| In reply to | #43061 |
On 2014-04-18, BartC <bc@freeuk.com> wrote: > As far as I can gather from my experiment below, a string constant in source > code has a 'char*' type I conducted an experiment today that shows you can stick two expressions together with a comma, and the value that comes out is evidently the right one. With a bit more time, I will have this whole mysterious C thing reverse-engineered, and then I will document it for everyone.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-18 18:34 +0100 |
| Message-ID | <Kmd4v.16647$sa2.10134@fx33.am4> |
| In reply to | #43081 |
"Kaz Kylheku" <kaz@kylheku.com> wrote in message news:20140418082333.779@kylheku.com... > On 2014-04-18, BartC <bc@freeuk.com> wrote: >> As far as I can gather from my experiment below, a string constant in >> source >> code has a 'char*' type > > I conducted an experiment today that shows you can stick two expressions > together with a comma, and the value that comes out is evidently the right > one. > > With a bit more time, I will have this whole mysterious C thing > reverse-engineered, and then I will document it for everyone. If you want me to stop posting in this group, just say the word. I had been in a slow process of migrating away from using C to implement my projects, but thanks to your piss-taking, that is now a priority. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-18 11:06 -0700 |
| Message-ID | <ln38ha5x70.fsf@nuthaus.mib.org> |
| In reply to | #43085 |
"BartC" <bc@freeuk.com> writes:
> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
> news:20140418082333.779@kylheku.com...
>> On 2014-04-18, BartC <bc@freeuk.com> wrote:
>>> As far as I can gather from my experiment below, a string constant in
>>> source
>>> code has a 'char*' type
>>
>> I conducted an experiment today that shows you can stick two expressions
>> together with a comma, and the value that comes out is evidently the right
>> one.
>>
>> With a bit more time, I will have this whole mysterious C thing
>> reverse-engineered, and then I will document it for everyone.
>
> If you want me to stop posting in this group, just say the word.
>
> I had been in a slow process of migrating away from using C to implement my
> projects, but thanks to your piss-taking, that is now a priority.
If one particular person is annoying you, a killfile might be a better
solution than leaving the group. (Kaz happens to be in mine.)
--
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 | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-18 18:54 +0000 |
| Message-ID | <20140418114334.799@kylheku.com> |
| In reply to | #43085 |
On 2014-04-18, BartC <bc@freeuk.com> wrote:
>
>
> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
> news:20140418082333.779@kylheku.com...
>> On 2014-04-18, BartC <bc@freeuk.com> wrote:
>>> As far as I can gather from my experiment below, a string constant in
>>> source
>>> code has a 'char*' type
>>
>> I conducted an experiment today that shows you can stick two expressions
>> together with a comma, and the value that comes out is evidently the right
>> one.
>>
>> With a bit more time, I will have this whole mysterious C thing
>> reverse-engineered, and then I will document it for everyone.
>
> If you want me to stop posting in this group, just say the word.
To hell with the newsgroup. Look around, it's mostly insipid twits who
can't program their way out of a paper bag.
What I'd like to see you do is (I mean, for pete's sake!): stop reverse
engineering things *that are documented*, and even done the same way by
multiple implementations.
Yes, we need experimentation desperately in our daily work: to make progress in
uncharted regions, like uncovering the root causes of bugs. No piece of
documentation will tell me why this USB driver I'm trying to fix is locking up
the device.
But we don't need to experiment to find out the type of a literal constant;
that's a waste of time.
Moreover, when you experiment, you're only discovering facts about one
dialect, and sometimes not even that.
Experiment shows that gcc will accept ({int x = 3; x}) as an expression,
which returns 3. Yet that's not in standard C, which is useful to know.
Experimenting could also convince you that i = i++ has a stable behavior.
String literals being char * could just be a bug in your compiler,
for all you know, or a feature of the default dialect.
> I had been in a slow process of migrating away from using C to implement my
> projects, but thanks to your piss-taking, that is now a priority.
Why. I am not C.
Kiki has me in his killfile because I told him to go fuck himself.
And look, he still uses C!
Sheesh ...
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-18 14:15 -0700 |
| Message-ID | <d0d9b35a-f707-4702-965d-23ff6b66f98e@googlegroups.com> |
| In reply to | #43091 |
On Friday, April 18, 2014 7:54:50 PM UTC+1, Kaz Kylheku wrote: > On 2014-04-18, BartC <bc@freeuk.com> wrote: > > > Yes, we need experimentation desperately in our daily work: to make progress > in uncharted regions, like uncovering the root causes of bugs. No piece of > documentation will tell me why this USB driver I'm trying to fix is locking up > the device. > > But we don't need to experiment to find out the type of a literal constant > that's a waste of time. > Awful documentation is a fact of life in programming. Yesterday I was trying to warp the pointer on a Apple computer for example. They have lots of co-ordinate systems going, plus two types of 2D point, and what should be a simple process is in fact very involved. You need to warp the pointer experimentally to see where it goes. It is a waste of time. There's endless timewasting involved in learning the intricacies of usually proprietary systems, most of which do largely the same thing, just with slightly different syntax, identifiers, and so on.
[toc] | [prev] | [next] | [standalone]
| From | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| Date | 2014-04-20 20:15 +0200 |
| Message-ID | <pb38l9pu7lf9ooit8hnhn4tftlunrb3289@4ax.com> |
| In reply to | #43061 |
On Fri, 18 Apr 2014 11:45:23 +0100, "BartC" <bc@freeuk.com> 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?
>
>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';
>
>}
"const" would exist for declare memory space too and not one type
so "const int *p;"
means
that p can point only mem that is const
Buona Pasqua a Tutti
[toc] | [prev] | [next] | [standalone]
| From | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| Date | 2014-04-20 22:13 +0200 |
| Message-ID | <6ga8l95qu4o5tokqj6gd80qnu2ntslcalo@4ax.com> |
| In reply to | #43186 |
On Sun, 20 Apr 2014 20:15:36 +0200, Rosario193
<Rosario@invalid.invalid> wrote:
>On Fri, 18 Apr 2014 11:45:23 +0100, "BartC" <bc@freeuk.com> 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?
>>
>>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';
>>
>>}
>
>"const" would exist for declare memory space too and not one type
>so "const int *p;"
>means
>that p can point only mem that is const
>
>Buona Pasqua a Tutti
but if one think better where is the const mem in a pc? not exist...
the memory is both or readable writable or not readable writable
at last i think that
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-20 14:31 -0700 |
| Message-ID | <lnppkb1ydq.fsf@nuthaus.mib.org> |
| In reply to | #43188 |
Rosario193 <Rosario@invalid.invalid> writes:
[...]
> but if one think better where is the const mem in a pc? not exist...
> the memory is both or readable writable or not readable writable
> at last i think that
PCs do have read-only memory. They can also have regions of RAM
treated as read-only by the operating system, so that a program can read
it but not write it.
Try reading and writing a string literal in a C program and see what happens.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-20 14:30 -0700 |
| Message-ID | <lntx9n1yfy.fsf@nuthaus.mib.org> |
| In reply to | #43186 |
Rosario193 <Rosario@invalid.invalid> writes:
[...]
> "const" would exist for declare memory space too and not one type
> so "const int *p;"
> means that p can point only mem that is const
In what language? That's not what "const" means in C.
--
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 | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| Date | 2014-04-21 02:43 +0200 |
| Message-ID | <iaq8l9l6q84jirbgbb8ktam5km664jh18m@4ax.com> |
| In reply to | #43194 |
On Sun, 20 Apr 2014 14:30:09 -0700, Keith Thompson wrote: >Rosario193 <Rosario@invalid.invalid> writes: >[...] >> "const" would exist for declare memory space too and not one type >> so "const int *p;" >> means that p can point only mem that is const > >In what language? That's not what "const" means in C. it would be all easier if not exist read only memory
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-21 03:12 +0000 |
| Message-ID | <20140420200836.833@kylheku.com> |
| In reply to | #43204 |
On 2014-04-21, Rosario193 <Rosario@invalid.invalid> wrote: > On Sun, 20 Apr 2014 14:30:09 -0700, Keith Thompson wrote: >>Rosario193 <Rosario@invalid.invalid> writes: >>[...] >>> "const" would exist for declare memory space too and not one type >>> so "const int *p;" >>> means that p can point only mem that is const >> >>In what language? That's not what "const" means in C. > > it would be all easier if not exist read only memory "All" would be easier? Really, now; don't you think that is a bit of an exaggeration ... Would it be easier for a computer to boot without some read-only memory? Or at least erasable, re-writable read-only memory? "All" would not be easier, would it. In general, stuff that doesn't change is easier to deal with than stuff which changes. A large number of bugs comes from unintended modification to read-write storage; and pretty much all the hard-to-find ones fall into this category.
[toc] | [prev] | [next] | [standalone]
| From | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| Date | 2014-04-21 09:08 +0200 |
| Message-ID | <rkg9l95engdtc702vnnj3d4plt8ssq5s20@4ax.com> |
| In reply to | #43207 |
On Mon, 21 Apr 2014 03:12:47 +0000 (UTC), Kaz Kylheku wrote: >On 2014-04-21, Rosario193 <Rosario@invalid.invalid> wrote: >> On Sun, 20 Apr 2014 14:30:09 -0700, Keith Thompson wrote: >>>Rosario193 <Rosario@invalid.invalid> writes: >>>[...] >>>> "const" would exist for declare memory space too and not one type >>>> so "const int *p;" >>>> means that p can point only mem that is const >>> >>>In what language? That's not what "const" means in C. >> >> it would be all easier if not exist read only memory > >"All" would be easier? > >Really, now; don't you think that is a bit of an exaggeration ... > >Would it be easier for a computer to boot without some read-only memory? Or at >least erasable, re-writable read-only memory? i say programs are easy to write if all mem they have to deal is (read and write) or (not read and not write) >"All" would not be easier, would it. > >In general, stuff that doesn't change is easier to deal with than stuff which >changes. yes but one has to reserch the perfection and the easy of write complex algo >A large number of bugs comes from unintended modification to read-write >storage; and pretty much all the hard-to-find ones fall into this category. i not find that, but i have little experience
[toc] | [prev] | [standalone]
Page 14 of 14 — ← Prev page 1 … 12 13 [14]
Back to top | Article view | comp.lang.c
csiph-web