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 9 of 14 — ← Prev page 1 … 7 8 [9] 10 11 … 14 Next page →
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-29 04:29 +0000 |
| Message-ID | <ljn9qm$b3n$1@speranza.aioe.org> |
| In reply to | #43804 |
Kaz Kylheku <kaz@kylheku.com> wrote: (snip) > We can easily talk, informally, about o being passed by > reference (not &o, of course). > The variable o is the important value, and & is just a piece > of "C fluff" to get the called function to be able to update o. Part of the design of VAX was standardized calling conventions, including call by value, reference, and descriptor. (And at the time that C was young.) To override the default convention, you use %val(), %ref(), or %descr() around the appropriate argument. Seems to me, then, that VAX C should allow %ref(o) instead of &o, though I never tried it. Different fluff. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Richard <rgrdev_@gmail.com> |
|---|---|
| Date | 2014-04-29 09:14 +0200 |
| Message-ID | <8738gw4ng9.fsf@gmail.com> |
| In reply to | #43805 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Kaz Kylheku <kaz@kylheku.com> wrote: > > (snip) > >> We can easily talk, informally, about o being passed by >> reference (not &o, of course). > >> The variable o is the important value, and & is just a piece >> of "C fluff" to get the called function to be able to update o. > > Part of the design of VAX was standardized calling conventions, > including call by value, reference, and descriptor. (And at the > time that C was young.) > > To override the default convention, you use %val(), %ref(), > or %descr() around the appropriate argument. > > Seems to me, then, that VAX C should allow %ref(o) instead > of &o, though I never tried it. > > Different fluff. > > -- glen > Or everyone should get over themselves and recognise &o for what it is. -- "Avoid hyperbole at all costs, its the most destructive argument on the planet" - Mark McIntyre in comp.lang.c
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-29 14:05 +0100 |
| Message-ID | <0.5a11a9439c09b4f49333.20140429140513BST.871twgxp4m.fsf@bsb.me.uk> |
| In reply to | #43807 |
Richard <rgrdev_@gmail.com> writes: <snip> > Or everyone should get over themselves and recognise &o for what it > is. Yes, exactly. (I never thought I'd say that!) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-29 00:37 -0700 |
| Message-ID | <2b32676d-a2e3-4c9b-bb02-140fa63397d0@googlegroups.com> |
| In reply to | #43793 |
On Tuesday, April 29, 2014 1:31:47 AM UTC+1, Kaz Kylheku wrote:
>
> How about:
>
> inline assign_42(int *i)
>
> {
>
> *i = 42;
>
> }
>
> assign_42(&x); /* generates the same code as x = 42: no pointer */
>
> If T is an external function in a separately compiled module,
> I don't see how Fortran can achieve it without a reference datum
> being passed indicating the location of I.
> (Or worse: call-by-name thunk or its ilk.)
>
Fortran 7 disallows recursion. So you don't need a stack.
In C, you do need a stack. There are also several situations in which the
assign by reference function will not be able to be replaced by a simple
assignment.
1) The function's address is taken. So the optimsing compiler has to
check the whole function first.
2) We've got a situation where the function is called with a pointer which
is assigned to a or b depending on some condition.
3) If the function is called with a null pointer. (Obviously you'd have to
not do the write in this situation. You can easily imagine a situation
where a human knows that the write can never happen, but a compiler can't
work it out).
4)If caller plays silly games, eg passing a pointer to a double to an int*.
But the main point is that in C the other arguments are going on the stack
anyway. So you've got to set up a stack pointer and push values onto it.
So most compiler writers will simply also take the pointer and push it on.
[toc] | [prev] | [next] | [standalone]
| From | Richard <rgrdev_@gmail.com> |
|---|---|
| Date | 2014-04-29 13:36 +0200 |
| Message-ID | <87bnvk74gk.fsf@gmail.com> |
| In reply to | #43808 |
ram@zedat.fu-berlin.de (Stefan Ram) writes: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>In C, you do need a stack. > > Recursion can be implemented with linked activation records > on a heap. (In an abstract sense, this is a stack, too.) > All stacks are "abstract". -- "Avoid hyperbole at all costs, its the most destructive argument on the planet" - Mark McIntyre in comp.lang.c
[toc] | [prev] | [next] | [standalone]
| From | ralph <nt_consulting@yahoo.com> |
|---|---|
| Date | 2014-04-29 07:49 -0500 |
| Message-ID | <0i7vl99ufqivhp53uu5h9eo61aee5sd2ad@4ax.com> |
| In reply to | #43814 |
On Tue, 29 Apr 2014 13:36:11 +0200, Richard <rgrdev_@gmail.com> wrote: >ram@zedat.fu-berlin.de (Stefan Ram) writes: > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>In C, you do need a stack. >> >> Recursion can be implemented with linked activation records >> on a heap. (In an abstract sense, this is a stack, too.) >> > >All stacks are "abstract". Until you run out of "stack space". "Abstract" quickly becomes concrete, with results analogous to real life events. <g> -ralph
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-29 06:28 -0700 |
| Message-ID | <cbe5f957-e3c0-4383-8927-534b9bd22ac3@googlegroups.com> |
| In reply to | #43808 |
On Tuesday, April 29, 2014 12:15:19 PM UTC+1, Stefan Ram wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > >In C, you do need a stack. > > Recursion can be implemented with linked activation records > on a heap. (In an abstract sense, this is a stack, too.) > Some small C compilers don't use stacks, and disallow recursion. They also might restrict the number of parameters allowed in a function. But basically you need a stack. Remember you've also got variadic functions to support. In Fortran you don't. There are no local copies of parameters, and the call tree is defined.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-29 07:37 -0700 |
| Message-ID | <lnwqe8nqvu.fsf@nuthaus.mib.org> |
| In reply to | #43821 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Tuesday, April 29, 2014 12:15:19 PM UTC+1, Stefan Ram wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> >In C, you do need a stack.
>>
>> Recursion can be implemented with linked activation records
>> on a heap. (In an abstract sense, this is a stack, too.)
>>
> Some small C compilers don't use stacks, and disallow recursion.
Then they're not C compilers (though they may be perfectly useful
compilers for some C-like dialect).
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2014-04-29 17:15 +0200 |
| Message-ID | <ljoflr$hkk$1@dont-email.me> |
| In reply to | #43825 |
On 29/04/14 16:37, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> On Tuesday, April 29, 2014 12:15:19 PM UTC+1, Stefan Ram wrote: >>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> >>>> In C, you do need a stack. >>> >>> Recursion can be implemented with linked activation records >>> on a heap. (In an abstract sense, this is a stack, too.) >>> >> Some small C compilers don't use stacks, and disallow recursion. > > Then they're not C compilers (though they may be perfectly useful > compilers for some C-like dialect). > On the compilers I have seen of this sort, they don't normally use stacks and recursion is avoided when possible - but is not disallowed completely. Stacks on chips like the 8051 are extremely inefficient for data, so the compiler usually aims to use fixed memory addresses for parameter passing and local data (the hardware stack is fine for return addresses). On some such compilers, you need special pragmas or extra keywords to allow a function to be recursive or re-entrant - then it is not standard C since you need extra compiler-specific lines to get standard re-entrant behaviour. On other compilers, the compiler can figure out if a function is used recursively (or re-entrantly from interrupts) and generate the software stack code only when strictly needed. My guess is that such compilers are then standard C on that particular point. Typically such compilers stray from standard C on other issues, such as lack of double-precision floating point (sometimes lack of single-precision floats too), and perhaps lack of 32-bit integer types, etc. They are, as you say, a C-like dialect.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-29 20:58 +0000 |
| Message-ID | <ljp3op$1tk$1@speranza.aioe.org> |
| In reply to | #43829 |
David Brown <david.brown@hesbynett.no> wrote: (snip, someone wrote) >>> Some small C compilers don't use stacks, and disallow recursion. >> Then they're not C compilers (though they may be perfectly useful >> compilers for some C-like dialect). > On the compilers I have seen of this sort, they don't normally use > stacks and recursion is avoided when possible - but is not disallowed > completely. Stacks on chips like the 8051 are extremely inefficient for > data, so the compiler usually aims to use fixed memory addresses for > parameter passing and local data (the hardware stack is fine for return > addresses). If you declare all data static, it won't need to go on the stack. If you pass arguments in file scope or external variables, instead of function arguments, they won't go on a stack. I think I remember some processors with a four entry return address stack. > On some such compilers, you need special pragmas or extra > keywords to allow a function to be recursive or re-entrant - then it is > not standard C since you need extra compiler-specific lines to get > standard re-entrant behaviour. On other compilers, the compiler can > figure out if a function is used recursively (or re-entrantly from > interrupts) and generate the software stack code only when strictly > needed. My guess is that such compilers are then standard C on that > particular point. Also, the standard allows for differences in non-hosted systems. > Typically such compilers stray from standard C on other issues, such as > lack of double-precision floating point (sometimes lack of > single-precision floats too), and perhaps lack of 32-bit integer types, > etc. They are, as you say, a C-like dialect. They might have a name with a C in it, but still not claim to be C compilers. -- glen
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2014-04-30 10:16 +0200 |
| Message-ID | <ljqbgn$eoa$1@dont-email.me> |
| In reply to | #43843 |
On 29/04/14 22:58, glen herrmannsfeldt wrote: > David Brown <david.brown@hesbynett.no> wrote: > > (snip, someone wrote) > >>>> Some small C compilers don't use stacks, and disallow recursion. > >>> Then they're not C compilers (though they may be perfectly useful >>> compilers for some C-like dialect). > >> On the compilers I have seen of this sort, they don't normally use >> stacks and recursion is avoided when possible - but is not disallowed >> completely. Stacks on chips like the 8051 are extremely inefficient for >> data, so the compiler usually aims to use fixed memory addresses for >> parameter passing and local data (the hardware stack is fine for return >> addresses). > > If you declare all data static, it won't need to go on the stack. > If you pass arguments in file scope or external variables, instead of > function arguments, they won't go on a stack. > The idea with such compilers is that you /don't/ declare the data static (unless you would normally do so, of course) - you declare your local variables and function parameters normally. The compiler then translates these into sort-of static data. Because the compiler knows the lifetimes of these sort-of-static variables, it can share them among functions in a way that would be impossible for real static data - these chips don't have much ram either, so such sharing is essential. > I think I remember some processors with a four entry return > address stack. I've worked with one with a three entry return stack (and no ram at all - just 32 8-bit registers). I programmed it with gcc - but it was a small program, and didn't use /all/ the features of C ! > >> On some such compilers, you need special pragmas or extra >> keywords to allow a function to be recursive or re-entrant - then it is >> not standard C since you need extra compiler-specific lines to get >> standard re-entrant behaviour. On other compilers, the compiler can >> figure out if a function is used recursively (or re-entrantly from >> interrupts) and generate the software stack code only when strictly >> needed. My guess is that such compilers are then standard C on that >> particular point. > > Also, the standard allows for differences in non-hosted systems. > >> Typically such compilers stray from standard C on other issues, such as >> lack of double-precision floating point (sometimes lack of >> single-precision floats too), and perhaps lack of 32-bit integer types, >> etc. They are, as you say, a C-like dialect. > > They might have a name with a C in it, but still not claim to be > C compilers. > Some claim to be C even though they fail to implement sizeable parts of the language and standards, others claim to be "standard C" but don't specify a standard, some call themselves "C" without mentioning standards even though they follow them very closely - there is a wide variation. But I don't think I've ever seen an embedded compiler that honestly called itself a "C-like" compiler.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-29 16:04 +0000 |
| Message-ID | <20140429090418.198@kylheku.com> |
| In reply to | #43825 |
On 2014-04-29, Keith Thompson <kst-u@mib.org> wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> On Tuesday, April 29, 2014 12:15:19 PM UTC+1, Stefan Ram wrote: >>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> >>> >In C, you do need a stack. >>> >>> Recursion can be implemented with linked activation records >>> on a heap. (In an abstract sense, this is a stack, too.) >>> >> Some small C compilers don't use stacks, and disallow recursion. > > Then they're not C compilers (though they may be perfectly useful > compilers for some C-like dialect). A C-like dialect is C; it's just not ISO C.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2014-04-29 16:10 +0000 |
| Message-ID | <ljoit7$41o$2@news.xmission.com> |
| In reply to | #43833 |
In article <20140429090418.198@kylheku.com>, Kaz Kylheku <kaz@kylheku.com> wrote: >On 2014-04-29, Keith Thompson <kst-u@mib.org> wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> On Tuesday, April 29, 2014 12:15:19 PM UTC+1, Stefan Ram wrote: >>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>> >>>> >In C, you do need a stack. >>>> >>>> Recursion can be implemented with linked activation records >>>> on a heap. (In an abstract sense, this is a stack, too.) >>>> >>> Some small C compilers don't use stacks, and disallow recursion. >> >> Then they're not C compilers (though they may be perfectly useful >> compilers for some C-like dialect). > >A C-like dialect is C; it's just not ISO C. Not in *this* newsgroup, buddy! -- Given Bush and his insanely expensive wars (*), that we will be paying for for generations to come, the only possible response a sensible person need ever give, when a GOPer/TeaBagger says anything about "deficits", is a polite snicker. (*) Obvious money transfers between the taxpayers and Bush's moneyed interests. Someday, we'll actually figure out a way to have a war where the money just gets moved around and nobody (on either side) gets injured or killed. That will be an accomplishment of which we will be justly proud.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-29 09:58 -0700 |
| Message-ID | <6fd89459-b91d-4353-b4a0-21e4365e32c9@googlegroups.com> |
| In reply to | #43835 |
On Tuesday, April 29, 2014 5:10:15 PM UTC+1, Kenny McCormack wrote: > In article <20140429090418.198@kylheku.com>, > > >A C-like dialect is C; it's just not ISO C. > > Not in *this* newsgroup, buddy! > A duck that says "who's a pretty boy then?" instead of quacking is still a duck. So is one that doesn't like to swim, or eats fruit instead of worms and bits of bread. But there comes a point when we have to say it's not a duck at all, it's a parrot.
[toc] | [prev] | [next] | [standalone]
| From | Richard <rgrdev_@gmail.com> |
|---|---|
| Date | 2014-04-30 12:46 +0200 |
| Message-ID | <874n1bxfh1.fsf@gmail.com> |
| In reply to | #43837 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Tuesday, April 29, 2014 5:10:15 PM UTC+1, Kenny McCormack wrote: >> In article <20140429090418.198@kylheku.com>, >> >> >A C-like dialect is C; it's just not ISO C. >> >> Not in *this* newsgroup, buddy! >> > A duck that says "who's a pretty boy then?" instead of quacking is still a duck. > So is one that doesn't like to swim, or eats fruit instead of worms and bits of > bread. > > But there comes a point when we have to say it's not a duck at all, > it's a parrot. Err yeah. But that's when it is a parrot. -- "Avoid hyperbole at all costs, its the most destructive argument on the planet" - Mark McIntyre in comp.lang.c
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-29 14:51 +0000 |
| Message-ID | <ljoeaf$739$1@speranza.aioe.org> |
| In reply to | #43821 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: (snip) > Some small C compilers don't use stacks, and disallow recursion. They > also might restrict the number of parameters allowed in a function. But > basically you need a stack. Remember you've also got variadic functions > to support. > In Fortran you don't. There are no local copies of parameters, and the > call tree is defined. More specifically, many Fortran 66 and 77 compilers allocated all variables statically. Some used static storage for the return address. The PDP-8 stores the return address in the first word of a subroutine, then branches to the next word. Return is an indirect jump through the first word. Works fine without recursion, but fails if the program is in ROM. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-29 16:05 +0000 |
| Message-ID | <20140429090514.801@kylheku.com> |
| In reply to | #43826 |
On 2014-04-29, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > (snip) >> Some small C compilers don't use stacks, and disallow recursion. They >> also might restrict the number of parameters allowed in a function. But >> basically you need a stack. Remember you've also got variadic functions >> to support. > >> In Fortran you don't. There are no local copies of parameters, and the >> call tree is defined. > > More specifically, many Fortran 66 and 77 compilers allocated > all variables statically. Some used static storage for the > return address. Written by people who counted on their pensions to be statically allocated. :)
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-29 01:53 +0000 |
| Message-ID | <ljn0n3$pji$1@speranza.aioe.org> |
| In reply to | #43790 |
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: (snip) >> I am not so sure what that means, but Fortran has much stricter >> aliasing rules than C. > My point was that when a Fortran compiler is using call by reference, it > is not required to pass a pointer and then dereference it. That was the > claim Kaz made that I was replying to. In a fragment like this: > J = 99 > CALL T(J) > ... > SUBROUTINE T(I) > I = 42 > END > the compiler can generate the same code (modulo the constant) for the > assignment to I as it does for the assignment to J. Some compilers > might pass an address then dereference it, but they are not required to > do that in all situations. The Fortran trandition was to compile each one separately, even if they are in the same file. (Unlike C, with file scope variables.) It might be, though, that more now optimize between routines, such that they could consider that case. It could also be fixed at link time. The VAX/VMS compiler passes CHARACTER arguments by descriptor, except that it also has to allow for passing a string constant to a non-CHARACTER dummy argument (for Fortran 66 compatibility). It does that by having the linker fix it, since the address is the first part of the descriptor, it can replace the descriptor address with the reference address at link time. > My remark "no more than any assignment does" is just a nod to the fact > that any assignment implicitly involves an indirect access, but there > need be no extra work simply because of the argument passing semantics. -- glen
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-28 23:11 +0000 |
| Message-ID | <ljmn6f$779$1@speranza.aioe.org> |
| In reply to | #43751 |
Kaz Kylheku <kaz@kylheku.com> wrote: (snip on call by reference, or not) > Assignment to i resulting in changing a variable in the caller, > is a feature of "pass by transparent/invisible reference". > "Pass by explicit/visible reference" requires that a dereferencing > operator be applied to the reference to designate the caller's object > from which the reference was obtained. So, the C [] operator is a visible dereference operator, but the Fortran () (dummy array subscript) is not? But C is different from Fortran in the need for * (or [0]) on scalar arguments. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-28 23:29 +0000 |
| Message-ID | <20140428161934.208@kylheku.com> |
| In reply to | #43770 |
On 2014-04-28, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > Kaz Kylheku <kaz@kylheku.com> wrote: > > (snip on call by reference, or not) > >> Assignment to i resulting in changing a variable in the caller, >> is a feature of "pass by transparent/invisible reference". > >> "Pass by explicit/visible reference" requires that a dereferencing >> operator be applied to the reference to designate the caller's object >> from which the reference was obtained. > > So, the C [] operator is a visible dereference operator, but > the Fortran () (dummy array subscript) is not? Ah, but in the case of arrays being passed around as a pointer to the first element, this operator is used everywhere: by the caller and callee alike. It is not an operator which is inserted only in the called function specifically to dereference the parameter. Arrays in fact look like "pass by invisible reference". The invisibility comes from the implicit array-to-pointer decay, and the way the array subscript works on the reference just as well as on the array (so much so that all array subscripting itself is defined that way). And further assisting the invisiblity is that we can declare the function parameter using array syntax. We call a function, giving the array as an argument: func(array). In the function, we use the parameter as an array with subscripting, and assignments to the element change the caller's array object. It quacks almost like a duck, just with a slight goosey accent. > But C is different from Fortran in the need for * (or [0]) > on scalar arguments. Or the non-scalar argument case of an array being passed using a "pointer to array"!
[toc] | [prev] | [next] | [standalone]
Page 9 of 14 — ← Prev page 1 … 7 8 [9] 10 11 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web