Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.unix.programmer > #306 > unrolled thread
| Started by | boltar2003@boltar.world |
|---|---|
| First post | 2011-05-05 09:37 +0000 |
| Last post | 2011-05-05 12:18 -0700 |
| Articles | 20 on this page of 270 — 46 participants |
Back to article view | Back to comp.unix.programmer
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? Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2011-05-05 13:40 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 13:52 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Azazel <azazel@remove.azazel.net> - 2011-05-05 09:22 -0500
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 14:41 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Azazel <azazel@remove.azazel.net> - 2011-05-05 10:30 -0500
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-07 23:23 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-05 18:55 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-05 11:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-06 14:36 +0200
RLIMIT_STACK (was: Avoiding recursive stack overflow in C on Unix/Linux?) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2011-05-10 14:19 +0100
Re: RLIMIT_STACK Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-11 08:28 +0200
Re: RLIMIT_STACK scott@slp53.sl.home (Scott Lurndal) - 2011-05-11 16:18 +0000
Re: RLIMIT_STACK Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-11 18:37 +0200
Re: RLIMIT_STACK scott@slp53.sl.home (Scott Lurndal) - 2011-05-11 19:53 +0000
Re: RLIMIT_STACK Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2011-05-11 17:43 +0100
Re: RLIMIT_STACK Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-11 20:03 +0200
Re: RLIMIT_STACK Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-11 20:20 +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? Noob <root@127.0.0.1> - 2011-06-01 15:19 +0200
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? Michael Press <rubrum@pacbell.net> - 2011-05-07 21:02 -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? Måns Rullgård <mans@mansr.com> - 2011-05-06 10:07 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-06 10:29 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-06 03:04 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 06:33 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-06 12:04 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? David Schwartz <davids@webmaster.com> - 2011-05-07 04:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-07 13:07 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? David Schwartz <davids@webmaster.com> - 2011-05-07 21:13 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-08 10:46 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? David Schwartz <davids@webmaster.com> - 2011-05-08 05:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Golden California Girls <gldncagrls@aol.com.mil> - 2011-05-07 08:59 -0700
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? Nicolas George <nicolas$george@salle-s.org> - 2011-05-11 21:07 +0000
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? "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2011-05-15 18:21 +0200
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? Nicolas George <nicolas$george@salle-s.org> - 2011-05-16 16:58 +0000
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? Michael Press <rubrum@pacbell.net> - 2011-05-07 23:27 -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? 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? Nobody <nobody@nowhere.com> - 2011-05-08 08:37 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 11:13 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-09 15:46 -0700
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? boltar2003@boltar.world - 2011-05-10 08:30 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-11 03:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-05 12:18 -0700
Page 12 of 14 — ← Prev page 1 … 10 11 [12] 13 14 Next page →
| From | boltar2003@boltar.world |
|---|---|
| Date | 2011-05-07 16:17 +0000 |
| Message-ID | <iq3ra9$5lu$1@speranza.aioe.org> |
| In reply to | #361 |
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 | #373 |
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 | #377 |
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 | #385 |
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 | #377 |
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 | #394 |
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 | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-05-07 23:27 -0700 |
| Message-ID | <rubrum-60795E.23271007052011@news.albasani.net> |
| In reply to | #410 |
In article <ffnh98-fpb.ln1@wilbur.25thandClement.com>, William Ahern <william@wilbur.25thandClement.com> wrote: > 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. Okay. I did `man queue' and will read it. You answered one question. An OOM condition can only occur when constructing a node, but not when traversing the data structure. The data structure that we think of as a tree is not really a tree, is it? The data is organized as a tree, and part of the code that traverses the tree part is embedded or cached nearby. > 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. -- Michael Press
[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 | #373 |
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 | #378 |
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 | #379 |
"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 | #381 |
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 | #382 |
"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]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-08 08:09 -0700 |
| Message-ID | <33207f5d-4927-4dcf-97ac-0398e2a9eefc@b19g2000yqg.googlegroups.com> |
| In reply to | #422 |
On May 8, 12:57 pm, Casper H.S. Dik <Casper....@OrSPaMcle.COM> wrote: > "Kleuskes & Moos" <kleu...@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". If it's unreliable then it's useless, so if you consider me an ass to demand it to be reliable, then so be it. Portability is a major issue, so calling me an ass for that falls under the same category. But i'd still be interested in your non-portable way, and the above is insufficient to give me an idea about what you have in mind.
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2011-05-08 19:41 +0100 |
| Message-ID | <pan.2011.05.08.18.41.41.359000@nowhere.com> |
| In reply to | #429 |
On Sun, 08 May 2011 08:09:26 -0700, Kleuskes & Moos wrote: >> Using an alternate signal stack is able to catch this, but >> don't be an a* about asking for "reliably and portability". > > If it's unreliable then it's useless, so if you consider me an ass to > demand it to be reliable, then so be it. Portability is a major issue, > so calling me an ass for that falls under the same category. Not really. Very few real programs are truly portable insofar as they require nothing beyond what is mandated by the C standard. If you need to use directories, child processes, networking, a GUI, etc, you have to forego portability to get them. A lot of code forsakes portability simply for performance reasons.
[toc] | [prev] | [next] | [standalone]
| From | Xavier Roche <xroche@free.fr.NOSPAM.invalid> |
|---|---|
| Date | 2011-05-08 17:59 +0200 |
| Message-ID | <iq6eks$o84$1@news.httrack.net> |
| In reply to | #382 |
Le 07/05/2011 20:43, Kleuskes & Moos a écrit :
> overflows are impossible to catch. Please expound on your method to
> reliably (and portably) catch stack-overflows in recursive algorithms.
To play devil's advocate (yes, having a stack overflow is a clear sign
that your algorithm sucks), you could in theory play with setjmp/longjmp
and a signal handler. This method is a big evil and gory, but, well,
using POSIX functions :)
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
#include <setjmp.h>
#include <sys/ucontext.h>
#include <assert.h>
static jmp_buf jmp_return;
static void handler(int code, siginfo_t *si, void *ctx) {
static const char message[] = "Caught SEGV\n";
(void) write(2, message, sizeof(message) - 1);
longjmp(jmp_return, 1);
}
/* Crappy recusrive function. */
static long recurse(long i) {
if (i > 3) {
return recurse(i - 1)*recurse(i - 2)*recurse(i - 3);
} else {
return 1;
}
}
static void *myFun(void *arg) {
long long value = *(long long*) arg;
struct sigaction sa;
printf("entering thread\n");
/* Install alternative stack. */
stack_t * const ss = calloc(1, sizeof(stack_t));
ss->ss_size = SIGSTKSZ;
ss->ss_sp = malloc(ss->ss_size);
ss->ss_flags = 0;
if (sigaltstack(ss, NULL) == -1) {
assert(0);
}
/* Install SEGV handler. */
if (sigemptyset(&sa.sa_mask) != 0) {
abort();
}
sa.sa_sigaction = handler;
sa.sa_flags = SA_SIGINFO | SA_ONSTACK;
if (sigaction(SIGSEGV, &sa, NULL) != 0) {
abort();
}
/* Save context. */
printf("executing function\n");
if (setjmp(jmp_return) == 0) {
const long result = recurse(value);
printf("result == %lu\n", result);
} else {
fprintf(stderr, "recurse failed\n");
}
printf("returning from thread\n");
return NULL;
}
int main(int argc, char **argv) {
pthread_t t;
long long value = atoll(argc > 1 ? argv[1] : "100000000000");
printf("main\n");
if (pthread_create(&t, NULL, myFun, &value) == 0) {
if (pthread_join(t, NULL) == 0) {
printf("success\n");
return EXIT_SUCCESS;
}
}
printf("error\n");
return EXIT_FAILURE;
}
[toc] | [prev] | [next] | [standalone]
| From | Xavier Roche <xroche@free.fr.NOSPAM.invalid> |
|---|---|
| Date | 2011-05-09 09:01 +0200 |
| Message-ID | <iq83ge$4gc$1@news.httrack.net> |
| In reply to | #431 |
On 05/08/2011 05:59 PM, Xavier Roche wrote: > To play devil's advocate (yes, having a stack overflow is a clear sign > that your algorithm sucks), you could in theory play with setjmp/longjmp > and a signal handler. This method is a big evil and gory, but, well, > using POSIX functions :) Note: for the lurkers, in the sample, it would be better to replace setjmp() by sigsetjmp(), and longjmp() by siglongjmp().
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2011-05-07 20:41 +0100 |
| Message-ID | <pan.2011.05.07.19.41.22.734000@nowhere.com> |
| In reply to | #379 |
On Sat, 07 May 2011 10:24:42 -0700, Kleuskes & Moos wrote: >> 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. You forgot a case: malloc() succeeds but the process receives SIGKILL when it actually tries to use the allocated memory (OOM-killer). This can be prevented by disabling overcommit, but on some systems the cost of doing so is unacceptably high, i.e. you may need to provide ten times (or worse) as much swap space as will ever be used in practice.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-07 12:48 -0700 |
| Message-ID | <lnei4apa0x.fsf@nuthaus.mib.org> |
| In reply to | #389 |
Nobody <nobody@nowhere.com> writes:
> On Sat, 07 May 2011 10:24:42 -0700, Kleuskes & Moos wrote:
>>> 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.
>
> You forgot a case: malloc() succeeds but the process receives SIGKILL when
> it actually tries to use the allocated memory (OOM-killer).
Actaully the OOM-killer kills *some* process, not necessarily the one
that just tried to use allocated memory.
> This can be prevented by disabling overcommit, but on some systems the
> cost of doing so is unacceptably high, i.e. you may need to provide ten
> times (or worse) as much swap space as will ever be used in practice.
--
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 | Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> |
|---|---|
| Date | 2011-05-08 11:01 +0000 |
| Message-ID | <4dc6780f$0$41113$e4fe514c@news.xs4all.nl> |
| In reply to | #390 |
Keith Thompson <kst-u@mib.org> writes: >Nobody <nobody@nowhere.com> writes: >> On Sat, 07 May 2011 10:24:42 -0700, Kleuskes & Moos wrote: >>>> 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. >> >> You forgot a case: malloc() succeeds but the process receives SIGKILL when >> it actually tries to use the allocated memory (OOM-killer). >Actaully the OOM-killer kills *some* process, not necessarily the one >that just tried to use allocated memory. Usually the large process such as the most important process :-) (I'd start with webbrowser as people will expect it to crash anyway) Casper --
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2011-05-08 13:10 +0000 |
| Message-ID | <iq64oh$vuo$1@news.xmission.com> |
| In reply to | #390 |
In article <lnei4apa0x.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.org> wrote:
>Nobody <nobody@nowhere.com> writes:
>> On Sat, 07 May 2011 10:24:42 -0700, Kleuskes & Moos wrote:
>>>> 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.
>>
>> You forgot a case: malloc() succeeds but the process receives SIGKILL when
>> it actually tries to use the allocated memory (OOM-killer).
>
>Actaully the OOM-killer kills *some* process, not necessarily the one
>that just tried to use allocated memory.
Show me where this thing of which you speak, this "OOM-killer", is mentioned
in (any of) the C standards documents. Thank you.
P.S. Having just Googled it, I see that this "OOM-killer" is a
Linux-specific thing, so discussion of it is OT in both newsgroups to which
this is being posted.
--
"We should always be disposed to believe that which appears to us to be
white is really black, if the hierarchy of the church so decides."
- Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -
[toc] | [prev] | [next] | [standalone]
Page 12 of 14 — ← Prev page 1 … 10 11 [12] 13 14 Next page →
Back to top | Article view | comp.unix.programmer
csiph-web