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 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-05-08 07:17 +0200 |
| Message-ID | <4dc62725$0$38641$4fafbaef@reader1.news.tin.it> |
| In reply to | #3421 |
"Niklas Holsti" <niklas.holsti@tidorum.invalid> ha scritto nel messaggio
news:92l9a8F413U1@mid.individual.net...
> James Kuyper wrote:
>
>> I'm not aware of any other language that provides a mechanism for
>> avoiding or dealing with this problem, either. There might be one, but I
>> don't know it's name.
>
> Stack overflow in the Ada language is expected to raise the Storage_Error
> exception, which can be caught and handled in the Ada program itself. However,
> this can depend on compilation options, for example the GNU Ada compiler gnat
> needs the option -fstack-check for Storage_Error to work in this way,
> otherwise stack overflow just signals a SIGSEGV.
for me it is the same recursive function that has to return error; as any other
visible and invisible error; something like
int recursivefunction(int* result, int* value)
{int a, b, c; // esp-=1024 esp<
if(GetCurrentStackPointerValue()<StackLimit-1000)
return -1
....
return recursivefunction(result, value)
}
> You can also do the recursive computation in a dedicated thread (an Ada
> "task") and control the amount of stack space allocated to the thread by means
> of pragma Storage_Size, with a static constant value or a dynamically
> calculated value, when the thread is created.
ok if understand well
> If you expect that Storage_Error may be raised by stack overflow during
> recursion, it is a good idea to put the handler for Storage_Error outside the
> recursion, so that the recursion unwinds and stack space is again available
> before the handler is entered.
>
> --
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
> . @ .
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2011-05-08 10:16 +0300 |
| Message-ID | <92muaiFkflU1@mid.individual.net> |
| In reply to | #3485 |
io_x wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> ha scritto nel messaggio
> news:92l9a8F413U1@mid.individual.net...
>> James Kuyper wrote:
>>
>>> I'm not aware of any other language that provides a mechanism for
>>> avoiding or dealing with this problem, either. There might be one, but I
>>> don't know it's name.
>> Stack overflow in the Ada language is expected to raise the Storage_Error
>> exception, which can be caught and handled in the Ada program itself. However,
>> this can depend on compilation options, for example the GNU Ada compiler gnat
>> needs the option -fstack-check for Storage_Error to work in this way,
>> otherwise stack overflow just signals a SIGSEGV.
>
> for me it is the same recursive function that has to return error; as any other
> visible and invisible error; something like
>
> int recursivefunction(int* result, int* value)
> {int a, b, c; // esp-=1024 esp<
> if(GetCurrentStackPointerValue()<StackLimit-1000)
> return -1
> ....
> return recursivefunction(result, value)
> }
Can be done in Ada:
function recursivefunction (result, value : access integer)
return integer
is
<declarations...>
begin
<statements...>
return recursivefunction (result, value);
exception
when Storage_Error => return -1;
end recursivefunction;
In the function above, if any of the <statements> or the recursive call
causes stack overflow, the Storage_Error handler is entered and the call
returns -1. If the <declarations> cause stack overflow, the handler for
the present call of recursivefunction is bypassed and the Storage_Error
exception is propagated to the outer call level, entering the handler at
that level.
With the gnat Ada compiler it seems that stack overflow at any point in
the function (declarations or statements) abandons the present call and
propagates Storage_Error to the outer call. So if the stack overflow is
detected on recursion level 9999 it is handled on level 9998. But that
should not matter much.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-05-09 09:03 +0200 |
| Message-ID | <4dc79192$0$18249$4fafbaef@reader2.news.tin.it> |
| In reply to | #3503 |
"Niklas Holsti" <niklas.holsti@tidorum.invalid> ha scritto nel messaggio
news:92muaiFkflU1@mid.individual.net...
> io_x wrote:
>> "Niklas Holsti" <niklas.holsti@tidorum.invalid> ha scritto nel messaggio
>> news:92l9a8F413U1@mid.individual.net...
>>> James Kuyper wrote:
>>>
>>>> I'm not aware of any other language that provides a mechanism for
>>>> avoiding or dealing with this problem, either. There might be one, but I
>>>> don't know it's name.
>>> Stack overflow in the Ada language is expected to raise the Storage_Error
>>> exception, which can be caught and handled in the Ada program itself.
>>> However,
>>> this can depend on compilation options, for example the GNU Ada compiler
>>> gnat
>>> needs the option -fstack-check for Storage_Error to work in this way,
>>> otherwise stack overflow just signals a SIGSEGV.
>>
>> for me it is the same recursive function that has to return error; as any
>> other
>> visible and invisible error; something like
>>
>> int recursivefunction(int* result, int* value)
>> {int a, b, c; // esp-=1024 esp<
>> if(GetCurrentStackPointerValue()<StackLimit-1000)
>> return -1
>> ....
>> return recursivefunction(result, value)
>> }
>
> Can be done in Ada:
>
> function recursivefunction (result, value : access integer)
> return integer
> is
> <declarations...>
> begin
> <statements...>
> return recursivefunction (result, value);
> exception
> when Storage_Error => return -1;
> end recursivefunction;
>
> In the function above, if any of the <statements> or the recursive call causes
> stack overflow, the Storage_Error handler is entered and the call returns -1.
> If the <declarations> cause stack overflow, the handler for the present call
> of recursivefunction is bypassed and the Storage_Error exception is propagated
> to the outer call level, entering the handler at that level.
for me it is good Ada has one mechanism for chach
one error **in the same function** [in what i understand]
so the function can return error;
some time ago i thought some sort of chach like above
> With the gnat Ada compiler it seems that stack overflow at any point in the
> function (declarations or statements) abandons the present call and propagates
> Storage_Error to the outer call. So if the stack overflow is detected on
> recursion level 9999 it is handled on level 9998. But that should not matter
> much.
>
> --
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
> . @ .
[toc] | [prev] | [next] | [standalone]
| From | boltar2003@boltar.world |
|---|---|
| Date | 2011-05-06 08:59 +0000 |
| Message-ID | <iq0d9b$1qe$1@speranza.aioe.org> |
| In reply to | #3320 |
On Thu, 5 May 2011 12:24:26 -0700 (PDT) "Kleuskes & Moos" <kleuske@xs4all.nl> wrote: >On May 5, 11:37=A0am, boltar2...@boltar.world wrote: >> Hello >> >> 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 thi= >s >> in C/C++? I realise I could catch the signal but thats a pretty damn ugly >> way to do it. >> >> B2003 > >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. Well its always theoretically possible to re-write recursive code in an iterative format but generally it leads to any reasonably complex recursive code becoming an unreadable mess. B2003
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-06 03:01 -0700 |
| Message-ID | <70d90b50-d514-402d-a20c-ed2b3e01bf2d@n10g2000yqf.googlegroups.com> |
| In reply to | #3359 |
On 6 mei, 10:59, boltar2...@boltar.world wrote: > On Thu, 5 May 2011 12:24:26 -0700 (PDT) > "Kleuskes & Moos" <kleu...@xs4all.nl> wrote: > > > > > > > > > > >On May 5, 11:37=A0am, boltar2...@boltar.world wrote: > >> Hello > > >> 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 thi= > >s > >> in C/C++? I realise I could catch the signal but thats a pretty damn ugly > >> way to do it. > > >> B2003 > > >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. > > Well its always theoretically possible to re-write recursive code in an > iterative format but generally it leads to any reasonably complex recursive > code becoming an unreadable mess. Bravo! That's he first sensible objection I've read in this thread, and you're right. Recursive algorithms are usually easier to grasp.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-06 07:13 -0400 |
| Message-ID | <iq0l45$cer$1@dont-email.me> |
| In reply to | #3370 |
On 05/06/2011 06:01 AM, Kleuskes & Moos wrote: > On 6 mei, 10:59, boltar2...@boltar.world wrote: ... >> Well its always theoretically possible to re-write recursive code in an >> iterative format but generally it leads to any reasonably complex recursive >> code becoming an unreadable mess. > > Bravo! That's he first sensible objection I've read in this thread, > and you're right. Recursive algorithms are usually easier to grasp. I think that this objection was considered so obvious by many of us that we didn't feel it needed emphasizing. It was referred to indirectly in some of the other messages people did post. As it turns out, we were right: you were in fact fully aware of the issue, and reached your conclusion despite that fact. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-06 09:02 -0700 |
| Message-ID | <4ea335bd-2b4e-46f4-8378-a457228d4926@b19g2000yqg.googlegroups.com> |
| In reply to | #3377 |
On May 6, 1:13 pm, James Kuyper <jameskuy...@verizon.net> wrote: > On 05/06/2011 06:01 AM, Kleuskes & Moos wrote: > > > On 6 mei, 10:59, boltar2...@boltar.world wrote: > ... > >> Well its always theoretically possible to re-write recursive code in an > >> iterative format but generally it leads to any reasonably complex recursive > >> code becoming an unreadable mess. > > > Bravo! That's he first sensible objection I've read in this thread, > > and you're right. Recursive algorithms are usually easier to grasp. > > I think that this objection was considered so obvious by many of us that > we didn't feel it needed emphasizing. It's always nice to provide your own applauding audience, so unless the 'we' is a 'pluralis maiestatis' i'm no likely to take that very seriously. > It was referred to indirectly in > some of the other messages people did post. As it turns out, we were > right: you were in fact fully aware of the issue, and reached your > conclusion despite that fact. Of course i was aware of the issue, and yes i reached that onclusion in spite of the fact that non-recursive algorithm's tend to be a bit less intuitive. But since you have already (and wrongly, i might add) argued that recursive algorithms are unsafe to begin with i still feel my position is sound on this matter.
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-05-06 15:41 -0700 |
| Message-ID | <rubrum-C8A86B.15410306052011@news.albasani.net> |
| In reply to | #3359 |
In article <iq0d9b$1qe$1@speranza.aioe.org>, boltar2003@boltar.world wrote: > On Thu, 5 May 2011 12:24:26 -0700 (PDT) > "Kleuskes & Moos" <kleuske@xs4all.nl> wrote: > >On May 5, 11:37=A0am, boltar2...@boltar.world wrote: > >> Hello > >> > >> 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 thi= > >s > >> in C/C++? I realise I could catch the signal but thats a pretty damn ugly > >> way to do it. > >> > >> B2003 > > > >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. > > Well its always theoretically possible to re-write recursive code in an > iterative format but generally it leads to any reasonably complex recursive > code becoming an unreadable mess. Does not have to. Implement a dynamically growable list with caching and memory recovery. Design a data structure for the data in the list. Design for list growing failure. Write push and pop. Presto! Chango! You have written a recursive function. -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-07 02:53 -0700 |
| Message-ID | <8f3e00bd-4883-461d-98aa-f2a7e581241f@k22g2000yqh.googlegroups.com> |
| In reply to | #3399 |
On May 7, 12:41 am, Michael Press <rub...@pacbell.net> wrote: > In article <iq0d9b$1q...@speranza.aioe.org>, boltar2...@boltar.world > wrote: > > > > > > > > > > > On Thu, 5 May 2011 12:24:26 -0700 (PDT) > > "Kleuskes & Moos" <kleu...@xs4all.nl> wrote: > > >On May 5, 11:37=A0am, boltar2...@boltar.world wrote: > > >> Hello > > > >> 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 thi= > > >s > > >> in C/C++? I realise I could catch the signal but thats a pretty damn ugly > > >> way to do it. > > > >> B2003 > > > >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. > > > Well its always theoretically possible to re-write recursive code in an > > iterative format but generally it leads to any reasonably complex recursive > > code becoming an unreadable mess. > > Does not have to. Implement a dynamically growable list > with caching and memory recovery. Design a data > structure for the data in the list. Design for list > growing failure. Write push and pop. Presto! Chango! > You have written a recursive function. :) Thanx...
[toc] | [prev] | [next] | [standalone]
| From | boltar2003@boltar.world |
|---|---|
| Date | 2011-05-07 16:17 +0000 |
| Message-ID | <iq3ra9$5lu$1@speranza.aioe.org> |
| In reply to | #3399 |
On Fri, 06 May 2011 15:41:03 -0700 Michael Press <rubrum@pacbell.net> wrote: >> Well its always theoretically possible to re-write recursive code in an >> iterative format but generally it leads to any reasonably complex recursive >> code becoming an unreadable mess. > >Does not have to. Implement a dynamically growable list >with caching and memory recovery. Design a data >structure for the data in the list. Design for list >growing failure. Write push and pop. Presto! Chango! >You have written a recursive function. So to implement a recursive function iteratively you manual stacks? Wow, who knew! </sarcasm> B2003
[toc] | [prev] | [next] | [standalone]
| From | William Ahern <william@wilbur.25thandClement.com> |
|---|---|
| Date | 2011-05-07 10:08 -0700 |
| Message-ID | <3tag98-eh9.ln1@wilbur.25thandClement.com> |
| In reply to | #3422 |
In comp.lang.c boltar2003@boltar.world wrote: > On Fri, 06 May 2011 15:41:03 -0700 > Michael Press <rubrum@pacbell.net> wrote: > >> Well its always theoretically possible to re-write recursive code in an > >> iterative format but generally it leads to any reasonably complex recursive > >> code becoming an unreadable mess. > > > >Does not have to. Implement a dynamically growable list > >with caching and memory recovery. Design a data > >structure for the data in the list. Design for list > >growing failure. Write push and pop. Presto! Chango! > >You have written a recursive function. > So to implement a recursive function iteratively you manual stacks? > Wow, who knew! > </sarcasm> Not necessarily... or rather, not exactly. Take a red-black tree implementation as an example. You can recurse, you can keep a manual stack, or you can use parent pointers. The beauty of the last option is that once you've allocated an object there's no possibility for collateral insertion failure (i.e. out-of-memory). If the sibling and parent pointers are members of the application object, then you can guarantee tree insertion. The downside is that maintaining parent pointers is more of a headache than a simple stack, and also most of those parent pointers are wasting memory, because you only required as many as were necessary to maintain a stack for the particular operation. I prefer all of my data structures to be free from resource acquisition failures. This makes RAII more convenient in C. My point is, you can roll the stack into whichever data structure you're working on, and a linked-list stack can be far more informative than an array stack (manual or implicit). Sometimes iterative algorithms like this are easier to comprehend. I'm writing a non-recursive implementation of left-leaning red-black trees, and insertion in particular seems much simpler in its iterative form.
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2011-05-07 20:20 +0100 |
| Message-ID | <pan.2011.05.07.19.20.45.593000@nowhere.com> |
| In reply to | #3431 |
On Sat, 07 May 2011 10:08:19 -0700, William Ahern wrote: > Not necessarily... or rather, not exactly. Take a red-black tree > implementation as an example. You can recurse, you can keep a manual stack, > or you can use parent pointers. The beauty of the last option is that once > you've allocated an object there's no possibility for collateral insertion > failure (i.e. out-of-memory). If the sibling and parent pointers are members > of the application object, then you can guarantee tree insertion. OTOH, if the parent pointers are part of the object, the object can only be inserted into a single tree (or, at least, a fixed set of trees).
[toc] | [prev] | [next] | [standalone]
| From | William Ahern <william@wilbur.25thandClement.com> |
|---|---|
| Date | 2011-05-07 14:26 -0700 |
| Message-ID | <01qg98-spe.ln1@wilbur.25thandClement.com> |
| In reply to | #3441 |
In comp.lang.c Nobody <nobody@nowhere.com> wrote: > On Sat, 07 May 2011 10:08:19 -0700, William Ahern wrote: > > Not necessarily... or rather, not exactly. Take a red-black tree > > implementation as an example. You can recurse, you can keep a manual stack, > > or you can use parent pointers. The beauty of the last option is that once > > you've allocated an object there's no possibility for collateral insertion > > failure (i.e. out-of-memory). If the sibling and parent pointers are members > > of the application object, then you can guarantee tree insertion. > OTOH, if the parent pointers are part of the object, the object can only > be inserted into a single tree (or, at least, a fixed set of trees). True, but I don't think I've worked on a software application that required insertion into an arbitrary number of trees, excepting actual language implementations. In fact, I don't think I've ever needed an object to be directly contained in more than two or three trees or lists simultaneously. An application basically boils down to the selection and use of data structures. If you modify the application, and add or remove a data structure, then modify the code accordingly. I can't remember the last time I used a void pointer in a tree or list structure in C. It just seems wrong. I don't believe I've ever needed a complex data structure to contain objects of unrelated type. Things get fuzzy when one has to be concerned with modules or other third party code. But if objects are being wrapped or subclassed, then the user can handle implementing a container. Anyhow, those patterns are more common in languages that handle memory management, provide very generic or universal primitives like hashes, and often are loosely typed. In those cases a failed allocation typically leads to the entire application aborting; for good reason, too. If statically describing a data and object model is too onerous, then recovering gracefully from memory errors is also likely to be impractical or error prone. In my opinion there's a misunderstanding about code reuse and modularity. The myth is that reuse means the code itself should be reuseable and extendable. But reuse is about the reuse of a solution, not code. A suitable high-level API oriented toward the solution is usually all the programmer should be concerned with. You don't subclass business solutions. That's nonsensical. It's exceedingly rare to need to subclass an HTTP parser, for example. If people are trying to tinker with the innards, then the API is poor. This is where the beauty of Open Source comes in; you can actually fix the API and improve the solution rather than hack around things.
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-05-07 14:31 -0700 |
| Message-ID | <rubrum-F3CAE7.14311807052011@news.albasani.net> |
| In reply to | #3431 |
In article <3tag98-eh9.ln1@wilbur.25thandClement.com>, William Ahern <william@wilbur.25thandClement.com> wrote: > In comp.lang.c boltar2003@boltar.world wrote: > > On Fri, 06 May 2011 15:41:03 -0700 > > Michael Press <rubrum@pacbell.net> wrote: > > >> Well its always theoretically possible to re-write recursive code in an > > >> iterative format but generally it leads to any reasonably complex recursive > > >> code becoming an unreadable mess. > > > > > >Does not have to. Implement a dynamically growable list > > >with caching and memory recovery. Design a data > > >structure for the data in the list. Design for list > > >growing failure. Write push and pop. Presto! Chango! > > >You have written a recursive function. > > > So to implement a recursive function iteratively you manual stacks? > > Wow, who knew! > > </sarcasm> > > Not necessarily... or rather, not exactly. Take a red-black tree > implementation as an example. You can recurse, you can keep a manual stack, > or you can use parent pointers. The beauty of the last option is that once > you've allocated an object there's no possibility for collateral insertion > failure (i.e. out-of-memory). If the sibling and parent pointers are members > of the application object, then you can guarantee tree insertion. > > The downside is that maintaining parent pointers is more of a headache than > a simple stack, and also most of those parent pointers are wasting memory, > because you only required as many as were necessary to maintain a stack for > the particular operation. I thought of that, but technically it is not a tree; and I mean to stand on that technicality. It needs O(depth of the tree) storage to traverse a tree. > I prefer all of my data structures to be free from resource acquisition > failures. This makes RAII more convenient in C. > > My point is, you can roll the stack into whichever data structure you're > working on, and a linked-list stack can be far more informative than an > array stack (manual or implicit). Sometimes iterative algorithms like this > are easier to comprehend. I'm writing a non-recursive implementation of > left-leaning red-black trees, and insertion in particular seems much simpler > in its iterative form. This means that you allocate all memory necessary before beginning to build the data structure? And never need to allocate more memory? -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | William Ahern <william@wilbur.25thandClement.com> |
|---|---|
| Date | 2011-05-07 22:49 -0700 |
| Message-ID | <ffnh98-fpb.ln1@wilbur.25thandClement.com> |
| In reply to | #3455 |
In comp.unix.programmer Michael Press <rubrum@pacbell.net> wrote: > In article <3tag98-eh9.ln1@wilbur.25thandClement.com>, > William Ahern <william@wilbur.25thandClement.com> wrote: <snip> > > I prefer all of my data structures to be free from resource acquisition > > failures. This makes RAII more convenient in C. > > > > My point is, you can roll the stack into whichever data structure you're > > working on, and a linked-list stack can be far more informative than an > > array stack (manual or implicit). Sometimes iterative algorithms like this > > are easier to comprehend. I'm writing a non-recursive implementation of > > left-leaning red-black trees, and insertion in particular seems much simpler > > in its iterative form. > This means that you allocate all memory necessary > before beginning to build the data structure? And > never need to allocate more memory? On BSD and Linux systems see, for example, the list implementations in /usr/include/sys/queue.h. You're allocating new memory for each object at construction time, but there's no separate allocation when manipulating a list, tree, etc. So list insertion has no failure mode. Tree insertion can often be arranged to have no failure mode, but in any event it wouldn't be because of an OOM condition. I eschew hash tables in C because they require dynamic memory management, and because of algorithmic complexity attacks--unless your hash is cryptographically strong, an attacker could make your hash table work in O(N), but an O(1) crypto-strong hashed table tends to be slower than O(lg(N)) with my data sets and usage patterns, or at least not worth the hassle. Most of my work involves network-facing software, where paranoia is a virtue.
[toc] | [prev] | [next] | [standalone]
| From | Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> |
|---|---|
| Date | 2011-05-07 17:22 +0000 |
| Message-ID | <4dc57fbc$0$81484$e4fe514c@news.xs4all.nl> |
| In reply to | #3422 |
boltar2003@boltar.world writes: >On Fri, 06 May 2011 15:41:03 -0700 >Michael Press <rubrum@pacbell.net> wrote: >>> Well its always theoretically possible to re-write recursive code in an >>> iterative format but generally it leads to any reasonably complex recursive >>> code becoming an unreadable mess. >> >>Does not have to. Implement a dynamically growable list >>with caching and memory recovery. Design a data >>structure for the data in the list. Design for list >>growing failure. Write push and pop. Presto! Chango! >>You have written a recursive function. >So to implement a recursive function iteratively you manual stacks? >Wow, who knew! ></sarcasm> And instead you run out of heap. Casper --
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-07 10:24 -0700 |
| Message-ID | <18115bd0-dc38-47a1-8f92-433dec64343b@n11g2000yqf.googlegroups.com> |
| In reply to | #3432 |
On May 7, 7:22 pm, Casper H.S. Dik <Casper....@OrSPaMcle.COM> wrote: > boltar2...@boltar.world writes: > >On Fri, 06 May 2011 15:41:03 -0700 > >Michael Press <rub...@pacbell.net> wrote: > >>> Well its always theoretically possible to re-write recursive code in an > >>> iterative format but generally it leads to any reasonably complex recursive > >>> code becoming an unreadable mess. > > >>Does not have to. Implement a dynamically growable list > >>with caching and memory recovery. Design a data > >>structure for the data in the list. Design for list > >>growing failure. Write push and pop. Presto! Chango! > >>You have written a recursive function. > >So to implement a recursive function iteratively you manual stacks? > >Wow, who knew! > ></sarcasm> > > And instead you run out of heap. Aye. But there's portable ways of checking that: malloc will just return NULL, which can be handled nicely and safely, instead of the system throwing a SIGSEGV.
[toc] | [prev] | [next] | [standalone]
| From | Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> |
|---|---|
| Date | 2011-05-07 17:32 +0000 |
| Message-ID | <4dc58247$0$81485$e4fe514c@news.xs4all.nl> |
| In reply to | #3433 |
"Kleuskes & Moos" <kleuske@xs4all.nl> writes: >On May 7, 7:22=A0pm, Casper H.S. Dik <Casper....@OrSPaMcle.COM> wrote: >> boltar2...@boltar.world writes: >> >On Fri, 06 May 2011 15:41:03 -0700 >> >Michael Press <rub...@pacbell.net> wrote: >> >>> Well its always theoretically possible to re-write recursive code in = >an >> >>> iterative format but generally it leads to any reasonably complex rec= >ursive >> >>> code becoming an unreadable mess. >> >> >>Does not have to. Implement a dynamically growable list >> >>with caching and memory recovery. Design a data >> >>structure for the data in the list. Design for list >> >>growing failure. Write push and pop. Presto! Chango! >> >>You have written a recursive function. >> >So to implement a recursive function iteratively you manual stacks? >> >Wow, who knew! >> ></sarcasm> >> >> And instead you run out of heap. >Aye. But there's portable ways of checking that: malloc will just >return NULL, which can be handled nicely and safely, instead of the >system throwing a SIGSEGV. As other have pointed out, it is possible to catch this and properly terminate (the same when you run out of stack) Casper --
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-07 11:43 -0700 |
| Message-ID | <fec0bf4d-aaa0-4f5f-bc29-a15f71407312@j23g2000yqc.googlegroups.com> |
| In reply to | #3435 |
On 7 mei, 19:32, Casper H.S. Dik <Casper....@OrSPaMcle.COM> wrote: > "Kleuskes & Moos" <kleu...@xs4all.nl> writes: > > > > > > > > > > >On May 7, 7:22=A0pm, Casper H.S. Dik <Casper....@OrSPaMcle.COM> wrote: > >> boltar2...@boltar.world writes: > >> >On Fri, 06 May 2011 15:41:03 -0700 > >> >Michael Press <rub...@pacbell.net> wrote: > >> >>> Well its always theoretically possible to re-write recursive code in = > >an > >> >>> iterative format but generally it leads to any reasonably complex rec= > >ursive > >> >>> code becoming an unreadable mess. > > >> >>Does not have to. Implement a dynamically growable list > >> >>with caching and memory recovery. Design a data > >> >>structure for the data in the list. Design for list > >> >>growing failure. Write push and pop. Presto! Chango! > >> >>You have written a recursive function. > >> >So to implement a recursive function iteratively you manual stacks? > >> >Wow, who knew! > >> ></sarcasm> > > >> And instead you run out of heap. > >Aye. But there's portable ways of checking that: malloc will just > >return NULL, which can be handled nicely and safely, instead of the > >system throwing a SIGSEGV. > > As other have pointed out, it is possible to catch this and properly > terminate (the same when you run out of stack) Ah... That's news. I was under the distinct impression that stack- overflows are impossible to catch. Please expound on your method to reliably (and portably) catch stack-overflows in recursive algorithms. I'm quite curious.
[toc] | [prev] | [next] | [standalone]
| From | Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> |
|---|---|
| Date | 2011-05-08 10:57 +0000 |
| Message-ID | <4dc6771f$0$41113$e4fe514c@news.xs4all.nl> |
| In reply to | #3438 |
"Kleuskes & Moos" <kleuske@xs4all.nl> writes: >Ah... That's news. I was under the distinct impression that stack- >overflows are impossible to catch. Please expound on your method to >reliably (and portably) catch stack-overflows in recursive algorithms. >I'm quite curious. Using an alternate signal stack is able to catch this, but don't be an a* about asking for "reliably and portability". Casper --
[toc] | [prev] | [next] | [standalone]
Page 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web