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 4 of 14 — ← Prev page 1 2 3 [4] 5 6 … 14 Next page →
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-05-08 15:26 -0700 |
| Message-ID | <rubrum-1DF3B6.15265108052011@news.albasani.net> |
| In reply to | #380 |
In article <614e7c8f-8298-45d1-8f10-c940f614af31@g12g2000yqd.googlegroups.com>, "Kleuskes & Moos" <kleuske@xs4all.nl> wrote: > On May 7, 3:01 pm, Barry Margolin <bar...@alum.mit.edu> wrote: > <snip> > > > read_first_token > > process_token > > recurse(rest of document) > > Where i work, code like that is likely to get you fired on the spot. The Code of Hammurabi. -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | William Ahern <william@wilbur.25thandClement.com> |
|---|---|
| Date | 2011-05-07 09:32 -0700 |
| Message-ID | <cq8g98-jcf.ln1@wilbur.25thandClement.com> |
| In reply to | #365 |
In comp.lang.c Dr Nick <3-nospam@temporary-address.org.uk> wrote: > "Kleuskes & Moos" <kleuske@xs4all.nl> writes: > > The saving grace of recursion is that recursive implementations are > > usually easier to understand. If it weren't for that, i'd ban the > > practice outright. > I'd be intrigued to see a non-recursive implementation of the code of a > library for creating, reading into memory and printing JSON data > structures as an obvious example. I would hope such library was non-recursive. This has Denial of Service written all over it, considering that JSON data usually comes from untrusted sources, and even many scripting languages use the C stack for calls in the scripting language. I suppose one could add kludges like a depth counter. I say kludge because stack memory in C is such an opaque and unmeasureable quantity.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-08 10:46 +1200 |
| Message-ID | <92m0eqF82qU1@mid.individual.net> |
| In reply to | #375 |
On 05/ 8/11 04:32 AM, William Ahern wrote: > In comp.lang.c Dr Nick<3-nospam@temporary-address.org.uk> wrote: >> "Kleuskes& Moos"<kleuske@xs4all.nl> writes: > >>> The saving grace of recursion is that recursive implementations are >>> usually easier to understand. If it weren't for that, i'd ban the >>> practice outright. > >> I'd be intrigued to see a non-recursive implementation of the code of a >> library for creating, reading into memory and printing JSON data >> structures as an obvious example. > > I would hope such library was non-recursive. This has Denial of Service > written all over it, considering that JSON data usually comes from untrusted > sources, and even many scripting languages use the C stack for calls in the > scripting language. > > I suppose one could add kludges like a depth counter. I say kludge because > stack memory in C is such an opaque and unmeasureable quantity. It would take an extremely large JSON object (at least as big as the stack) to overflow a server's stack. A prudent sever admin would set a realistic limit on request sizes. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | William Ahern <william@wilbur.25thandClement.com> |
|---|---|
| Date | 2011-05-07 21:49 -0700 |
| Message-ID | <evjh98-mdb.ln1@wilbur.25thandClement.com> |
| In reply to | #401 |
In comp.unix.programmer Ian Collins <ian-news@hotmail.com> wrote: > On 05/ 8/11 04:32 AM, William Ahern wrote: > > In comp.lang.c Dr Nick<3-nospam@temporary-address.org.uk> wrote: > >> "Kleuskes& Moos"<kleuske@xs4all.nl> writes: > > > >>> The saving grace of recursion is that recursive implementations are > >>> usually easier to understand. If it weren't for that, i'd ban the > >>> practice outright. > > > >> I'd be intrigued to see a non-recursive implementation of the code of a > >> library for creating, reading into memory and printing JSON data > >> structures as an obvious example. > > > > I would hope such library was non-recursive. This has Denial of Service > > written all over it, considering that JSON data usually comes from untrusted > > sources, and even many scripting languages use the C stack for calls in the > > scripting language. > > > > I suppose one could add kludges like a depth counter. I say kludge because > > stack memory in C is such an opaque and unmeasureable quantity. > It would take an extremely large JSON object (at least as big as the > stack) to overflow a server's stack. A prudent sever admin would set a > realistic limit on request sizes. Relying on prudent admins, instead of safe by design, explains where the industry is in terms of security. But I'll admit that blowing the stack is low on the list of things to freak out over, especially given the behavior on most systems is to safely terminate. And if a recursive algorithm is much simpler and easier to code safely, it's a compromise I'd make, everything else being equal.
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-07 09:59 -0700 |
| Message-ID | <8f882810-2e4e-404f-a660-fdcbb67360c9@e35g2000yqc.googlegroups.com> |
| In reply to | #365 |
On May 7, 2:03 pm, Dr Nick <3-nos...@temporary-address.org.uk> wrote: > "Kleuskes & Moos" <kleu...@xs4all.nl> writes: > > > The saving grace of recursion is that recursive implementations are > > usually easier to understand. If it weren't for that, i'd ban the > > practice outright. > > I'd be intrigued to see a non-recursive implementation of the code of a > library for creating, reading into memory and printing JSON data > structures as an obvious example. Not that difficult. I suspect most (stable) JSON versions are non- recursive and (like many other parsers and parser generators such as flex), employ a FSM instead. For good reason, too, as William Ahern points out.
[toc] | [prev] | [next] | [standalone]
| From | Dr Nick <3-nospam@temporary-address.org.uk> |
|---|---|
| Date | 2011-05-07 20:24 +0100 |
| Message-ID | <87r58anwjr.fsf@temporary-address.org.uk> |
| In reply to | #376 |
"Kleuskes & Moos" <kleuske@xs4all.nl> writes:
> On May 7, 2:03 pm, Dr Nick <3-nos...@temporary-address.org.uk> wrote:
>> "Kleuskes & Moos" <kleu...@xs4all.nl> writes:
>>
>> > The saving grace of recursion is that recursive implementations are
>> > usually easier to understand. If it weren't for that, i'd ban the
>> > practice outright.
>>
>> I'd be intrigued to see a non-recursive implementation of the code of a
>> library for creating, reading into memory and printing JSON data
>> structures as an obvious example.
>
> Not that difficult. I suspect most (stable) JSON versions are non-
> recursive and (like many other parsers and parser generators such as
> flex), employ a FSM instead.
>
> For good reason, too, as William Ahern points out.
It's not so much the parser, it's the data store and the output.
suppose you have the following sort of interface:
object *new_atom(char *contents);
object *new_list(void);
object *new_array(void);
void add_to_list(object* destination, object *source);
void add_to_array(object* destination, char *name, object *source);
void print_object(object *item);
How do you code print_object in a non-recursive way? Remember, we might
have done something like this:
object *s1 = new_atom("hello");
object *s2 = new_atom("world");
object *l1 = new_list();
object *l2 = new_list();
add_to_list(l1,s1);
add_to_list(l1,s2);
add_to_list(l2,s2);
add_to_list(l2,s1);
add_to_list(l2,l1);
object a1 = new_array();
add_to_array(a1,"hi",s1);
add_to_array(a1,"simple",l1);
add_to_array(a1,"notsosimple",l2);
add_to_array(a1,"what",s2);
print_object(a1);
Somewhere you are going to need a queue. I'm far from convinced
(particularly given the way many modern machines act when memory gets
tight; even if you turn off optimistic allocation, many will grind to a
halt thrashing the swap months before malloc returns NULL) that catching
malloc failures in a manual queue is any better than catching a signal
from the stack filling up.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-05-07 15:04 -0700 |
| Message-ID | <rubrum-267C0F.15040407052011@news.albasani.net> |
| In reply to | #376 |
In article <8f882810-2e4e-404f-a660-fdcbb67360c9@e35g2000yqc.googlegroups.com>, "Kleuskes & Moos" <kleuske@xs4all.nl> wrote: > On May 7, 2:03 pm, Dr Nick <3-nos...@temporary-address.org.uk> wrote: > > "Kleuskes & Moos" <kleu...@xs4all.nl> writes: > > > > > The saving grace of recursion is that recursive implementations are > > > usually easier to understand. If it weren't for that, i'd ban the > > > practice outright. > > > > I'd be intrigued to see a non-recursive implementation of the code of a > > library for creating, reading into memory and printing JSON data > > structures as an obvious example. > > Not that difficult. I suspect most (stable) JSON versions are non- > recursive and (like many other parsers and parser generators such as > flex), employ a FSM instead. A FSM has a hard coded bound on depth. Can you make these parser generators admit to reaching their limit by asking them to parse input that goes too deep? -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-07 15:15 -0700 |
| Message-ID | <fd463f06-f800-4b97-b02c-135deac828bd@m10g2000yqd.googlegroups.com> |
| In reply to | #395 |
On May 8, 12:04 am, Michael Press <rub...@pacbell.net> wrote: > In article > <8f882810-2e4e-404f-a660-fdcbb6736...@e35g2000yqc.googlegroups.com>, > "Kleuskes & Moos" <kleu...@xs4all.nl> wrote: > > > On May 7, 2:03 pm, Dr Nick <3-nos...@temporary-address.org.uk> wrote: > > > "Kleuskes & Moos" <kleu...@xs4all.nl> writes: > > > > > The saving grace of recursion is that recursive implementations are > > > > usually easier to understand. If it weren't for that, i'd ban the > > > > practice outright. > > > > I'd be intrigued to see a non-recursive implementation of the code of a > > > library for creating, reading into memory and printing JSON data > > > structures as an obvious example. > > > Not that difficult. I suspect most (stable) JSON versions are non- > > recursive and (like many other parsers and parser generators such as > > flex), employ a FSM instead. > > A FSM has a hard coded bound on depth. Since when? > Can you make these parser generators > admit to reaching their limit by asking > them to parse input that goes too deep? Huh?
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-05-07 21:02 -0700 |
| Message-ID | <rubrum-6FE8E4.21023707052011@news.albasani.net> |
| In reply to | #397 |
In article <fd463f06-f800-4b97-b02c-135deac828bd@m10g2000yqd.googlegroups.com>, "Kleuskes & Moos" <kleuske@xs4all.nl> wrote: > On May 8, 12:04 am, Michael Press <rub...@pacbell.net> wrote: > > In article > > <8f882810-2e4e-404f-a660-fdcbb6736...@e35g2000yqc.googlegroups.com>, > > "Kleuskes & Moos" <kleu...@xs4all.nl> wrote: > > > > > On May 7, 2:03 pm, Dr Nick <3-nos...@temporary-address.org.uk> wrote: > > > > "Kleuskes & Moos" <kleu...@xs4all.nl> writes: > > > > > > > The saving grace of recursion is that recursive implementations are > > > > > usually easier to understand. If it weren't for that, i'd ban the > > > > > practice outright. > > > > > > I'd be intrigued to see a non-recursive implementation of the code of a > > > > library for creating, reading into memory and printing JSON data > > > > structures as an obvious example. > > > > > Not that difficult. I suspect most (stable) JSON versions are non- > > > recursive and (like many other parsers and parser generators such as > > > flex), employ a FSM instead. > > > > A FSM has a hard coded bound on depth. > > Since when? Since always. > > Can you make these parser generators > > admit to reaching their limit by asking > > them to parse input that goes too deep? > > Huh? -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2011-05-07 19:57 +0100 |
| Message-ID | <pan.2011.05.07.18.56.55.953000@nowhere.com> |
| In reply to | #365 |
On Sat, 07 May 2011 13:03:47 +0100, Dr Nick wrote: >> The saving grace of recursion is that recursive implementations are >> usually easier to understand. If it weren't for that, i'd ban the >> practice outright. > > I'd be intrigued to see a non-recursive implementation of the code of a > library for creating, reading into memory and printing JSON data > structures as an obvious example. "Real" parsers are seldom recursive, but instead use an explicit stack (pushdown automaton). Recursive-descent parsers tend to be used by people who are unfamiliar with existing practice and just used the first approach they thought of. The main drawbacks of recursive parsers are: 1. They need hacks to avoid infinite recursion when dealing with left-recursive grammars. 2. They're "pull" orientated; once they start reading an entity, they don't return until they've finished. For anything dealing with networking, point #2 favours the automaton approach, as you can push tokens into the parser as and when they arrive over the network, and get on with something else (e.g. redraw) when no more data is available. To obtain a similar interface, a recursive parser needs to be turned inside-out, using continuations, threads (coroutines), etc. OTOH, actually processing the subsequent parse tree naturally lends itself to a recursive algorithm. Of course, any such algorithm can be converted to a non-recursive algorithm, but the result will typically resemble machine code (i.e. with explicit "call" and "return" operations), which largely defeats the point of having high-level languages.
[toc] | [prev] | [next] | [standalone]
| From | Dr Nick <3-nospam@temporary-address.org.uk> |
|---|---|
| Date | 2011-05-07 20:26 +0100 |
| Message-ID | <87mxiynwhb.fsf@temporary-address.org.uk> |
| In reply to | #383 |
Nobody <nobody@nowhere.com> writes: > On Sat, 07 May 2011 13:03:47 +0100, Dr Nick wrote: > >>> The saving grace of recursion is that recursive implementations are >>> usually easier to understand. If it weren't for that, i'd ban the >>> practice outright. >> >> I'd be intrigued to see a non-recursive implementation of the code of a >> library for creating, reading into memory and printing JSON data >> structures as an obvious example. > > OTOH, actually processing the subsequent parse tree naturally lends itself > to a recursive algorithm. Of course, any such algorithm can be converted > to a non-recursive algorithm, but the result will typically resemble > machine code (i.e. with explicit "call" and "return" operations), which > largely defeats the point of having high-level languages. Indeed. Parsing is a red herring here. It's how you represent and then how you traverse a naturally recursive data structure, such as pretty well any modern language has. -- Online waterways route planner | http://canalplan.eu Plan trips, see photos, check facilities | http://canalplan.org.uk
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2011-05-07 21:06 +0100 |
| Message-ID | <pan.2011.05.07.20.06.34.0@nowhere.com> |
| In reply to | #387 |
On Sat, 07 May 2011 20:26:08 +0100, Dr Nick wrote: >> OTOH, actually processing the subsequent parse tree naturally lends itself >> to a recursive algorithm. Of course, any such algorithm can be converted >> to a non-recursive algorithm, but the result will typically resemble >> machine code (i.e. with explicit "call" and "return" operations), which >> largely defeats the point of having high-level languages. > > Indeed. Parsing is a red herring here. It's how you represent and then > how you traverse a naturally recursive data structure, such as pretty > well any modern language has. An interpreted programming language may still use a "hand-rolled" call stack, as it can simplify the implementation of features such as exceptions and continuations. More mundane processing of recursive structures[1] is likely to just use recursive function calls. [1] And also divide-and-conquer algorithms on linear structures, e.g. quicksort.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2011-05-07 23:27 +0000 |
| Message-ID | <Szkxp.201860$fQ3.25462@news.usenetserver.com> |
| In reply to | #338 |
"Kleuskes & Moos" <kleuske@xs4all.nl> writes: >Nope. It follows from the design of processors and a wish to avoid >unneccesary overhead (passing arguments, stack-frame maintenance, >pushing and popping return adresses) and that's without even >considering any effect a call may have on things like branch- >prediction, instruction pipe-lines and such. > A 'call' instruction is >(relative to a branch) quite expensive and prevents some optimisations >like loop-unrolling. Actually, it is not that expensive with modern processors (which include internal return stacks, and for Intel x86_64, passes parameters in general purpose registers (up to the first 6 args)). Branch prediction doesn't have anything to do with calls (which are just unconditional branches). A function call to a recursive function with less than 6 args will involve one memory reference on the call instruction (to push the return address). scott
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-05 20:07 -0400 |
| Message-ID | <ipve3o$stk$1@dont-email.me> |
| In reply to | #321 |
On 05/05/2011 03:24 PM, Kleuskes & Moos wrote:
> On May 5, 11:37�am, 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 this
>> 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.
And how do you do that? If the stack size is sufficiently limited, even
int main(int argc, char*argv[]) { return 0; }
could overflow the stack.
You can take measures to reduce the likelihood of overflow, but there's
no easy way to know whether you've done enough. And doing enough on one
system might be a complete waste of time on others. The systems I use
most frequently allow me to put a gigabyte or more of data on the stack;
other systems are far more limited.
...
> Trying to solve a design problem by imposing artificial limitations
> seems a bad idea.
So what's the design solution you propose to "prevent overflow"?
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-05-06 02:53 +0100 |
| Message-ID | <0.d059e8eb09aad5ff3b6b.20110506025343BST.87k4e4387s.fsf@bsb.me.uk> |
| In reply to | #327 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 05/05/2011 03:24 PM, Kleuskes & Moos wrote:
>> On May 5, 11:37�am, 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 this
>>> 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.
>
> And how do you do that? If the stack size is sufficiently limited, even
>
> int main(int argc, char*argv[]) { return 0; }
>
> could overflow the stack.
Hmm... only in the most contrived implementation. The standard mandates
that an implementation must be able to translate and run at least one
program that is very much more complex than this. The system would have
to penalise simple, small programs deliberately!
It's a detail. I agree with your point that almost any call can be the
one that causes a stack overflow. Recursion need not be to blame.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-05-08 19:27 +0200 |
| Message-ID | <4dc6d253$0$18246$4fafbaef@reader2.news.tin.it> |
| In reply to | #328 |
"Ben Bacarisse" <ben.usenet@bsb.me.uk> ha scritto nel messaggio > It's a detail. I agree with your point that almost any call can be the > one that causes a stack overflow. Recursion need not be to blame. if you have one recursive function fun() that call itself, while it call itself "almost any call can be the cause of oveflow" is false because can cause the stack overflow the function fun() or the functions are called in fun() if someone know how many bytes each function called in fun() alloc from the stack, possibily, can estimate the right stack limit if it is know the stack limit of the program > <snip> > -- > Ben.
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2011-05-06 10:07 +0100 |
| Message-ID | <yw1xfwosjiyl.fsf@unicorn.mansr.com> |
| In reply to | #327 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 05/05/2011 03:24 PM, Kleuskes & Moos wrote:
>> On May 5, 11:37�am, 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 this
>>> 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.
>
> And how do you do that? If the stack size is sufficiently limited, even
>
> int main(int argc, char*argv[]) { return 0; }
>
> could overflow the stack.
> You can take measures to reduce the likelihood of overflow, but there's
> no easy way to know whether you've done enough. And doing enough on one
> system might be a complete waste of time on others. The systems I use
> most frequently allow me to put a gigabyte or more of data on the stack;
> other systems are far more limited.
Recursion or not isn't really important. What matters is having a
static bound on the amount of stack space required. Any design with
potentially unbounded stack usage (determined by runtime input) is
flawed since there is no way to reliably detect and recover from a stack
overflow.
--
Måns Rullgård
mans@mansr.com
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2011-05-06 10:29 +0100 |
| Message-ID | <yw1xbozgjhx1.fsf@unicorn.mansr.com> |
| In reply to | #333 |
ram@zedat.fu-berlin.de (Stefan Ram) writes: > Måns Rullgård <mans@mansr.com> writes: >>Recursion or not isn't really important. What matters is having a >>static bound on the amount of stack space required. > > In C, there is no »stack«. c.l.c, so predictable. -- Måns Rullgård mans@mansr.com
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-05-06 03:04 -0700 |
| Message-ID | <83b1e5e9-c208-43fc-a27e-2ce419790328@v8g2000yqb.googlegroups.com> |
| In reply to | #333 |
On May 6, 12:07 pm, Måns Rullgård <m...@mansr.com> wrote: > > Recursion or not isn't really important. What matters is having a > static bound on the amount of stack space required. Any design with > potentially unbounded stack usage (determined by runtime input) is > flawed since there is no way to reliably detect and recover from a stack > overflow. > The C that everyone uses doesn't allow variable-sized items to be placed on the stack. So you always know the maximum depth of the stack, unless you allow recursion. One of the main uses of recursion is to parse input data which is tree- like. So it's hard to add sensible bounds at programming time. The only real solution is to be able to rely on the compiler detecting stack overflow and not allowing for malicious exploits.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-06 06:33 -0400 |
| Message-ID | <iq0iqf$t3s$1@dont-email.me> |
| In reply to | #333 |
On 05/06/2011 05:07 AM, � wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>
>> On 05/05/2011 03:24 PM, Kleuskes & Moos wrote:
>>> On May 5, 11:37�am, 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 this
>>>> 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.
>>
>> And how do you do that? If the stack size is sufficiently limited, even
>>
>> int main(int argc, char*argv[]) { return 0; }
>>
>> could overflow the stack.
>> You can take measures to reduce the likelihood of overflow, but there's
>> no easy way to know whether you've done enough. And doing enough on one
>> system might be a complete waste of time on others. The systems I use
>> most frequently allow me to put a gigabyte or more of data on the stack;
>> other systems are far more limited.
>
> Recursion or not isn't really important. What matters is having a
> static bound on the amount of stack space required. Any design with
> potentially unbounded stack usage (determined by runtime input) is
> flawed since there is no way to reliably detect and recover from a stack
> overflow.
So, bounded recursion is fine? I'll have to agree, only an idiot would
attempt unbounded recursion.
The real problem is knowing whether or not the upper bound on stack
space is low enough. I have no idea how to determine that. Some highly
non-portable methods have been suggested in this thread. I assume that
they actually work, in the right environment. However, there's no
portable way to check it. That's equally true whether or not my program
uses recursion.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
Page 4 of 14 — ← Prev page 1 2 3 [4] 5 6 … 14 Next page →
Back to top | Article view | comp.unix.programmer
csiph-web