Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #3254 > unrolled thread
| Started by | boltar2003@boltar.world |
|---|---|
| First post | 2011-05-05 09:37 +0000 |
| Last post | 2011-05-11 03:43 -0700 |
| Articles | 20 on this page of 241 — 42 participants |
Back to article view | Back to comp.lang.c
Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 09:37 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? China Blue Veins <chine.bleu@yahoo.com> - 2011-05-05 02:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 09:58 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? China Blue Veins <chine.bleu@yahoo.com> - 2011-05-05 04:47 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-07 23:22 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-05 11:58 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-06 03:27 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-06 00:03 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 09:18 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-06 02:56 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-05 12:24 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Lowell Gilbert <lgusenet@be-well.ilk.org> - 2011-05-05 15:40 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:18 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-05 21:17 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-05-05 18:45 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:44 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 09:58 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Richard Kettlewell <rjk@greenend.org.uk> - 2011-05-06 11:11 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 10:16 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Richard Kettlewell <rjk@greenend.org.uk> - 2011-05-06 11:28 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:34 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-06 15:09 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 13:03 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 09:01 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 14:32 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-07 16:27 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 16:43 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-08 06:19 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-08 17:18 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-08 09:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-09 11:34 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-11 03:48 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-11 10:51 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-11 08:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-11 15:47 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-12 15:05 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-07 16:23 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 18:12 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 10:30 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:01 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 12:37 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 18:15 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-08 15:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 09:32 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-08 10:46 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 21:49 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 09:59 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 20:24 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-07 15:04 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 15:15 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 19:57 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 20:26 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 21:06 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-07 23:27 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-05 20:07 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-06 02:53 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 19:27 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-18 19:54 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-06 10:07 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 07:08 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 08:18 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Marco Parrone <marco@marcoparrone.com> - 2011-05-06 17:32 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 08:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 21:46 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 00:28 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-07 09:01 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 06:35 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-07 22:52 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 01:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-08 09:37 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-08 03:21 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Willem <willem@toad.stack.nl> - 2011-05-08 10:44 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 07:23 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-09 11:30 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-09 13:36 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-09 07:08 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 07:38 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 07:44 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-09 21:44 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 13:59 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 14:19 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 15:05 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 10:20 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 19:04 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-14 11:13 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-09 15:40 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-09 23:44 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 11:06 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-10 00:11 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 11:17 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-10 07:10 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 12:24 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-05-10 13:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:48 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:54 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-05-12 05:56 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 00:44 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 19:36 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 23:21 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 07:08 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-11 11:48 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 10:03 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 10:12 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 21:23 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-12 09:45 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:00 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:35 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-12 06:51 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-12 14:36 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-12 22:57 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-11 11:47 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:07 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-10 21:16 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-11 02:40 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 09:39 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:42 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-15 00:23 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? pacman@kosh.dhis.org (Alan Curry) - 2011-05-14 22:30 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-16 04:19 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-16 08:40 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-16 17:53 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-16 21:39 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 09:12 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-17 10:20 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-17 15:00 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? pacman@kosh.dhis.org (Alan Curry) - 2011-05-17 20:28 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 14:45 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 14:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-17 16:23 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-17 23:06 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-18 01:02 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-18 01:29 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-18 04:03 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Pfaff <blp@cs.stanford.edu> - 2011-05-17 16:47 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 17:21 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-23 21:57 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-23 21:57 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-23 17:45 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-24 11:43 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-24 10:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Sherm Pendley <sherm.pendley@gmail.com> - 2011-05-11 11:11 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:48 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-09 16:22 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 21:25 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Seebs <usenet-nospam@seebs.net> - 2011-05-10 17:28 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 17:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 12:20 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 03:53 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 20:18 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 04:42 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-10 09:12 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-10 03:21 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-10 10:53 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-10 08:12 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 09:39 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 12:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-11 08:12 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-10 15:16 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 19:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 07:41 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-11 12:45 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-10 07:50 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-10 11:04 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-08 09:27 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 08:04 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-08 22:50 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 00:18 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:49 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-08 20:05 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-08 13:44 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 00:22 -0700
Re: Avoiding recursive stack overflow in C? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-15 17:05 +0100
Re: Avoiding recursive stack overflow in C? James Kuyper <jameskuyper@verizon.net> - 2011-05-15 14:07 -0400
Re: Avoiding recursive stack overflow in C? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-15 22:49 +0100
Re: Avoiding recursive stack overflow in C? James Kuyper <jameskuyper@verizon.net> - 2011-05-15 21:08 -0400
Re: Avoiding recursive stack overflow in C? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-16 11:10 +0100
Re: Avoiding recursive stack overflow in C? Ilya Zakharevich <nospam-abuse@ilyaz.org> - 2011-05-16 08:04 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-05-07 19:11 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 07:17 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-05-08 10:16 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-09 09:03 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 08:59 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 03:01 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 07:13 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 09:02 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-06 15:41 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 02:53 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-07 16:17 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 10:08 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:20 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 14:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-07 14:31 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 22:49 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-07 17:22 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 10:24 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-07 17:32 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 11:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 10:57 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 08:09 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:41 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Shao Miller <sha0.miller@gmail.com> - 2011-05-07 21:35 -0500
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-08 23:31 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 00:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-09 08:39 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-09 09:03 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 10:06 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-09 17:52 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Herbert Rosenau" <os2guy@pc-rosenau.de> - 2011-05-10 11:20 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-08 17:59 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-09 09:01 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:41 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 12:48 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 11:01 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? gazelle@shell.xmission.com (Kenny McCormack) - 2011-05-08 13:10 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:51 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-08 22:21 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? gazelle@shell.xmission.com (Kenny McCormack) - 2011-06-04 12:54 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-06-04 12:59 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-06-07 06:30 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-06-10 21:56 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 13:53 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 15:16 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-07 23:42 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 19:37 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 07:17 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 09:24 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-08 10:36 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 13:29 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-08 00:28 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 23:06 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-08 07:30 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-08 15:51 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 13:33 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-14 11:08 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-14 15:53 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-10 22:14 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 11:08 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 08:15 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-11 03:43 -0700
Page 2 of 13 — ← Prev page 1 [2] 3 4 … 13 Next page →
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-06 02:34 -0700 |
| Message-ID | <3bd2f399-754b-40dc-90da-b2ee35184281@k25g2000yqf.googlegroups.com> |
| In reply to | #3322 |
On 5 mei, 22:17, Ben Bacarisse <ben.use...@bsb.me.uk> wrote: > "Kleuskes & Moos" <kleu...@xs4all.nl> writes: > > > On May 5, 11:37 am, boltar2...@boltar.world wrote: > >> If a program recurses too deeply there's always a chance that it could > >> run out of stack space and die with a SIGSEGV. Is there any API that can > >> tell you how much stack space is left or some other method to prevent this > >> in C/C++? I realise I could catch the signal but thats a pretty damn ugly > >> way to do it. > > > The only proper way to avoid stack-overflows is to prevent it from > > happening in the first place. If at all possible (and frequently it > > is) avoid recursion, if it's unavoidable, as it sometimes is, make > > sure your design prevents those situations from arising in the first > > place. > > I find this answer interesting, mainly because I think is suggests a > very different view about programming. I would not try to avoid > recursion "if at all possible". In general I consider that it is up to > the system to provide the resources needed by a program and this > includes stack for a reasonable amount of recursion. These resources > can run out of course, and the stack is special in that few languages > provide any way to handle its exhaustion elegantly, but that does not > seem enough reason to design out all recursion. If you compare recursive to equivalent non-recursive algorithms, i think you will find recursion is usually slower and demands (much) more resources. So as a rule of thumb, don't recurse, unless you have to. And yes, i do have a background in embedded systems, where these considerations are more important than on modern PC's. > There are special cases: some environments are severely resource limited > but there's no indication that the OP is using such a system and, > anyway, I don't think you can make general rules from specific situations. well... It's bread and butter for the science guys and the practice is called "inference". Nevertheless, it's easy to show that recursive algorithms are outperformed my equivalent non-recursive ones. The saving grace of recursion is that recursive implementations are usually easier to understand. If it weren't for that, i'd ban the practice outright. > > Trying to solve a design problem by imposing artificial limitations > > seems a bad idea. > > Isn't this what you are doing? Isn't the ban on recursion not an > artificial limitation? Nope. It follows from the design of processors and a wish to avoid unneccesary overhead (passing arguments, stack-frame maintenance, pushing and popping return adresses) and that's without even considering any effect a call may have on things like branch- prediction, instruction pipe-lines and such. A 'call' instruction is (relative to a branch) quite expensive and prevents some optimisations like loop-unrolling. So no, that's not an artificial limitation, but a design consideration.
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-05-06 15:09 -0700 |
| Message-ID | <rubrum-55B22D.15093606052011@news.albasani.net> |
| In reply to | #3365 |
In article <3bd2f399-754b-40dc-90da-b2ee35184281@k25g2000yqf.googlegroups.com>, "Kleuskes & Moos" <kleuske@xs4all.nl> wrote: > The saving grace of recursion is that recursive implementations are > usually easier to understand. If it weren't for that, i'd ban the > practice outright. First it's recursive functions, then world domination. You are on a slippery slope. -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Dr Nick <3-nospam@temporary-address.org.uk> |
|---|---|
| Date | 2011-05-07 13:03 +0100 |
| Message-ID | <87ei4ara3g.fsf@temporary-address.org.uk> |
| In reply to | #3365 |
"Kleuskes & Moos" <kleuske@xs4all.nl> writes: > The saving grace of recursion is that recursive implementations are > usually easier to understand. If it weren't for that, i'd ban the > practice outright. I'd be intrigued to see a non-recursive implementation of the code of a library for creating, reading into memory and printing JSON data structures as an obvious example. -- Online waterways route planner | http://canalplan.eu Plan trips, see photos, check facilities | http://canalplan.org.uk
[toc] | [prev] | [next] | [standalone]
| From | Barry Margolin <barmar@alum.mit.edu> |
|---|---|
| Date | 2011-05-07 09:01 -0400 |
| Message-ID | <barmar-ED6D77.09010807052011@reserved-multicast-range-not-delegated.example.com> |
| In reply to | #3413 |
In article <87ei4ara3g.fsf@temporary-address.org.uk>, Dr Nick <3-nospam@temporary-address.org.uk> wrote: > "Kleuskes & Moos" <kleuske@xs4all.nl> writes: > > > The saving grace of recursion is that recursive implementations are > > usually easier to understand. If it weren't for that, i'd ban the > > practice outright. > > I'd be intrigued to see a non-recursive implementation of the code of a > library for creating, reading into memory and printing JSON data > structures as an obvious example. Recursive algorithms for applications like this are generally not a problem. The recursion depth is proportional to the level of nesting of the data structures, which is usually in the single digits, and practically never more than a couple dozen. This is negligible on any non-toy implementation. Where recursion becomes an issue is when you use it for every element of a sequential data structure. For instance, if a parser's algorithmic structure were something like: read_first_token process_token recurse(rest of document) it would probably run into a stack limit on most implementations when processing any real input. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
[toc] | [prev] | [next] | [standalone]
| From | Dr Nick <3-nospam@temporary-address.org.uk> |
|---|---|
| Date | 2011-05-07 14:32 +0100 |
| Message-ID | <87vcxmprer.fsf@temporary-address.org.uk> |
| In reply to | #3414 |
Barry Margolin <barmar@alum.mit.edu> writes: > In article <87ei4ara3g.fsf@temporary-address.org.uk>, > Dr Nick <3-nospam@temporary-address.org.uk> wrote: > >> "Kleuskes & Moos" <kleuske@xs4all.nl> writes: >> >> > The saving grace of recursion is that recursive implementations are >> > usually easier to understand. If it weren't for that, i'd ban the >> > practice outright. >> >> I'd be intrigued to see a non-recursive implementation of the code of a >> library for creating, reading into memory and printing JSON data >> structures as an obvious example. > > Recursive algorithms for applications like this are generally not a > problem. The recursion depth is proportional to the level of nesting of > the data structures, which is usually in the single digits, and > practically never more than a couple dozen. This is negligible on any > non-toy implementation. I know. It's not me who is arguing that recursion is evil and in an ideal world ought to be banned! > Where recursion becomes an issue is when you use it for every element of > a sequential data structure. For instance, if a parser's algorithmic > structure were something like: > > read_first_token > process_token > recurse(rest of document) > > it would probably run into a stack limit on most implementations when > processing any real input. Most implementations where the compiler doesn't optimise tail recursion away, anyway. -- Online waterways route planner | http://canalplan.eu Plan trips, see photos, check facilities | http://canalplan.org.uk
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Date | 2011-05-07 16:27 +0100 |
| Message-ID | <87hb96ledz.fsf@sapphire.mobileactivedefense.com> |
| In reply to | #3416 |
Dr Nick <3-nospam@temporary-address.org.uk> writes: > Barry Margolin <barmar@alum.mit.edu> writes: [...] >> Where recursion becomes an issue is when you use it for every element of >> a sequential data structure. For instance, if a parser's algorithmic >> structure were something like: >> >> read_first_token >> process_token >> recurse(rest of document) >> >> it would probably run into a stack limit on most implementations when >> processing any real input. > > Most implementations where the compiler doesn't optimise tail recursion > away, anyway. Eh ... you do understand that 'compiler detects that programmer was a crackpot and works around that automatically' implies that recursion is probematic, do you?
[toc] | [prev] | [next] | [standalone]
| From | Dr Nick <3-nospam@temporary-address.org.uk> |
|---|---|
| Date | 2011-05-07 16:43 +0100 |
| Message-ID | <878vuipldb.fsf@temporary-address.org.uk> |
| In reply to | #3419 |
Rainer Weikusat <rweikusat@mssgmbh.com> writes: > Dr Nick <3-nospam@temporary-address.org.uk> writes: >> Barry Margolin <barmar@alum.mit.edu> writes: > > [...] > >>> Where recursion becomes an issue is when you use it for every element of >>> a sequential data structure. For instance, if a parser's algorithmic >>> structure were something like: >>> >>> read_first_token >>> process_token >>> recurse(rest of document) >>> >>> it would probably run into a stack limit on most implementations when >>> processing any real input. >> >> Most implementations where the compiler doesn't optimise tail recursion >> away, anyway. > > Eh ... you do understand that 'compiler detects that programmer was a > crackpot and works around that automatically' implies that recursion > is probematic, do you? I don't even understand the question. -- Online waterways route planner | http://canalplan.eu Plan trips, see photos, check facilities | http://canalplan.org.uk
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2011-05-08 06:19 +0000 |
| Message-ID | <slrniscdej.gtj.grahn+nntp@frailea.sa.invalid> |
| In reply to | #3419 |
On Sat, 2011-05-07, Rainer Weikusat wrote: > Dr Nick <3-nospam@temporary-address.org.uk> writes: >> Barry Margolin <barmar@alum.mit.edu> writes: > > [...] > >>> Where recursion becomes an issue is when you use it for every element of >>> a sequential data structure. For instance, if a parser's algorithmic >>> structure were something like: >>> >>> read_first_token >>> process_token >>> recurse(rest of document) >>> >>> it would probably run into a stack limit on most implementations when >>> processing any real input. >> >> Most implementations where the compiler doesn't optimise tail recursion >> away, anyway. > > Eh ... you do understand that 'compiler detects that programmer was a > crackpot and works around that automatically' implies that recursion > is probematic, do you? It's the other way around -- recursion is less problematic if it can be compiled into something which runs efficiently. Compilers and interpreters for functional languages (Haskell, ML, Lisp ...) where recursion replaces loops, have been doing this for decades. (Not that I use recursion a lot myself.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Date | 2011-05-08 17:18 +0100 |
| Message-ID | <877ha1b1y6.fsf@sapphire.mobileactivedefense.com> |
| In reply to | #3492 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > On Sat, 2011-05-07, Rainer Weikusat wrote: >> Dr Nick <3-nospam@temporary-address.org.uk> writes: >>> Barry Margolin <barmar@alum.mit.edu> writes: >> >> [...] >> >>>> Where recursion becomes an issue is when you use it for every element of >>>> a sequential data structure. For instance, if a parser's algorithmic >>>> structure were something like: >>>> >>>> read_first_token >>>> process_token >>>> recurse(rest of document) >>>> >>>> it would probably run into a stack limit on most implementations when >>>> processing any real input. >>> >>> Most implementations where the compiler doesn't optimise tail recursion >>> away, anyway. >> >> Eh ... you do understand that 'compiler detects that programmer was a >> crackpot and works around that automatically' implies that recursion >> is probematic, do you? > > It's the other way around -- recursion is less problematic if it can > be compiled into something which runs efficiently. For obvious reasons, recursion cannot cause anything detrimental if it is automaticlly removed. But if there wasn't a problem to begin with, there would be no reason for this automatic removal. 'Tail recursion' is essentially something which shouldn't be used because the recursion doesn't really help with anything in this case: The fact that it is 'at the tail' implies that the current processing step can be completed before the next step and the most 'natural' represention of that is a processing loop. Recursion is useful when the current processing step cannot be completed before the result of the next processing step is known, IOW, when some algorithm must first move to the tail of something and then process data backwards from there, utilizing the 'state information' that's stored in the environments of the stacked subroutine invocations. In an imperative language, it is essentially a trick which can be used to cause the compiler generate the necessary state management code (at the expense of a certain runtime overhead) automatically instead of writing it by hand. > Compilers and interpreters for functional languages (Haskell, ML, > Lisp ...) where recursion replaces loops, have been doing this for > decades. People who like express simple things in weird, complicated ways have (for decades, presumably) relied on computer program to silently undo the weirdness in order to maintain the illusion that what they are doing actually makes any sense ...
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-05-08 09:58 -0700 |
| Message-ID | <3b09773c-1bb0-465b-956f-36cc3980e8f3@g12g2000yqd.googlegroups.com> |
| In reply to | #3536 |
On May 8, 7:18 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote: > Jorgen Grahn <grahn+n...@snipabacken.se> writes: > > > Compilers and interpreters for functional languages (Haskell, ML, > > Lisp ...) where recursion replaces loops, have been doing this for > > decades. > > People who like express simple things in weird, complicated ways have > (for decades, presumably) relied on computer program to silently > undo the weirdness in order to maintain the illusion that what they > are doing actually makes any sense ... > The Lisp family of languages are fundamentally different to the C family. I must admit I've never been able to get anything useful out of them, but they I've only played about with them in my spare time.
[toc] | [prev] | [next] | [standalone]
| From | boltar2003@boltar.world |
|---|---|
| Date | 2011-05-09 11:34 +0000 |
| Message-ID | <iq8jgp$2rm$1@speranza.aioe.org> |
| In reply to | #3536 |
On Sun, 08 May 2011 17:18:41 +0100 Rainer Weikusat <rweikusat@mssgmbh.com> wrote: >the stacked subroutine invocations. In an imperative language, it is >essentially a trick which can be used to cause the compiler >generate the necessary state management code (at the expense of a >certain runtime overhead) automatically instead of writing it by >hand. And its a very useful trick. Unrolling a simple recursive function that just calls itself is fairly trivial, but if you have recursion such as: A() -> B() -> C() -> A() .... then unrolling that into an iterative loop will give you grey hairs to rival gandalf if the code is sufficiently complex. Not to mention that fact that most likely all the code from those 3 functions will end up in one big lump of code in a single function. And yes - I have seen the above used in language interpreters. eg: evalUserFunction() evalExpression() evalMathsExpression() evalUserFunction() etc B2003
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-05-11 03:48 -0700 |
| Message-ID | <173b59eb-e534-466c-a471-2ca8262af649@p13g2000yqh.googlegroups.com> |
| In reply to | #3419 |
On May 7, 4:27 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote: > Dr Nick <3-nos...@temporary-address.org.uk> writes: > > Barry Margolin <bar...@alum.mit.edu> writes: > > [...] > > >> Where recursion becomes an issue is when you use it for every element of > >> a sequential data structure. For instance, if a parser's algorithmic > >> structure were something like: > > >> read_first_token > >> process_token > >> recurse(rest of document) > > >> it would probably run into a stack limit on most implementations when > >> processing any real input. > > > Most implementations where the compiler doesn't optimise tail recursion > > away, anyway. > > Eh ... you do understand that 'compiler detects that programmer was a > crackpot and works around that automatically' implies that recursion > is probematic, do you? some languages don't provide any looping form except recursion.
[toc] | [prev] | [next] | [standalone]
| From | boltar2003@boltar.world |
|---|---|
| Date | 2011-05-11 10:51 +0000 |
| Message-ID | <iqdpns$46s$1@speranza.aioe.org> |
| In reply to | #3734 |
On Wed, 11 May 2011 03:48:30 -0700 (PDT) Nick Keighley <nick_keighley_nospam@hotmail.com> wrote: >some languages don't provide any looping form except recursion. Usually languages that seem like a good idea when sitting at the top of an ivory tower smoking some weed. B2003
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-11 08:11 -0700 |
| Message-ID | <lnoc39l1ah.fsf@nuthaus.mib.org> |
| In reply to | #3735 |
boltar2003@boltar.world writes:
> On Wed, 11 May 2011 03:48:30 -0700 (PDT)
> Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
>>some languages don't provide any looping form except recursion.
>
> Usually languages that seem like a good idea when sitting at the top of
> an ivory tower smoking some weed.
And sometimes they seem like a good idea to people who get actual work
done using them.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | boltar2003@boltar.world |
|---|---|
| Date | 2011-05-11 15:47 +0000 |
| Message-ID | <iqeb3f$j5d$1@speranza.aioe.org> |
| In reply to | #3758 |
On Wed, 11 May 2011 08:11:50 -0700 Keith Thompson <kst-u@mib.org> wrote: >boltar2003@boltar.world writes: >> On Wed, 11 May 2011 03:48:30 -0700 (PDT) >> Nick Keighley <nick_keighley_nospam@hotmail.com> wrote: >>>some languages don't provide any looping form except recursion. >> >> Usually languages that seem like a good idea when sitting at the top of >> an ivory tower smoking some weed. > >And sometimes they seem like a good idea to people who get actual work >done using them. There are zero good reasons good reasons for having a language with no looping constructs other than recursion and no state. A language like that merely satisfies the quirky asthetics of certain mathematically minded academics and it serves no more purpose than if it had looping constructs included - its just assumed to be somehow more pure and therefor more worthy as a language. Which is drivel. Functional programming is generally thought to be a nice idea by people who never have to write programs for live enviroments that work on real machines in real time with real limits on memory and CPU. And yes I am aware of Erlang and no I wouldn't piss on it if it was on fire whether ericsson still use it in their switches or not. B2003
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-05-12 15:05 -0700 |
| Message-ID | <5f2d1277-cd7e-447e-87da-b3ad97ad3a56@j28g2000vbp.googlegroups.com> |
| In reply to | #3762 |
On May 11, 4:47 pm, boltar2...@boltar.world wrote: > On Wed, 11 May 2011 08:11:50 -0700 > > Keith Thompson <ks...@mib.org> wrote: > >boltar2...@boltar.world writes: > >> On Wed, 11 May 2011 03:48:30 -0700 (PDT) > >> Nick Keighley <nick_keighley_nos...@hotmail.com> wrote: > >>>some languages don't provide any looping form except recursion. > > >> Usually languages that seem like a good idea when sitting at the top of > >> an ivory tower smoking some weed. > > >And sometimes they seem like a good idea to people who get actual work > >done using them. > > There are zero good reasons good reasons for having a language with no > looping constructs other than recursion and no state. A language like that > merely satisfies the quirky asthetics of certain mathematically minded > academics and it serves no more purpose than if it had looping constructs > included - its just assumed to be somehow more pure and therefor more worthy > as a language. Which is drivel. > > Functional programming is generally thought to be a nice idea by people who > never have to write programs for live enviroments that work on real machines > in real time with real limits on memory and CPU. And yes I am aware of Erlang > and no I wouldn't piss on it if it was on fire whether ericsson still use it > in their switches or not. ah, reasoned discussion
[toc] | [prev] | [next] | [standalone]
| From | boltar2003@boltar.world |
|---|---|
| Date | 2011-05-07 16:23 +0000 |
| Message-ID | <iq3rlr$6gp$1@speranza.aioe.org> |
| In reply to | #3414 |
On Sat, 07 May 2011 09:01:15 -0400
Barry Margolin <barmar@alum.mit.edu> wrote:
>Where recursion becomes an issue is when you use it for every element of
>a sequential data structure. For instance, if a parser's algorithmic
>structure were something like:
>
>read_first_token
>process_token
>recurse(rest of document)
>
>it would probably run into a stack limit on most implementations when
>processing any real input.
Some language interpreters internally recurse along with any recursing in the
program they're interpreting. Awk is a good example and will happily crash
with a SIGSEGV due to recursion. eg:
BEGIN {
blah()
}
function blah()
{
blah()
}
B2003
[toc] | [prev] | [next] | [standalone]
| From | Barry Margolin <barmar@alum.mit.edu> |
|---|---|
| Date | 2011-05-07 18:12 -0400 |
| Message-ID | <barmar-BD51B6.18122807052011@62-183-169-81.bb.dnainternet.fi> |
| In reply to | #3423 |
In article <iq3rlr$6gp$1@speranza.aioe.org>, boltar2003@boltar.world
wrote:
> On Sat, 07 May 2011 09:01:15 -0400
> Barry Margolin <barmar@alum.mit.edu> wrote:
> >Where recursion becomes an issue is when you use it for every element of
> >a sequential data structure. For instance, if a parser's algorithmic
> >structure were something like:
> >
> >read_first_token
> >process_token
> >recurse(rest of document)
> >
> >it would probably run into a stack limit on most implementations when
> >processing any real input.
>
> Some language interpreters internally recurse along with any recursing in the
> program they're interpreting. Awk is a good example and will happily crash
> with a SIGSEGV due to recursion. eg:
>
> BEGIN {
> blah()
> }
>
> function blah()
> {
> blah()
> }
>
>
> B2003
That's not recursing in the parser, that's recursing in the interpreter.
It't not surprising that a script with infinite recursion might cause
infinite recursion in the interpreter.
And even if the interpreter didn't recurse when the script does, it
still has to keep the script's stack somewhere. So if it doesn't blow
out the interpreter's stack, it will run out of VM eventually.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-07 10:30 -0700 |
| Message-ID | <614e7c8f-8298-45d1-8f10-c940f614af31@g12g2000yqd.googlegroups.com> |
| In reply to | #3414 |
On May 7, 3:01 pm, Barry Margolin <bar...@alum.mit.edu> wrote: <snip> > read_first_token > process_token > recurse(rest of document) Where i work, code like that is likely to get you fired on the spot.
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2011-05-07 20:01 +0100 |
| Message-ID | <pan.2011.05.07.19.01.27.672000@nowhere.com> |
| In reply to | #3434 |
On Sat, 07 May 2011 10:30:04 -0700, Kleuskes & Moos wrote: >> read_first_token >> process_token >> recurse(rest of document) > > Where i work, code like that is likely to get you fired on the spot. OTOH, in functional languages (ML, Haskell, etc) it's the correct approach. Iteration is just tail recursion; it's the compiler's job to optimise it. Such languages don't have iteration primitives, and any standard functions for performing iteration are written using recursion.
[toc] | [prev] | [next] | [standalone]
Page 2 of 13 — ← Prev page 1 [2] 3 4 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web