Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #64979 > unrolled thread
| Started by | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| First post | 2015-07-09 12:49 +0200 |
| Last post | 2015-07-16 09:41 +1200 |
| Articles | 20 on this page of 292 — 25 participants |
Back to article view | Back to comp.lang.c
Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 12:49 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 12:03 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 14:15 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 13:49 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:15 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 14:25 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:36 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 14:51 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 16:02 +0200
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 20:48 +0100
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-09 09:54 -0400
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 15:08 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 16:16 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 15:18 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 16:24 +0200
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 20:31 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 21:42 +0200
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-10 00:57 +0100
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 20:39 +0100
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 21:44 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-09 22:50 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-09 13:49 +0100
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 13:52 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:26 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 14:28 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-09 05:28 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:09 +0200
Re: Recursion or loop, design questions "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-09 09:25 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 18:41 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-10 11:52 -0400
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 18:44 +0200
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-10 18:52 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 20:34 +0200
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-10 11:50 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 20:56 +0200
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-10 13:30 -0700
Re: Recursion or loop, design questions Philip Lantz <prl@canterey.us> - 2015-07-11 10:51 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-11 16:07 -0700
Re: Recursion or loop, design questions Philip Lantz <prl@canterey.us> - 2015-07-12 00:20 -0700
Re: Recursion or loop, design questions gordonb.j93iw@burditt.org (Gordon Burditt) - 2015-07-11 21:26 -0500
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-09 10:08 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 19:19 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 19:11 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 21:28 +0200
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-09 13:41 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:22 +0200
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 18:45 +0200
Re: Recursion or loop, design questions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-09 18:05 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 07:06 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-11 15:51 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 09:36 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-15 10:49 -0700
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-15 13:05 -0500
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 10:28 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-20 12:41 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-20 21:37 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-24 13:05 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-24 15:07 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 12:42 -0700
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-24 15:38 -0500
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 12:39 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-30 22:35 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 07:09 -0700
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 14:43 -0500
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-03 09:48 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 21:23 +0200
Re: Recursion or loop, design questions Andrew Cooper <amc96@cam.ac.uk> - 2015-07-10 00:52 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-10 01:28 +0100
Re: Recursion or loop, design questions Phil Carmody <pc+usenet@asdf.org> - 2015-07-12 13:20 +0300
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-12 11:39 +0100
Re: Recursion or loop, design questions David Kleinecke <dkleinecke@gmail.com> - 2015-07-12 10:28 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-13 08:17 +1200
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-07-21 14:46 +0200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 19:27 -0700
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-07-13 21:16 +0000
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 08:34 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 00:46 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 12:35 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 12:47 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 14:29 +0200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 06:36 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 07:16 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 14:23 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-15 15:27 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 19:27 -0700
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-11 15:27 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 08:00 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-11 15:46 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 16:01 -0700
Re: Recursion or loop, design questions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 00:36 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 13:55 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-15 14:12 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 19:45 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 14:34 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-15 15:37 -0700
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-16 10:07 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-16 10:18 +0100
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-16 13:35 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-16 21:10 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-17 13:55 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-17 11:16 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-17 11:25 -0700
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-17 20:51 +0100
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-17 13:48 -0700
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-07-21 15:12 +0200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-21 10:56 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-21 19:43 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-21 12:52 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-21 21:17 +0100
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-07-21 23:58 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 20:39 +0100
Re: Recursion or loop, design questions Richard Damon <Richard@Damon-Family.org> - 2015-07-24 00:54 -0400
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-24 09:06 +0100
Re: Recursion or loop, design questions Richard Damon <Richard@Damon-Family.org> - 2015-07-24 08:04 -0400
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-24 13:48 +0100
Re: Recursion or loop, design questions Richard Damon <Richard@Damon-Family.org> - 2015-07-25 14:02 -0400
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 13:41 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-02 15:41 +0200
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-02 21:51 +0000
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-03 01:20 +0200
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-04 10:54 +0000
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 06:02 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 14:03 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 11:36 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 11:21 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 12:18 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 13:19 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 13:35 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 21:40 +0100
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 13:51 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 22:57 +0200
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-08-05 08:45 +0200
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 14:19 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 23:22 +0200
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 14:28 -0700
Language (was: Re: Recursion or loop, design questions) "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 23:35 +0200
Re: Language (was: Re: Recursion or loop, design questions) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 14:45 -0700
Re: Language "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 23:55 +0200
Re: Language (was: Re: Recursion or loop, design questions) fir <profesor.fir@gmail.com> - 2015-08-04 16:44 -0700
Re: Language (was: Re: Recursion or loop, design questions) fir <profesor.fir@gmail.com> - 2015-08-04 17:18 -0700
Re: Language (was: Re: Recursion or loop, design questions) fir <profesor.fir@gmail.com> - 2015-08-05 01:32 -0700
Re: Language Richard Heathfield <rjh@cpax.org.uk> - 2015-08-05 09:51 +0100
Re: Language Richard Heathfield <rjh@cpax.org.uk> - 2015-08-05 12:55 +0100
Re: Language Gareth Owen <gwowen@gmail.com> - 2015-08-05 19:12 +0100
Re: Language Richard Heathfield <rjh@cpax.org.uk> - 2015-08-06 17:09 +0100
Re: Language luser droog <luser.droog@gmail.com> - 2015-08-06 15:10 -0700
Re: Language Richard Heathfield <rjh@cpax.org.uk> - 2015-08-07 09:48 +0100
Re: Language luser droog <luser.droog@gmail.com> - 2015-08-07 13:37 -0700
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-06 10:54 +0000
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-06 13:32 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-08-06 11:06 -0400
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-06 11:52 -0700
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-08-06 21:19 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-08-06 17:59 -0400
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-06 15:54 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-06 12:56 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-07 23:45 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-08 09:27 +0200
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-08 01:09 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-08 01:34 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-08-08 13:00 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-08 14:22 -0700
Re: Recursion or loop, design questions David Kleinecke <dkleinecke@gmail.com> - 2015-08-08 16:12 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-08-08 17:31 -0700
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-09 13:34 +0000
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-09 08:38 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-09 09:31 +0200
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-09 01:52 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-06 04:40 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 20:19 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 23:59 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 15:53 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 19:43 -0700
Re: Recursion or loop, design questions David Kleinecke <dkleinecke@gmail.com> - 2015-07-25 20:05 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-27 23:53 +0100
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-03 01:51 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-03 10:04 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-17 21:34 +0100
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-17 13:52 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-17 21:57 +0100
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 10:44 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-18 11:00 +0100
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-18 05:25 -0500
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 14:26 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-18 17:38 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 10:05 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 21:31 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 14:28 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-18 15:01 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 15:39 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-18 15:44 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 15:55 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-19 10:58 +1200
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-18 16:26 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 17:23 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-18 18:04 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 00:03 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-19 13:30 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 08:45 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-19 20:59 +0200
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-19 21:19 +0200
Re: Recursion or loop, design questions Les Cargill <lcargill99@comcast.com> - 2015-07-20 07:23 -0500
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-07-19 21:11 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 15:37 -0700
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-09 13:55 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 11:22 -0700
Re: Recursion or loop, design questions Gareth Owen <gwowen@gmail.com> - 2015-07-19 17:22 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 10:25 -0700
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-19 03:15 -0500
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-19 10:36 +0100
Re: Recursion or loop, design questions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-07-19 12:45 -0400
Re: Recursion or loop, design questions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-07-19 13:05 -0400
Re: Recursion or loop, design questions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-07-19 13:09 -0400
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 10:40 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-19 22:31 +0100
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-09 14:05 +0000
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-09 21:22 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-09 16:14 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-10 05:39 +0200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 01:40 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-08-10 21:03 +1200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 03:16 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-10 12:16 +0200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 03:36 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-10 12:45 +0200
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:07 +0000
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:07 +0000
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 02:47 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-19 22:23 +1200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 05:01 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 09:55 +1200
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-19 23:13 +0100
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 10:19 +1200
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-19 17:21 -0500
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-20 00:25 +0100
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 11:45 +1200
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-20 02:34 -0500
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-20 10:52 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-20 05:31 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 22:16 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 17:24 +1200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 22:36 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 21:07 +1200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-20 02:51 -0700
Re: Recursion or loop, design questions Les Cargill <lcargill99@comcast.com> - 2015-07-19 10:12 -0500
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-19 16:54 -0500
Re: Recursion or loop, design questions Les Cargill <lcargill99@comcast.com> - 2015-07-20 12:34 -0500
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 07:28 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-27 11:08 +0200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 15:45 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-02 14:59 +0200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 08:40 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 23:05 +0200
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-19 12:46 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 12:57 -0700
Re: Recursion or loop, design questions Gareth Owen <gwowen@gmail.com> - 2015-07-19 21:16 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 15:50 -0700
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-18 09:13 -0400
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 15:04 +0100
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-18 12:40 -0400
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 16:27 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 14:26 +0100
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-18 09:58 -0400
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 15:24 +0100
Re: Recursion or loop, design questions Richard Damon <Richard@Damon-Family.org> - 2015-07-18 10:29 -0400
Re: Recursion or loop, design questions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-18 17:32 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 15:28 -0700
Re: Recursion or loop, design questions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-20 22:58 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 03:13 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 21:49 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 15:12 -0700
Re: Recursion or loop, design questions "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-20 15:21 -0700
Re: Recursion or loop, design questions "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-20 15:23 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 03:46 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 03:31 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-21 04:08 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:50 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-11 18:43 +0200
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-11 18:54 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-11 13:06 -0400
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-12 23:45 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-12 17:48 -0400
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-13 01:27 +0200
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-11 19:39 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 14:51 -0700
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-11 23:51 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 08:04 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-16 09:36 +1200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 10:37 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-21 20:55 +1200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 07:39 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-16 09:41 +1200
Page 2 of 15 — ← Prev page 1 [2] 3 4 … 15 Next page →
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-09 22:50 +0100 |
| Message-ID | <mnmq7t$5mu$1@dont-email.me> |
| In reply to | #65058 |
On 09/07/2015 20:39, Ben Bacarisse wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: >> The lexing stage creates a linked list of lexemes (lexical >> elements). The parser then processes that list, creating the object >> tree. > > For most modern syntaxes, you need only one (occasionally two) tokens > "in hand" for the parse to be done. It's very rare that you need the > tokens in a list. I use a lexing stage at the moment which first generates a complete list of tokens before it gets on to parsing; it was an experiment which seemed to work and I never bothered changing back. Although I don't know if I would recommend it; the list can get big if it includes expansions of macros and headers, if this is going to be for source code rather than XML. (I use a handful of global state variables to describe each token, they got fiddly and time-consuming to juggle even working only one or two tokens in hand. What was needed was a lexer that yielded a token at a time as needed, but could also effortlessly look ahead one or two tokens, or go back one or two. A list of tokens provided that easily.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-09 13:49 +0100 |
| Message-ID | <mnlqhr$ld0$1@dont-email.me> |
| In reply to | #64980 |
On 09/07/2015 12:03, Richard Heathfield wrote: > Readability is a higher priority than correctness, and correctness is a > higher priority than speed. Then readability is a higher priority than speed? That need not be the case! You might be specifically writing a fast version of something that already works. The user of the resultant executable won't care how readable the source is, he just wants something fast. Of course it's best if a readable, fully working version is achieved first, but that doesn't always work out either, if a lot of development or experimentation is involved. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-09 13:52 +0100 |
| Message-ID | <mnlqog$leq$2@dont-email.me> |
| In reply to | #64990 |
On 09/07/15 13:49, Bartc wrote: > On 09/07/2015 12:03, Richard Heathfield wrote: > >> Readability is a higher priority than correctness, and correctness is a >> higher priority than speed. > > Then readability is a higher priority than speed? Yes. > That need not be the case! You might be specifically writing a fast > version of something that already works. In other words, you (rightly) placed correctness over speed - you got it working *first*. Now you're speeding it up. And presumably you got it working because you could read it, which means that you (rightly) placed readability over correctness. Because you could read it, you could get it working (while keeping it readable). Now that you've got it working, you're making it fast (while keeping it working and readable). Well done. You have your priorities exactly right. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-09 15:26 +0200 |
| Message-ID | <mnlsnu$a2i$1@speranza.aioe.org> |
| In reply to | #64992 |
On 09.07.2015 14:52, Richard Heathfield wrote: > On 09/07/15 13:49, Bartc wrote: >> On 09/07/2015 12:03, Richard Heathfield wrote: >> >>> Readability is a higher priority than correctness, and correctness is a >>> higher priority than speed. >> >> Then readability is a higher priority than speed? > > Yes. > >> That need not be the case! You might be specifically writing a fast >> version of something that already works. > > In other words, you (rightly) placed correctness over speed - you got it > working *first*. Now you're speeding it up. And presumably you got it > working because you could read it, which means that you (rightly) placed > readability over correctness. > > Because you could read it, you could get it working (while keeping it > readable). > > Now that you've got it working, you're making it fast (while keeping it > working and readable). > > Well done. You have your priorities exactly right. Hm. But what about automatic tests? You can read code forever, while tests are a low cost and more or less instant readable message whether something is working or not. I found one bug today that wasn't caught by a test by reading the code, now there is a test for that specific bug as well. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-09 14:28 +0100 |
| Message-ID | <mnlsru$tf8$2@dont-email.me> |
| In reply to | #64998 |
On 09/07/15 14:26, Morten W. Petersen wrote: > On 09.07.2015 14:52, Richard Heathfield wrote: >> On 09/07/15 13:49, Bartc wrote: >>> On 09/07/2015 12:03, Richard Heathfield wrote: >>> >>>> Readability is a higher priority than correctness, and correctness is a >>>> higher priority than speed. >>> >>> Then readability is a higher priority than speed? >> >> Yes. >> >>> That need not be the case! You might be specifically writing a fast >>> version of something that already works. >> >> In other words, you (rightly) placed correctness over speed - you got it >> working *first*. Now you're speeding it up. And presumably you got it >> working because you could read it, which means that you (rightly) placed >> readability over correctness. >> >> Because you could read it, you could get it working (while keeping it >> readable). >> >> Now that you've got it working, you're making it fast (while keeping it >> working and readable). >> >> Well done. You have your priorities exactly right. > > Hm. But what about automatic tests? Good question. Here's my answer. Making your automatic tests readable is a higher priority than making them correct. Making them correct is a higher priority than making them fast. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-09 05:28 -0700 |
| Message-ID | <60a17017-4fa3-4367-8b88-02038deb499e@googlegroups.com> |
| In reply to | #64979 |
On Thursday, July 9, 2015 at 11:49:05 AM UTC+1, Morten W. Petersen wrote: > > As for internal representation, choosing a linked-list > structure seems like the way to go. > > However, choosing between recursion and looping is less > obvious, to me at least. > An xml file is best represented as a binary tree with two descendant nodes, child and next. So to count the direct children, go to the child node, and follow along the next pointers until you hit a null. You want to loop over the siblings, or next pointers, and recurse down the children. Typically in XML files, where you have huge numbers of tags, they're all siblings, they're not in massively deep ancestry arrangement.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-09 15:09 +0200 |
| Message-ID | <mnlrnn$7ek$1@speranza.aioe.org> |
| In reply to | #64987 |
On 09.07.2015 14:28, Malcolm McLean wrote: > On Thursday, July 9, 2015 at 11:49:05 AM UTC+1, Morten W. Petersen wrote: >> >> As for internal representation, choosing a linked-list >> structure seems like the way to go. >> >> However, choosing between recursion and looping is less >> obvious, to me at least. >> > An xml file is best represented as a binary tree with two descendant nodes, > child and next. So to count the direct children, go to the child node, > and follow along the next pointers until you hit a null. > > You want to loop over the siblings, or next pointers, and recurse down the > children. Typically in XML files, where you have huge numbers of tags, > they're all siblings, they're not in massively deep ancestry arrangement. Well, when you say it that way, I agree that recursion looks better as it would be simpler code. However, I haven't decided on recursion or looping yet, I'll have to give it some thought. -Morten
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <nospam@nospam.nospam> |
|---|---|
| Date | 2015-07-09 09:25 -0700 |
| Message-ID | <mnm7ak$5cv$1@speranza.aioe.org> |
| In reply to | #64994 |
> "Morten W. Petersen" wrote in message > news:mnlrnn$7ek$1@speranza.aioe.org... [...] > However, I haven't decided on recursion or looping yet, I'll have to > give it some thought. Recursion is fine. Just keep in mind that it can blow the stack if you go too deep! :^o
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-09 18:41 +0200 |
| Message-ID | <mnm85m$7i4$1@speranza.aioe.org> |
| In reply to | #65023 |
On 09.07.2015 18:25, Chris M. Thomasson wrote: >> "Morten W. Petersen" wrote in message >> news:mnlrnn$7ek$1@speranza.aioe.org... > > [...] > >> However, I haven't decided on recursion or looping yet, I'll have to >> give it some thought. > > Recursion is fine. > > Just keep in mind that it can blow the stack if you go too deep! Blow the stack.. is that something that can be exploited, be a security risk? I've seen "smashing the stack" and other phrases used before, is it the same or simply running out of memory? If I manage a stack in a loop then the worst case seems to be just running out of memory. -Morten
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-10 11:52 -0400 |
| Message-ID | <559FEA49.9020007@verizon.net> |
| In reply to | #65028 |
On 07/09/2015 12:41 PM, Morten W. Petersen wrote: > On 09.07.2015 18:25, Chris M. Thomasson wrote: ... >> Recursion is fine. >> >> Just keep in mind that it can blow the stack if you go too deep! > > Blow the stack.. is that something that can be exploited, ... Yes. > ... be a security risk? ... Yes. > ... I've seen "smashing the stack" and other phrases > used before, is it the same ... Yes. > ... or simply running out of memory? Yes. These terms all refer to the fact that each level of recursion will generally use up additional memory, and if the recursion goes too far, it will use up all available memory. The next recursive call will after that happens will have undefined behavior. The standard provides no method for detecting whether this will happen, nor whether it has happened. This is not unique to recursive functions: any function will have undefined behavior if executed when there's insufficient memory available to store it's local objects. However, recursive function calls can make this more likely to happen. > If I manage a stack in a loop then the worst case seems to > be just running out of memory. Unless the recursive function is tail-recursive, it may require the storage of a separate copy of at least some of it's local variables for each level of the recursion. The looping equivalent will need to store the same information in some other way, usually in an array, possibly dynamically allocated. If it's a fixed length local array, it might not be big enough, and if it is big enough, it might exceed the amount of memory available, in which case the looping function will fail for the same reason the recursive one did. If it's allocated dynamically (using malloc()/calloc()/realloc()), the the allocation can fail - but in this case, you can detect the failure and deal with it.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-10 18:44 +0200 |
| Message-ID | <mnosnf$2in$1@speranza.aioe.org> |
| In reply to | #65124 |
On 10.07.2015 17:52, James Kuyper wrote: > On 07/09/2015 12:41 PM, Morten W. Petersen wrote: >> On 09.07.2015 18:25, Chris M. Thomasson wrote: > ... >>> Recursion is fine. >>> >>> Just keep in mind that it can blow the stack if you go too deep! >> >> Blow the stack.. is that something that can be exploited, ... > > Yes. > >> ... be a security risk? ... > > Yes. > >> ... I've seen "smashing the stack" and other phrases >> used before, is it the same ... > > Yes. > >> ... or simply running out of memory? > > Yes. > > These terms all refer to the fact that each level of recursion will > generally use up additional memory, and if the recursion goes too far, > it will use up all available memory. The next recursive call will after > that happens will have undefined behavior. The standard provides no > method for detecting whether this will happen, nor whether it has > happened. This is not unique to recursive functions: any function will > have undefined behavior if executed when there's insufficient memory > available to store it's local objects. However, recursive function calls > can make this more likely to happen. > >> If I manage a stack in a loop then the worst case seems to >> be just running out of memory. > > Unless the recursive function is tail-recursive, it may require the > storage of a separate copy of at least some of it's local variables for > each level of the recursion. The looping equivalent will need to store > the same information in some other way, usually in an array, possibly > dynamically allocated. > If it's a fixed length local array, it might not be big enough, and if > it is big enough, it might exceed the amount of memory available, in > which case the looping function will fail for the same reason the > recursive one did. If it's allocated dynamically (using > malloc()/calloc()/realloc()), the the allocation can fail - but in this > case, you can detect the failure and deal with it. OK. Well then the only way to deal securely with unpredictable input on any platform is to do looping. I like the elegance of recursion, and coming from the Python world it is a secure thing as excessive recursion gives a recognizable RuntimeError exception. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-10 18:52 +0100 |
| Message-ID | <mnp0lh$2gp$1@dont-email.me> |
| In reply to | #65135 |
On 10/07/2015 17:44, Morten W. Petersen wrote: > OK. Well then the only way to deal securely with unpredictable input > on any platform is to do looping. > > I like the elegance of recursion, and coming from the Python world it is > a secure thing as excessive recursion gives a recognizable RuntimeError > exception. You'd think then that Python would take the opportunity to extend the stack as needed, something not viable in C (because everything is crawling with pointers including to objects on the stack). But Python has a ludicrously small stack anyway. In an example like this: def fn(): fn() fn() it crashes out after 1000 to 2000 calls depending on version. I don't know what the overheads are per call, but even assuming a dozen 8-byte entries per call, that means the stack size is just under 200KB or 0.006% of the total RAM on my machine. That is far too small. It means I can't run simple benchmarks such as the Ackermann function without using smaller arguments, which is not then much of a test. (In my own bytecode language it can manage about 70,000 nested calls on a stack size of just over 1MB, still only 0.03% of RAM. In C, various compilers managed 15,000 to 257,000 calls. I think Python is short-changing you...) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-10 20:34 +0200 |
| Message-ID | <mnp353$i2c$1@speranza.aioe.org> |
| In reply to | #65154 |
On 10.07.2015 19:52, Bartc wrote: > On 10/07/2015 17:44, Morten W. Petersen wrote: > >> OK. Well then the only way to deal securely with unpredictable input >> on any platform is to do looping. >> >> I like the elegance of recursion, and coming from the Python world it is >> a secure thing as excessive recursion gives a recognizable RuntimeError >> exception. > > You'd think then that Python would take the opportunity to extend the > stack as needed, something not viable in C (because everything is > crawling with pointers including to objects on the stack). > > But Python has a ludicrously small stack anyway. In an example like this: > > def fn(): > fn() > fn() > > it crashes out after 1000 to 2000 calls depending on version. I don't > know what the overheads are per call, but even assuming a dozen 8-byte > entries per call, that means the stack size is just under 200KB or > 0.006% of the total RAM on my machine. > > That is far too small. It means I can't run simple benchmarks such as > the Ackermann function without using smaller arguments, which is not > then much of a test. > > (In my own bytecode language it can manage about 70,000 nested calls on > a stack size of just over 1MB, still only 0.03% of RAM. > > In C, various compilers managed 15,000 to 257,000 calls. I think Python > is short-changing you...) It is possible to adjust the stack size in Python, also you have Stackless Python: https://wiki.python.org/moin/StacklessPython As for Python and default stack limit, it does the right thing, it raises an exception with usable information. One doesn't exhaust the stack with unpredictable results. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-10 11:50 -0700 |
| Message-ID | <ln615rsv7b.fsf@kst-u.example.com> |
| In reply to | #65124 |
James Kuyper <jameskuyper@verizon.net> writes:
[...]
> These terms all refer to the fact that each level of recursion will
> generally use up additional memory, and if the recursion goes too far,
> it will use up all available memory. The next recursive call will after
> that happens will have undefined behavior. The standard provides no
> method for detecting whether this will happen, nor whether it has
> happened. This is not unique to recursive functions: any function will
> have undefined behavior if executed when there's insufficient memory
> available to store it's local objects. However, recursive function calls
> can make this more likely to happen.
[...]
True. On the other hand, I think most operating systems guard against
stack overflow, so if a function call attempts to allocate more memory
(for local variables and so forth) than is currently available, the
program will terminate.
Are there practical cases where a stack *overflow* can cause problems
other than terminating the program?
--
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 | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-10 20:56 +0200 |
| Message-ID | <mnp4eu$kdj$1@speranza.aioe.org> |
| In reply to | #65171 |
On 10.07.2015 20:50, Keith Thompson wrote: > James Kuyper <jameskuyper@verizon.net> writes: > [...] >> These terms all refer to the fact that each level of recursion will >> generally use up additional memory, and if the recursion goes too far, >> it will use up all available memory. The next recursive call will after >> that happens will have undefined behavior. The standard provides no >> method for detecting whether this will happen, nor whether it has >> happened. This is not unique to recursive functions: any function will >> have undefined behavior if executed when there's insufficient memory >> available to store it's local objects. However, recursive function calls >> can make this more likely to happen. > [...] > > True. On the other hand, I think most operating systems guard against > stack overflow, so if a function call attempts to allocate more memory > (for local variables and so forth) than is currently available, the > program will terminate. > > Are there practical cases where a stack *overflow* can cause problems > other than terminating the program? Well, if you live by a language, you die by it. :) By the way I understand it, the C language standard doesn't define what happens when the stack is overflowed, and anything could in theory happen. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-10 13:30 -0700 |
| Message-ID | <lnlhenrc0c.fsf@kst-u.example.com> |
| In reply to | #65171 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Keith Thompson <kst-u@mib.org> writes:
>>Are there practical cases where a stack *overflow* can cause problems
>>other than terminating the program?
>
> »stack overflow does not necessarily have to result
> in a crash with a nice error message, but might also
> overwrite non-stack parts of the memory (possibly
> putting the address of virus code there)«
>
> n1637
n1637, http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1637.pdf, is
titled "Subtleties of the ANSI/ISO C standard".
I'm aware that the the behavior of stack overflow is not defined by the
C standard. That passage suggests that it can behave in ways other than
terminating the program, but it offers no concrete examples.
My question is, how likely is it *in practice* for a stack overflow to
fail to be detected, and to result in something other than program
termination?
--
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 | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-07-11 10:51 -0700 |
| Message-ID | <MPG.300af76c7b9b7b684d@news.eternal-september.org> |
| In reply to | #65184 |
Keith Thompson wrote:
> Stefan Ram writes:
> > Keith Thompson writes:
> >>Are there practical cases where a stack *overflow* can cause problems
> >>other than terminating the program?
> >
> > »stack overflow does not necessarily have to result
> > in a crash with a nice error message, but might also
> > overwrite non-stack parts of the memory (possibly
> > putting the address of virus code there)«
> >
> > n1637
>
> n1637, http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1637.pdf, is
> titled "Subtleties of the ANSI/ISO C standard".
>
> I'm aware that the the behavior of stack overflow is not defined by the
> C standard. That passage suggests that it can behave in ways other than
> terminating the program, but it offers no concrete examples.
>
> My question is, how likely is it *in practice* for a stack overflow to
> fail to be detected, and to result in something other than program
> termination?
Consider this:
char d;
void f(unsigned long long);
int main()
{
char s;
// The following line is undefined behavior, of course, but
// it is simply an example of a way on some typical systems
// to determine a value for n that is likely to cause the
// behavior I want to show.
unsigned long long n = &s - &d;
f(n);
}
void f(unsigned long long n)
{
// This function almost certainly has undefined behavior,
// given the value of n passed by main.
// However, I think it is likely on typical implementations
// overwrite accessible memory somewhere in the vicinity of
// the to variable 'd'.
char a[n];
volatile char d1 = 0;
}
The likelyhood of a scenario like this occurring in practice depends on
the sizes of the data and stack segments, and the distance between them,
relative to the address space. With a program that uses a large
percentage of the available address space, and allocates large objects
on the stack, it seems to me that it might not be too unlikely.
With a program that uses recursion with relatively small stack frames, I
agree with your expectation that it is quite unlikely for the stack to
overflow into accessible data space without it being caught first.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-11 16:07 -0700 |
| Message-ID | <lna8v2pa2t.fsf@kst-u.example.com> |
| In reply to | #65318 |
Philip Lantz <prl@canterey.us> writes:
> Keith Thompson wrote:
[...]
>> I'm aware that the the behavior of stack overflow is not defined by the
>> C standard. That passage suggests that it can behave in ways other than
>> terminating the program, but it offers no concrete examples.
>>
>> My question is, how likely is it *in practice* for a stack overflow to
>> fail to be detected, and to result in something other than program
>> termination?
>
> Consider this:
>
[example snipped]
Your example, I think, can be reduced to a function that defines a very
large VLA, perhaps with a size chosen to maximize the likelihood of
something bad happening. It's a concrete example of code that *might*
have such a problem, but not a concrete example of a problemm occurring,
which is what I was asking about.
For real-world compilers, would such a function actually do something
other than (a) successfully allocating the VLA and behaving correctly or
(b) crashing/terminating on the function call?
And if so, do such problems occur in the absence of VLAs?
To be clear, this is not a rhetorical question; I don't know the answer.
[...]
--
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 | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-07-12 00:20 -0700 |
| Message-ID | <MPG.300bb517badcbd764e@news.eternal-september.org> |
| In reply to | #65363 |
Keith Thompson wrote: > Philip Lantz writes: > > Keith Thompson wrote: > [...] > >> I'm aware that the the behavior of stack overflow is not defined by the > >> C standard. That passage suggests that it can behave in ways other than > >> terminating the program, but it offers no concrete examples. > >> > >> My question is, how likely is it *in practice* for a stack overflow to > >> fail to be detected, and to result in something other than program > >> termination? > > > > Consider this: > > > [example snipped] > > Your example, I think, can be reduced to a function that defines a very > large VLA, perhaps with a size chosen to maximize the likelihood of > something bad happening. It's a concrete example of code that *might* > have such a problem, but not a concrete example of a problemm occurring, > which is what I was asking about. > > For real-world compilers, would such a function actually do something > other than (a) successfully allocating the VLA and behaving correctly or > (b) crashing/terminating on the function call? > > And if so, do such problems occur in the absence of VLAs? > > To be clear, this is not a rhetorical question; I don't know the answer. The fact that it is a VLA doesn't matter; the relevant part is that the array is large enough to push the stack all the way into the part of the address space where other data is stored. Computing the size and using a VLA the way I did was just to show what a suitable size would be for the array. Yes, I guarantee that using real-world compilers, it would do something other than your (a) or (b)--it would write over some other data. GCC, for instance, in the modes that I'm most familiar with, will generate code that behaves this way. There are no stack checks generated in the code, and the operating system doesn't configure the processor to distinguish between stack accesses and other data accesses to the same address, so it wouldn't trap on the improper access. I have actually had bugs caused by this (without using VLAs), but it has been a while, because I put more space between my stacks and my data these days--that doesn't prevent the problem completely, but it makes it far less likely given the sizes of stack frames that I typically use.
[toc] | [prev] | [next] | [standalone]
| From | gordonb.j93iw@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2015-07-11 21:26 -0500 |
| Message-ID | <dYOdnUk-WIncTTzInZ2dnUU7-I2dnZ2d@posted.internetamerica> |
| In reply to | #65171 |
A particular (and now very old) implementation of Xenix had a fixed stack, specified at link time. The memory management hardware was too simple to permit automatically growing the stack. The initial version of find(1), with no modifications for a fixed-stack machine yet, had a fixed stack sufficient for directories about 6 levels deep. After that point, the output of find started spewing binary jibberish with text mixed in. The buffers for reading in directory contents, which were auto variables, had overlapped the stdout buffer when the stack overflowed. Depending on the depth of the directory tree, say, about 6-8, you would get garbage output but not terminate the program. More than that, and the program would terminate. Fix: make the fixed stack bigger for this program, at least big enough to handle the filesystem as distributed (which was about 9, I think). Beyond about 17 levels of directories deep, it would run out of file descriptors regardless of how much stack it had. There are better ways to write this for a fixed-stack machine, such as caching file descriptors and using malloc() for buffers. Sometimes stack overflow does not result in crashing the program.
[toc] | [prev] | [next] | [standalone]
Page 2 of 15 — ← Prev page 1 [2] 3 4 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web