Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #3254 > unrolled thread
| Started by | boltar2003@boltar.world |
|---|---|
| First post | 2011-05-05 09:37 +0000 |
| Last post | 2011-05-11 03:43 -0700 |
| Articles | 20 on this page of 241 — 42 participants |
Back to article view | Back to comp.lang.c
Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 09:37 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? China Blue Veins <chine.bleu@yahoo.com> - 2011-05-05 02:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 09:58 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? China Blue Veins <chine.bleu@yahoo.com> - 2011-05-05 04:47 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-07 23:22 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-05 11:58 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-06 03:27 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-06 00:03 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 09:18 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-06 02:56 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-05 12:24 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Lowell Gilbert <lgusenet@be-well.ilk.org> - 2011-05-05 15:40 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:18 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-05 21:17 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-05-05 18:45 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:44 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 09:58 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Richard Kettlewell <rjk@greenend.org.uk> - 2011-05-06 11:11 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 10:16 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Richard Kettlewell <rjk@greenend.org.uk> - 2011-05-06 11:28 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:34 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-06 15:09 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 13:03 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 09:01 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 14:32 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-07 16:27 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 16:43 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-08 06:19 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-08 17:18 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-08 09:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-09 11:34 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-11 03:48 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-11 10:51 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-11 08:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-11 15:47 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-12 15:05 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-07 16:23 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 18:12 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 10:30 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:01 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 12:37 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 18:15 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-08 15:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 09:32 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-08 10:46 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 21:49 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 09:59 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 20:24 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-07 15:04 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 15:15 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 19:57 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 20:26 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 21:06 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-07 23:27 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-05 20:07 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-06 02:53 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 19:27 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-18 19:54 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-06 10:07 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 07:08 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 08:18 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Marco Parrone <marco@marcoparrone.com> - 2011-05-06 17:32 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 08:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 21:46 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 00:28 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-07 09:01 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 06:35 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-07 22:52 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 01:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-08 09:37 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-08 03:21 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Willem <willem@toad.stack.nl> - 2011-05-08 10:44 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 07:23 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-09 11:30 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-09 13:36 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-09 07:08 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 07:38 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 07:44 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-09 21:44 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 13:59 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 14:19 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 15:05 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 10:20 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 19:04 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-14 11:13 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-09 15:40 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-09 23:44 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 11:06 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-10 00:11 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 11:17 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-10 07:10 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 12:24 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-05-10 13:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:48 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:54 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-05-12 05:56 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 00:44 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 19:36 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 23:21 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 07:08 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-11 11:48 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 10:03 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 10:12 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 21:23 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-12 09:45 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:00 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:35 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-12 06:51 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-12 14:36 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-12 22:57 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-11 11:47 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:07 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-10 21:16 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-11 02:40 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 09:39 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:42 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-15 00:23 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? pacman@kosh.dhis.org (Alan Curry) - 2011-05-14 22:30 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-16 04:19 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-16 08:40 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-16 17:53 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-16 21:39 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 09:12 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-17 10:20 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-17 15:00 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? pacman@kosh.dhis.org (Alan Curry) - 2011-05-17 20:28 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 14:45 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 14:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-17 16:23 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-17 23:06 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-18 01:02 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-18 01:29 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-18 04:03 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Pfaff <blp@cs.stanford.edu> - 2011-05-17 16:47 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 17:21 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-23 21:57 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-23 21:57 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-23 17:45 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-24 11:43 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-24 10:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Sherm Pendley <sherm.pendley@gmail.com> - 2011-05-11 11:11 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:48 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-09 16:22 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 21:25 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Seebs <usenet-nospam@seebs.net> - 2011-05-10 17:28 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 17:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 12:20 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 03:53 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 20:18 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 04:42 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-10 09:12 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-10 03:21 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-10 10:53 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-10 08:12 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 09:39 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 12:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-11 08:12 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-10 15:16 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 19:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 07:41 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-11 12:45 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-10 07:50 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-10 11:04 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-08 09:27 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 08:04 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-08 22:50 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 00:18 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:49 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-08 20:05 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-08 13:44 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 00:22 -0700
Re: Avoiding recursive stack overflow in C? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-15 17:05 +0100
Re: Avoiding recursive stack overflow in C? James Kuyper <jameskuyper@verizon.net> - 2011-05-15 14:07 -0400
Re: Avoiding recursive stack overflow in C? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-15 22:49 +0100
Re: Avoiding recursive stack overflow in C? James Kuyper <jameskuyper@verizon.net> - 2011-05-15 21:08 -0400
Re: Avoiding recursive stack overflow in C? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-16 11:10 +0100
Re: Avoiding recursive stack overflow in C? Ilya Zakharevich <nospam-abuse@ilyaz.org> - 2011-05-16 08:04 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-05-07 19:11 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 07:17 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-05-08 10:16 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-09 09:03 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 08:59 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 03:01 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 07:13 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 09:02 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-06 15:41 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 02:53 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-07 16:17 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 10:08 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:20 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 14:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-07 14:31 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 22:49 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-07 17:22 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 10:24 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-07 17:32 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 11:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 10:57 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 08:09 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:41 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Shao Miller <sha0.miller@gmail.com> - 2011-05-07 21:35 -0500
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-08 23:31 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 00:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-09 08:39 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-09 09:03 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 10:06 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-09 17:52 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Herbert Rosenau" <os2guy@pc-rosenau.de> - 2011-05-10 11:20 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-08 17:59 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-09 09:01 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:41 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 12:48 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 11:01 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? gazelle@shell.xmission.com (Kenny McCormack) - 2011-05-08 13:10 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:51 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-08 22:21 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? gazelle@shell.xmission.com (Kenny McCormack) - 2011-06-04 12:54 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-06-04 12:59 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-06-07 06:30 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-06-10 21:56 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 13:53 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 15:16 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-07 23:42 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 19:37 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 07:17 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 09:24 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-08 10:36 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 13:29 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-08 00:28 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 23:06 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-08 07:30 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-08 15:51 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 13:33 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-14 11:08 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-14 15:53 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-10 22:14 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 11:08 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 08:15 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-11 03:43 -0700
Page 11 of 13 — ← Prev page 1 … 9 10 [11] 12 13 Next page →
| 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 | #3516 |
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 | #3528 |
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 | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-05-07 21:35 -0500 |
| Message-ID | <iq7ge8$gvu$1@dont-email.me> |
| In reply to | #3528 |
Kleuskes & Moos wrote: > > 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. Could you please confirm: Are you offering that in practice, it is best to avoid recursion? That's what I'm gathering since "stack" doesn't appear in n1256.pdf. We do get some limits from that draft's 5.2.4.1p1, including: - 127 nesting levels of blocks - 511 identifiers with block scope in one block - 127 arguments in one function call But I'm not sure if that helps us to control whether or not a C program would cause a problem if an implementation uses a stack for anything. If we have mission-critical code and do not use automatic objects at all, would that even help? Or might a particular C implementation still use a stack behind-the-scenes for something or another, and we might still run the risk of overflowing it? If we roll our own stack(s) and have stack_push() and stack_pop(), and those functions write their success/failure to a static object, then we could certainly avoid overflowing our custom stack(s), right? But are you advising that if it is known or suspected that the C implementation uses a stack for the operation of function calls, that such an implementation detail alone is enough reason to avoid recursion in mission-critical code, because C does not have a standard way to detect proximity to overflow of said stack? Would you be interested in C code which tries to avoid automatic objects and instead manage its memory resources very tightly? Do you already have code like that, that you're willing to share? As "un-C-like" as it might be to avoid the native calling features of C, perhaps there might still be some benefit to having such code, since C is so widely portable, thanks to its years of standardization efforts, and so audience-accessible, do you think? Thanks for the interesting read! :)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-05-08 23:31 -0700 |
| Message-ID | <f2241d7e-3aef-4d1d-b1ec-362b64d4b5b6@j31g2000yqe.googlegroups.com> |
| In reply to | #3566 |
On May 8, 5:35 am, Shao Miller <sha0.mil...@gmail.com> wrote: > Kleuskes & Moos wrote: > > But are you advising that if it is known or suspected that the C > implementation uses a stack for the operation of function calls, that > such an implementation detail alone is enough reason to avoid recursion > in mission-critical code, because C does not have a standard way to > detect proximity to overflow of said stack? > There's no way of implementing recursion without some sort of LIFO structure, which almost always is a stack. C implementations that don't use stacks usually don't support recursion. The problem is that if the stack overflows you get undefined behaviour, usually but not guaranteed to be a crash. There's a possibility of malicious exploits. For many applications it doesn't matter, but for many it does, notably safety-critical systems and popular mass-market applications. In reality I think almost everyone just sanity tests the depth of recursion.
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-09 00:26 -0700 |
| Message-ID | <4f16a6ee-6b09-42e0-aae6-83c30e989a51@m10g2000yqd.googlegroups.com> |
| In reply to | #3592 |
On May 9, 8:31 am, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote: > On May 8, 5:35 am, Shao Miller <sha0.mil...@gmail.com> wrote:> Kleuskes & Moos wrote: > > > But are you advising that if it is known or suspected that the C > > implementation uses a stack for the operation of function calls, that > > such an implementation detail alone is enough reason to avoid recursion > > in mission-critical code, because C does not have a standard way to > > detect proximity to overflow of said stack? > > There's no way of implementing recursion without some sort of LIFO > structure, which almost always is a stack. C implementations that > don't use stacks usually don't support recursion. > > The problem is that if the stack overflows you get undefined > behaviour, usually but not guaranteed to be a crash. There's a > possibility of malicious exploits. For many applications it doesn't > matter, but for many it does, notably safety-critical systems and > popular mass-market applications. In reality I think almost everyone > just sanity tests the depth of recursion. I could not have said it better than that. Thanx.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-09 08:39 -0700 |
| Message-ID | <lnfwonq3x4.fsf@nuthaus.mib.org> |
| In reply to | #3592 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On May 8, 5:35 am, Shao Miller <sha0.mil...@gmail.com> wrote:
>> Kleuskes & Moos wrote:
>>
>> But are you advising that if it is known or suspected that the C
>> implementation uses a stack for the operation of function calls, that
>> such an implementation detail alone is enough reason to avoid recursion
>> in mission-critical code, because C does not have a standard way to
>> detect proximity to overflow of said stack?
>>
> There's no way of implementing recursion without some sort of LIFO
> structure, which almost always is a stack. C implementations that
> don't use stacks usually don't support recursion.
What exactly do you mean by "stack"? One definition of "stack" is
a LIFO data structure, which makes your first statement trivially
true even without the "almost".
Another common meaning is a contiguous region of memory that grows
and shrinks in a particular direction, typically, but not always,
managed via a hardware "stack pointer" register. It's true that
most C implementations use this kind of stack, but not all do.
There have been C implementations in which the activation record for
each function call is allocated by a mechanism similar to malloc().
Such an implementation has a "stack" in the first sense, but not
in the second.
And an implementation that doesn't support recursion is not a C
implementation (though it might be C-like).
[...]
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-05-09 09:03 -0700 |
| Message-ID | <c62cc3f7-2d9d-477b-aa08-385382e11f4c@gh5g2000vbb.googlegroups.com> |
| In reply to | #3614 |
On May 9, 6:39 pm, Keith Thompson <ks...@mib.org> wrote: > Malcolm McLean <malcolm.mcle...@btinternet.com> writes: > > > There's no way of implementing recursion without some sort of LIFO > > structure, which almost always is a stack. C implementations that > > don't use stacks usually don't support recursion. > > What exactly do you mean by "stack"? One definition of "stack" is > a LIFO data structure, which makes your first statement trivially > true even without the "almost". > Yes, so here I obviously mean "stack" in the sense of contiguous area of memory with a pointer to the top. If C implementations don't use stacks, usually they write to fixed areas of memory, because they are running on tiny platforms with instruction sets that don't make indirect addressing easy. Recursion isn't supported, but normally processors like that only ever run one program in their useful life, which is likely to be controlling a digital display or something similar.
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-09 10:06 -0700 |
| Message-ID | <e8caae0b-749f-4a93-9f9b-456ad4cc1efb@w10g2000yqa.googlegroups.com> |
| In reply to | #3616 |
On May 9, 6:03 pm, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote: > On May 9, 6:39 pm, Keith Thompson <ks...@mib.org> wrote:> Malcolm McLean <malcolm.mcle...@btinternet.com> writes: > > > > There's no way of implementing recursion without some sort of LIFO > > > structure, which almost always is a stack. C implementations that > > > don't use stacks usually don't support recursion. > > > What exactly do you mean by "stack"? One definition of "stack" is > > a LIFO data structure, which makes your first statement trivially > > true even without the "almost". > > Yes, so here I obviously mean "stack" in the sense of contiguous area > of memory with a pointer to the top. > > If C implementations don't use stacks, usually they write to fixed > areas of memory, because they are running on tiny platforms with > instruction sets that don't make indirect addressing easy. Recursion > isn't supported, but normally processors like that only ever run one > program in their useful life, which is likely to be controlling a > digital display or something similar. Additionally: On large CPU's the stack is just a piece of memory. In microcontrollers (eg. PIC, 68HC11), the call-stack sometimes resides in a special registerfile and can be quite small, and may not even have the same width as the rest of the memory.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-09 17:52 -0400 |
| Message-ID | <iq9nmj$vse$1@dont-email.me> |
| In reply to | #3616 |
On 05/09/2011 12:03 PM, Malcolm McLean wrote: > On May 9, 6:39�pm, Keith Thompson <ks...@mib.org> wrote: >> Malcolm McLean <malcolm.mcle...@btinternet.com> writes: >> >>> There's no way of implementing recursion without some sort of LIFO >>> structure, which almost always is a stack. C implementations that >>> don't use stacks usually don't support recursion. >> >> What exactly do you mean by "stack"? �One definition of "stack" is >> a LIFO data structure, which makes your first statement trivially >> true even without the "almost". >> > Yes, so here I obviously mean "stack" in the sense of contiguous area > of memory with a pointer to the top. > > If C implementations don't use stacks, usually they write to fixed > areas of memory, because they are running on tiny platforms with > instruction sets that don't make indirect addressing easy. Recursion > isn't supported, ... So, as Keith said, those aren't actually C implementations. How should your comments be understood in the context of things which actually are C implementations, which don't use stacks, but instead rely upon activation records? -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Herbert Rosenau" <os2guy@pc-rosenau.de> |
|---|---|
| Date | 2011-05-10 11:20 +0000 |
| Message-ID | <wmzsGguTDN6N-pn2-rpOj0fGMdE7j@JUPITER.PC-ROSENAU.DE> |
| In reply to | #3566 |
On Sun, 8 May 2011 02:35:57 UTC, Shao Miller <sha0.miller@gmail.com> wrote: > Kleuskes & Moos wrote: > > > > 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. > > Could you please confirm: Are you offering that in practice, it is best > to avoid recursion? No. That's what I'm gathering since "stack" doesn't > appear in n1256.pdf. No wounder, as C does neither know what a stack is nor need a stack. -- Tschau/Bye Herbert Visit http://www.ecomstation.de the home of german eComStation eComStation 2.0 ist da!
[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 | #3438 |
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 | #3532 |
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 | #3433 |
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 | #3446 |
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 | #3447 |
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 | #3447 |
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]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2011-05-08 19:51 +0100 |
| Message-ID | <pan.2011.05.08.18.51.45.62000@nowhere.com> |
| In reply to | #3520 |
On Sun, 08 May 2011 13:10:41 +0000, Kenny McCormack wrote: > 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. Only if you consider programming to be an intellectual curiosity with no practical significance. To be of practical use, a program has to run on a real system which is bound to have implementation-specific behaviour.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2011-05-08 22:21 +0000 |
| Message-ID | <DHExp.72925$HX7.47300@news.usenetserver.com> |
| In reply to | #3548 |
Nobody <nobody@nowhere.com> writes: >On Sun, 08 May 2011 13:10:41 +0000, Kenny McCormack wrote: > >> 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. > >Only if you consider programming to be an intellectual curiosity with no >practical significance. To be of practical use, a program has to run on a >real system which is bound to have implementation-specific behaviour. > yep. Kenny seems to be of the oft-stated opinion that the only topic suitable for comp.lang.c is standard C (specifically discussions of the standard itself, rather than using the langauge) and I'm not sure that he is aware that for the most part, unix == linux from an application development standpoint. scott
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2011-06-04 12:54 +0000 |
| Message-ID | <isd9up$hk4$1@news.xmission.com> |
| In reply to | #3562 |
In article <DHExp.72925$HX7.47300@news.usenetserver.com>, Scott Lurndal <slp53@pacbell.net> wrote: ... >yep. Kenny seems to be of the oft-stated opinion that the only >topic suitable for comp.lang.c is standard C (specifically discussions >of the standard itself, rather than using the langauge) and I'm not >sure that he is aware that for the most part, unix == linux from an >application development standpoint. It ain't me, babe! (sing the rest of this old Turtles tune to yourself...) -- Is God willing to prevent evil, but not able? Then he is not omnipotent. Is he able, but not willing? Then he is malevolent. Is he both able and willing? Then whence cometh evil? Is he neither able nor willing? Then why call him God? ~ Epicurus
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-06-04 12:59 -0700 |
| Message-ID | <rubrum-3706B9.12593904062011@news.albasani.net> |
| In reply to | #5423 |
In article <isd9up$hk4$1@news.xmission.com>, gazelle@shell.xmission.com (Kenny McCormack) wrote: > In article <DHExp.72925$HX7.47300@news.usenetserver.com>, > Scott Lurndal <slp53@pacbell.net> wrote: > ... > >yep. Kenny seems to be of the oft-stated opinion that the only > >topic suitable for comp.lang.c is standard C (specifically discussions > >of the standard itself, rather than using the langauge) and I'm not > >sure that he is aware that for the most part, unix == linux from an > >application development standpoint. > > It ain't me, babe! > > (sing the rest of this old Turtles tune to yourself...) They might have covered it, but it ain't theirs, babe. -- Michael Press
[toc] | [prev] | [next] | [standalone]
Page 11 of 13 — ← Prev page 1 … 9 10 [11] 12 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web