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 13 of 14 — ← Prev page 1 … 11 12 [13] 14 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-22 10:17 -0700 |
| Message-ID | <lnmwfdxozs.fsf@nuthaus.mib.org> |
| In reply to | #43308 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Tuesday, April 22, 2014 5:35:19 PM UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> > I don't have an easy answer, but essentially const makes the wrong
>> > distinction, which is between opaque and transparent pointers, not
>> > between writeable and non-writeable ones. Normally it's none of
>> > caller's business whether a subroutine is setting flags in a
>> > structure passed to it or not.
>>
>> Your statement that const makes the distinction between opaque and
>> transparent pointers doesn't make much sense to me. Is that really
>> what you meant?
>>
> I accidentally wrote nonsense.
It happens to all of us.
> The distinction we really need to draw is between opaque and
> transparent pointers. const doesn't do that, it distinguishes between
> writeable and non-writeable ones, and even that not very well, because
> it doesn't struck to nested pointers embedded within the structure.
>
> const isn't appropriate for an opaque pointer, because the whole point
> is that caller doesn't need to know whether its being modified
> internally or not. With transparent pointers, it does have a purpose,
> but a pretty minor one, because normally if a transparent pointer is
> modified, then the purpose of the call is to create that modification
> and examine it or use it in some way. If it's not modified, then the
> purpose of the structure is to provide input parameters for the
> call. So "const" isn't especially helpful - not to say there won't be
> a few situations where it's very helpful, but as a general rule it's a
> reminder you don't need.
I mostly agree with your point about const with opaque pointers. For
opaque data structures (FILE is a good example), you typically want the
functions defined in the interface to deal with the internals. Whether
those functions modify members of the FILE structure (assuming it's a
structure) are typically of no relevance to client code, which will deal
only with FILE* pointers created by functions in the interface.
Which is why fopen, fread, et al take arguments of type FILE* and not
const FILE*.
But there's plenty of code behind the scenes that implements that
abstract interface, and I would *hope* that it makes judicious use of
"const" to avoid and detect logical errors.
How much C code actually use opaque types? Without having done a
survey, I'd say "not a whole lot" and "probably not enough".
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-22 10:31 -0700 |
| Message-ID | <ebfcf7e2-c2e8-468d-aa74-b8aae60c7f2c@googlegroups.com> |
| In reply to | #43313 |
On Tuesday, April 22, 2014 6:17:43 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > How much C code actually use opaque types? Without having done a > survey, I'd say "not a whole lot" and "probably not enough". > I use opaque types pretty heavily. But a lot of people would turn to C++ for the same problems.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-22 02:33 -0700 |
| Message-ID | <708fa974-9f9a-463a-af92-82d7de4275bb@googlegroups.com> |
| In reply to | #43133 |
On Saturday, April 19, 2014 9:20:03 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > And how often are you going to want to modify data in place in a string > containing CSV data? You can only do that if the replacement data is > exactly the same length as the original data; you can't change > "...,9,..." to "...,10,..." without shifting the rest of the string and > perhaps allocating extra memory. I'd say it's perfectly acceptable in > this case to provide *only* a function that doesn't let you modify > anything. (And if you really need to modify the string, you can either > write that second function or *carefully* use casts to override the > "const".) > This is it. Rarely. So the const version will be fine, until someone wants to put all the alphabetics into upper case or something. Then the const becomes a thundering nuisance. Saying that it can be cast away is a desperate solution.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-04-22 21:37 +1200 |
| Message-ID | <brmrj6F43uvU10@mid.individual.net> |
| In reply to | #43267 |
Malcolm McLean wrote: > On Saturday, April 19, 2014 9:20:03 PM UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> And how often are you going to want to modify data in place in a >> string containing CSV data? You can only do that if the >> replacement data is exactly the same length as the original data; >> you can't change "...,9,..." to "...,10,..." without shifting the >> rest of the string and perhaps allocating extra memory. I'd say >> it's perfectly acceptable in this case to provide *only* a function >> that doesn't let you modify anything. (And if you really need to >> modify the string, you can either write that second function or >> *carefully* use casts to override the "const".) >> > This is it. Rarely. So the const version will be fine, until someone > wants to put all the alphabetics into upper case or something. Then > the const becomes a thundering nuisance. Saying that it can be cast > away is a desperate solution. It also the wrong solution. You transform the data, then parse it. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-22 07:17 -0700 |
| Message-ID | <lnoaztzbxc.fsf@nuthaus.mib.org> |
| In reply to | #43269 |
Ian Collins <ian-news@hotmail.com> writes:
> Malcolm McLean wrote:
>> On Saturday, April 19, 2014 9:20:03 PM UTC+1, Keith Thompson wrote:
>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>
>>> And how often are you going to want to modify data in place in a
>>> string containing CSV data? You can only do that if the
>>> replacement data is exactly the same length as the original data;
>>> you can't change "...,9,..." to "...,10,..." without shifting the
>>> rest of the string and perhaps allocating extra memory. I'd say
>>> it's perfectly acceptable in this case to provide *only* a function
>>> that doesn't let you modify anything. (And if you really need to
>>> modify the string, you can either write that second function or
>>> *carefully* use casts to override the "const".)
>>>
>> This is it. Rarely. So the const version will be fine, until someone
>> wants to put all the alphabetics into upper case or something. Then
>> the const becomes a thundering nuisance. Saying that it can be cast
>> away is a desperate solution.
>
> It also the wrong solution. You transform the data, then parse it.
Not if you just want to convert, say, the 3rd comma-delimited field to
upper case.
But I don't think a rare special case like that justifies dropping
"const" from the language.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-19 13:42 +0100 |
| Message-ID | <obu4v.33705$Cn.30106@fx06.am4> |
| In reply to | #43117 |
"Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message news:9fd76d44-6d6b-466e-8515-0b3a806854cd@googlegroups.com... > On Saturday, April 19, 2014 12:06:38 AM UTC+1, Kaz Kylheku wrote: >> On 2014-04-18, BartC <bc@freeuk.com> wrote: >> >> Although C++ has "const char *" string literals, that was a relatively >> late >> decision in in the history of C++. >> >> In C, a the safety benefits go out the window as soon as you use a >> function >> like: >> >> char *strchr(const char *str, int c); >> > And you very rarely want to call strchr with an explicit string literal, > but > you quite often want to parse a string literal passed from above. > The poor rules for string literals are seldom much of a practical problem, > because if in a real program a function modifies a string passed to it, > the > caller is going to want to examine the result. So he can't pass a string > literal. > const rules mean that you have to have two versions of strchr, which isn't > too bad. But they also mean that anyone writing a strchr-like function to > parse a string needs to write two versions. That's unacceptable. In general, you need one function taking const char*, as that will accept, without errors, either char* or const char* arguments. The problem in this example, is when you return the same input string, or a slice of it, then you want the output type to match that of the argument: either const char* or char*. That's tricky to do with just the one function and its one return type. This is a more general problem with 'const': it can quickly turn into a nuisance, if you strive to do the right thing everywhere, and possibly distract you from other things. Perhaps better to just accept that you are programming in C, after all, where you need to live a little more dangerously.) It doesn't help that as C implements it (a necessity, given its fairly low level and its role in implementing everything else), any type (parameter type etc) can be arbitrary complex and 'const's can appear anywhere in the type structure: const/non-const pointers to arrays of const/non-const elements, or to structs of a mix of const/non-const elements including const/non-const pointers to other const/non-const structs and arrays... Even if a compiler can untangle it all, frequently a human can't! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2014-04-19 15:42 +0000 |
| Message-ID | <slrn3vfsll56ao.cmu.ike@iceland.freeshell.org> |
| In reply to | #43117 |
On 2014-04-19, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> And you very rarely want to call strchr with an explicit string literal, [...]
I sometime use
if (strchr("KMGTP",c))
as a shorthand for
if (c=='K' || c=='M' || c=='G' || c=='T' || c=='P')
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-19 16:19 +0000 |
| Message-ID | <20140419091441.999@kylheku.com> |
| In reply to | #43127 |
On 2014-04-19, Ike Naar <ike@iceland.freeshell.org> wrote:
> On 2014-04-19, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>> And you very rarely want to call strchr with an explicit string literal, [...]
>
> I sometime use
>
> if (strchr("KMGTP",c))
>
> as a shorthand for
>
> if (c=='K' || c=='M' || c=='G' || c=='T' || c=='P')
On the same note, I just remembered something. Check out this utility:
It has tons of strchr over literals to do set testing, just like
your shorthand above.
http://www.kylheku.com/cgit/c-snippets/tree/autotab.c
This is little a program which analyzes a file to determine the tabstop,
expandtab and shiftwidth settings for Vim.
[toc] | [prev] | [next] | [standalone]
| From | Seungbeom Kim <musiphil@bawi.org> |
|---|---|
| Date | 2014-04-19 17:47 -0700 |
| Message-ID | <liv5eb$sgt$1@usenet.stanford.edu> |
| In reply to | #43117 |
On 2014-04-19 03:57, Malcolm McLean wrote:
> const rules mean that you have to have two versions of strchr, which isn't
> too bad. But they also mean that anyone writing a strchr-like function to
> parse a string needs to write two versions. That's unacceptable.
Still a nuisance, but not too bad as one version can often delegate
the actual work to the other version and just add a cast. For example:
const char *strchr_c(const char *str, int c) { /* actual work */ }
char *strchr_nc(char *str, c) {
return (char *)strchr_c(str, c);
}
// or
char *strchr_nc(char *str, int c) { /* actual work */ }
const char *strchr_c(const char *str, c) {
return strchr_nc((char *)str, c);
}
(Casting in itself is typically a no-op, and the compiler may be smart
enough to inline the delegating function or make it into a thunk.)
With generics, a single function (such as std::find in C++) works with
many different types, including const/non-const; needing const/non-const
versions for strchr is just analogous to needing float/double/long double
versions for each math function.
--
Seungbeom Kim
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2014-04-22 11:00 -0500 |
| Message-ID | <lj63nn$hoa$1@dont-email.me> |
| In reply to | #43103 |
On 18-Apr-14 17:53, BartC wrote: > "Ian Collins" <ian-news@hotmail.com> wrote in message > news:brdil0F43uvU1@mid.individual.net... >> Maybe you should start compiling your C with a C++ compiler? The >> const rules in C++ are much closer to what you are expecting. > > This particular issue isn't bothering me at the minute. I was just > intrigued at the more rigorous enforcement of const types on one hand, > compared with the lax approach used with string constants. It's never > really come up before because I refuse to use 'const' anywhere. Then you're throwing away one of the few type-safety features that C offers, which doesn't seem wise. > (And I have tried using g++ to compile my code (with a view to > simplifying using libraries only having a C++ interface), but it's even > more of a nightmare getting it to compile my C code, most of which is > auto-generated in various ways.) Sounds like your auto-generator is broken; getting it to produce code in the C-like subset of C++ should be trivial. 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-22 18:36 +0100 |
| Message-ID | <jYx5v.117758$Ey6.76735@fx24.am4> |
| In reply to | #43300 |
"Stephen Sprunk" <stephen@sprunk.org> wrote in message news:lj63nn$hoa$1@dont-email.me... > On 18-Apr-14 17:53, BartC wrote: >> "Ian Collins" <ian-news@hotmail.com> wrote in message >> news:brdil0F43uvU1@mid.individual.net... >>> Maybe you should start compiling your C with a C++ compiler? The >>> const rules in C++ are much closer to what you are expecting. >> >> This particular issue isn't bothering me at the minute. I was just >> intrigued at the more rigorous enforcement of const types on one hand, >> compared with the lax approach used with string constants. It's never >> really come up before because I refuse to use 'const' anywhere. > > Then you're throwing away one of the few type-safety features that C > offers, which doesn't seem wise. > >> (And I have tried using g++ to compile my code (with a view to >> simplifying using libraries only having a C++ interface), but it's even >> more of a nightmare getting it to compile my C code, most of which is >> auto-generated in various ways.) > > Sounds like your auto-generator is broken; getting it to produce code in > the C-like subset of C++ should be trivial. I wasn't specifically generating C++ code. I just tried a C++ compiler on the off-chance it would work. For example C++ doesn't like pointers to unbounded arrays, which my source language likes to use to differentiate between pointers to arrays and non-arrays (more useful than const/non-const IMO). Fixing that isn't so trivial. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-04-23 09:38 +1200 |
| Message-ID | <bro5qpF43v1U1@mid.individual.net> |
| In reply to | #43318 |
BartC wrote: > "Stephen Sprunk" <stephen@sprunk.org> wrote: >> >> Sounds like your auto-generator is broken; getting it to produce code in >> the C-like subset of C++ should be trivial. > > I wasn't specifically generating C++ code. I just tried a C++ compiler on > the off-chance it would work. > > For example C++ doesn't like pointers to unbounded arrays, which my source > language likes to use to differentiate between pointers to arrays and > non-arrays (more useful than const/non-const IMO). > > Fixing that isn't so trivial. Care to provide an example? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-22 23:25 +0100 |
| Message-ID | <w1C5v.92946$q95.70689@fx22.am4> |
| In reply to | #43368 |
"Ian Collins" <ian-news@hotmail.com> wrote in message
news:bro5qpF43v1U1@mid.individual.net...
> BartC wrote:
>> "Stephen Sprunk" <stephen@sprunk.org> wrote:
>>>
>>> Sounds like your auto-generator is broken; getting it to produce code in
>>> the C-like subset of C++ should be trivial.
>>
>> I wasn't specifically generating C++ code. I just tried a C++ compiler on
>> the off-chance it would work.
>>
>> For example C++ doesn't like pointers to unbounded arrays, which my
>> source
>> language likes to use to differentiate between pointers to arrays and
>> non-arrays (more useful than const/non-const IMO).
>>
>> Fixing that isn't so trivial.
>
> Care to provide an example?
Fragment of source syntax:
proc testfn(ref[]int a)=
print a^[2] # (ie. (*a)[2]; explicit deref needed)
end
proc start=
[]int a:=(10,20,30,40,50)
testfn(&a)
end
C output (there is also a header explaining what i32 is etc):
static void testfn(i32 (*a)[]) {
printf("%d",(*a)[1]); /* (adjusts 1-based to 0-based indexing) */
}
void start(void) {
i32 a[5]={10,20,30,40,50};
testfn((i32 (*)[])(&a));
}
This compiles as C (with gcc, Pelles C, lccwin32, DMC, gcc/TDM, and Clang
x86 compilers).
But g++ says this:
... error: parameter 'a' includes pointer to array of unknown bound 'i32 []
{aka int []}'
static void testfn(i32 (*a)[]) {
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-04-23 10:48 +1200 |
| Message-ID | <bro9ttF43v1U3@mid.individual.net> |
| In reply to | #43382 |
BartC wrote:
> "Ian Collins" <ian-news@hotmail.com> wrote:
>> BartC wrote:
>>> "Stephen Sprunk" <stephen@sprunk.org> wrote:
>>>>
>>>> Sounds like your auto-generator is broken; getting it to produce code in
>>>> the C-like subset of C++ should be trivial.
>>>
>>> I wasn't specifically generating C++ code. I just tried a C++ compiler on
>>> the off-chance it would work.
>>>
>>> For example C++ doesn't like pointers to unbounded arrays, which my
>>> source
>>> language likes to use to differentiate between pointers to arrays and
>>> non-arrays (more useful than const/non-const IMO).
>>>
>>> Fixing that isn't so trivial.
>>
>> Care to provide an example?
>
> Fragment of source syntax:
>
> proc testfn(ref[]int a)=
> print a^[2] # (ie. (*a)[2]; explicit deref needed)
> end
>
> proc start=
> []int a:=(10,20,30,40,50)
>
> testfn(&a)
> end
>
> C output (there is also a header explaining what i32 is etc):
>
> static void testfn(i32 (*a)[]) {
> printf("%d",(*a)[1]); /* (adjusts 1-based to 0-based indexing) */
> }
>
> void start(void) {
> i32 a[5]={10,20,30,40,50};
> testfn((i32 (*)[])(&a));
> }
>
> This compiles as C (with gcc, Pelles C, lccwin32, DMC, gcc/TDM, and Clang
> x86 compilers).
>
> But g++ says this:
>
> .... error: parameter 'a' includes pointer to array of unknown bound 'i32 []
> {aka int []}'
> static void testfn(i32 (*a)[]) {
I'm surprised gcc doesn't issue a warning about the null dimension.
You could avoid all of the casts if you wrote this in C++:
template <int N> void testfn(int (&a)[N]) {
printf("%d\n",a[1]); /* (adjusts 1-based to 0-based indexing) */
}
void start(void) {
int a[5]={10,20,30,40,50};
testfn(a);
}
Note the parameter type "int (&a)[N]" is a reference to an array of N
ints, the compiler does the rest! This is a useful trick for forwarding
array sizes to functions that use a pointer and a size as their parameters.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-23 12:37 +0100 |
| Message-ID | <0.2cd99975c0e328760512.20140423123716BST.87ha5k9t03.fsf@bsb.me.uk> |
| In reply to | #43387 |
Ian Collins <ian-news@hotmail.com> writes:
> BartC wrote:
<snip>
>> Fragment of source syntax:
>>
>> proc testfn(ref[]int a)=
>> print a^[2] # (ie. (*a)[2]; explicit deref needed)
>> end
>>
>> proc start=
>> []int a:=(10,20,30,40,50)
>>
>> testfn(&a)
>> end
>>
>> C output (there is also a header explaining what i32 is etc):
>>
>> static void testfn(i32 (*a)[]) {
>> printf("%d",(*a)[1]); /* (adjusts 1-based to 0-based indexing) */
>> }
>>
>> void start(void) {
>> i32 a[5]={10,20,30,40,50};
>> testfn((i32 (*)[])(&a));
>> }
>>
>> This compiles as C (with gcc, Pelles C, lccwin32, DMC, gcc/TDM, and Clang
>> x86 compilers).
>>
>> But g++ says this:
>>
>> .... error: parameter 'a' includes pointer to array of unknown bound 'i32 []
>> {aka int []}'
>> 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.
> You could avoid all of the casts if you wrote this in C++:
He could avoid all of the casts in C by simply not writing them!
(There's only one that I can see, and it's not needed.)
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-23 13:47 +0100 |
| Message-ID | <vHO5v.45612$N05.4198@fx12.am4> |
| In reply to | #43413 |
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:0.2cd99975c0e328760512.20140423123716BST.87ha5k9t03.fsf@bsb.me.uk...
> Ian Collins <ian-news@hotmail.com> writes:
>> BartC wrote:
>>> static void testfn(i32 (*a)[]) {
>>> printf("%d",(*a)[1]); /* (adjusts 1-based to 0-based indexing)
>>> */
>>> }
>>>
>>> void start(void) {
>>> i32 a[5]={10,20,30,40,50};
>>> testfn((i32 (*)[])(&a));
>>> But g++ says this:
>>>
>>> .... error: parameter 'a' includes pointer to array of unknown bound
>>> 'i32 []
>>> {aka int []}'
>>> 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.
>
>> You could avoid all of the casts if you wrote this in C++:
>
> He could avoid all of the casts in C by simply not writing them!
> (There's only one that I can see, and it's not needed.)
I was surprised myself. The reason seems to be that the cast is there to
convert from:
'pointer to array 5 of int'
to:
'pointer to array of int'
using Cdecl syntax.
(The source language needs arrays to be compatible (they are value types);
but it also generally doesn't care about pointer targets needing to match.
The cast must be there to keep C compilers happy. But if C doesn't need it,
that doesn't really matter. The translator generates a lot worse! This bit
of input source code:
byte swapped
repeat
until not swapped
results in this C (which I have even tidied up by removing unnecessary
labels):
u8 swapped;
do {
} while (!(!((bool)((u32)(swapped)))));
My C compilers might be suffering but they haven't complained about it so
far.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-23 14:03 +0100 |
| Message-ID | <0.8bdaa6fcdf3a2e24b3cb.20140423140308BST.87vbu08agj.fsf@bsb.me.uk> |
| In reply to | #43418 |
"BartC" <bc@freeuk.com> writes: > "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message > news:0.2cd99975c0e328760512.20140423123716BST.87ha5k9t03.fsf@bsb.me.uk... >> Ian Collins <ian-news@hotmail.com> writes: <snip> >>> You could avoid all of the casts if you wrote this in C++: >> >> He could avoid all of the casts in C by simply not writing them! > [...] But if C doesn't need it, > that doesn't really matter. The translator generates a lot worse! Yes, that's why I didn't reply to your post but to Ian's comment on it. It's not surprising that a translator's output has redundant constructs like casts and parentheses -- it's just simpler to do it that way, but Ian seemed to be suggesting that C++ could be used to avoid the cast, so I thought it helpful to point out that it is not needed, even in C. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-04-24 09:14 +1200 |
| Message-ID | <brqoouF43v1U5@mid.individual.net> |
| In reply to | #43413 |
Ben Bacarisse wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>
>> BartC wrote:
>>>
>>> This compiles as C (with gcc, Pelles C, lccwin32, DMC, gcc/TDM, and Clang
>>> x86 compilers).
>>>
>>> But g++ says this:
>>>
>>> .... error: parameter 'a' includes pointer to array of unknown bound 'i32 []
>>> {aka int []}'
>>> 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. 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++.
>> You could avoid all of the casts if you wrote this in C++:
>
> He could avoid all of the casts in C by simply not writing them!
> (There's only one that I can see, and it's not needed.)
True, but he looses the array size.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-23 23:37 +0100 |
| Message-ID | <0.a2a4900d8dc93bdd77f1.20140423233700BST.8738h38ygj.fsf@bsb.me.uk> |
| In reply to | #43464 |
Ian Collins <ian-news@hotmail.com> writes:
> Ben Bacarisse wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>
>>> BartC wrote:
>
>>>>
>>>> This compiles as C (with gcc, Pelles C, lccwin32, DMC, gcc/TDM, and Clang
>>>> x86 compilers).
>>>>
>>>> But g++ says this:
>>>>
>>>> .... error: parameter 'a' includes pointer to array of unknown bound 'i32 []
>>>> {aka int []}'
>>>> 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.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-04-24 10:54 +1200 |
| Message-ID | <brqulgF43v1U9@mid.individual.net> |
| In reply to | #43471 |
Ben Bacarisse wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>
>> Ben Bacarisse wrote:
>>> Ian Collins <ian-news@hotmail.com> writes:
>>>
>>>> BartC wrote:
>>
>>>>>
>>>>> This compiles as C (with gcc, Pelles C, lccwin32, DMC, gcc/TDM, and Clang
>>>>> x86 compilers).
>>>>>
>>>>> But g++ says this:
>>>>>
>>>>> .... error: parameter 'a' includes pointer to array of unknown bound 'i32 []
>>>>> {aka int []}'
>>>>> 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."
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
Page 13 of 14 — ← Prev page 1 … 11 12 [13] 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web