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 4 of 13 — ← Prev page 1 2 3 [4] 5 6 … 13 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-06 07:08 -0400 |
| Message-ID | <iq0krm$kvl$1@dont-email.me> |
| In reply to | #3369 |
On 05/06/2011 05:58 AM, Kleuskes & Moos wrote:
> On 6 mei, 02:07, James Kuyper <jameskuy...@verizon.net> wrote:
>> 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.
>
> That would be _very_ bad design, omitting to consider the basic
> processing needs of the system.
>
>> You can take measures to reduce the likelihood of overflow, but there's
>> no easy way to know whether you've done enough.
>
> Nope, there isn't. But then again, there's no easy way to produce any
> software. Designing software _is_ hard and it will remain hard. Anyone
> offering an "easy" solution to this kind of considerartions is either
> a fool or a fraud.
I'm not complaining about it being too much work to deal with this
problem; I'm complaining about the fact that there's absolutely no
portable way to deal with it, at all. There's not too many non-portable
ways, either, and none that I'm aware of that are not prohibitively
expensive in terms of developer time.
>> And doing enough on one
>> system might be a complete waste of time on others.
>
> True. But then again, considering the platform(s) your software will
> run on is an integral part of the design process.
There are programs whose purpose is inherently platform specific;
failing to take into consideration platform-specific features is indeed
a design flaw for such programs. There are other programs, such as the
ones I work on, that are required to be portable to wide variety of
platforms.
My own programs are allowed to assume support for C90, a correspondingly
early version of POSIX, and three widely ported third-party libraries.
They are required to either work correctly or fail gracefully (if, for
instance, malloc() returns a null pointer) on any platform which meets
those requirements. Thankfully, one of those libraries (HDF) handles a
lot of the portability issues itself, freeing my code to concentrate on
other issues. If my code has to take into consideration
platform-specific characteristics that cannot be tested using code that
meets these requirements, then it has violated a design requirement.
It shouldn't be difficult to meet such a requirement. The fact that C
provides no mechanism for determining whether or not you can safely call
a particular function without overflowing the stack makes it
unnecessarily difficult to do so.
>> 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.
>
> Nice. So what?
So, it would be ridiculous to blindly prohibit the use of techniques
that take advantage of the capabilities of such platforms, just because
they won't work on other platforms. It's a problem with C (though it's
not unique to C) that it provides no way for my code to determine
whether it can safely take advantage of such capabilities.
>>> 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"?
>
> Avoid recursion if at all possible, for instance by using things like
> finite state machines for parsing data. Recursion is quite costly. I'm
> surprised i have to explain this in this forum.
>
> And no, it's not _always_ possible to avoid recursion, not is it
> _always_ wise to do so, but as a rule of thumb, it's good.
I'm not strongly tempted by recursion, except for traversal of certain
tree-like data structures - an issue which has seldom come up in my work.
But arbitrarily avoiding recursion makes as much sense to me as
arbitrarily avoiding binary trees, or any other design option.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-06 08:18 -0700 |
| Message-ID | <8cc03ab1-4ecf-4f0b-ab5c-29a0e0f008da@28g2000yqu.googlegroups.com> |
| In reply to | #3376 |
On May 6, 1:08 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> On 05/06/2011 05:58 AM, Kleuskes & Moos wrote:
> > On 6 mei, 02:07, James Kuyper <jameskuy...@verizon.net> wrote:
> >> 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.
>
> > That would be _very_ bad design, omitting to consider the basic
> > processing needs of the system.
>
> >> You can take measures to reduce the likelihood of overflow, but there's
> >> no easy way to know whether you've done enough.
>
> > Nope, there isn't. But then again, there's no easy way to produce any
> > software. Designing software _is_ hard and it will remain hard. Anyone
> > offering an "easy" solution to this kind of considerartions is either
> > a fool or a fraud.
>
> I'm not complaining about it being too much work to deal with this
> problem; I'm complaining about the fact that there's absolutely no
> portable way to deal with it, at all. There's not too many non-portable
> ways, either, and none that I'm aware of that are not prohibitively
> expensive in terms of developer time.
Of course there are portable ways of dealing with it. For instance:
it's simple enough to pass long an extra integer parameter and
decrementing some initial setting on every recursion. If the counter
reaches zero, print an error message and abort. Portable as hell. The
only thing you need to take a stab at are sensible initial values,
high enough to allow wellbehaved programs to run, but low enough not
to allow runaway recursion to blast the stack to kingdom come.
> >> And doing enough on one
> >> system might be a complete waste of time on others.
>
> > True. But then again, considering the platform(s) your software will
> > run on is an integral part of the design process.
>
> There are programs whose purpose is inherently platform specific;
> failing to take into consideration platform-specific features is indeed
> a design flaw for such programs. There are other programs, such as the
> ones I work on, that are required to be portable to wide variety of
> platforms.
Which is difficult and takes different and way more consideration of
the platforms involved.
> My own programs are allowed to assume support for C90, a correspondingly
> early version of POSIX, and three widely ported third-party libraries.
> They are required to either work correctly or fail gracefully (if, for
> instance, malloc() returns a null pointer) on any platform which meets
> those requirements. Thankfully, one of those libraries (HDF) handles a
> lot of the portability issues itself, freeing my code to concentrate on
> other issues. If my code has to take into consideration
> platform-specific characteristics that cannot be tested using code that
> meets these requirements, then it has violated a design requirement.
Wonderful. Sounds like you're doing your job. I wasn't talking about
introducing anything platform specific, though. Hence the '(s)' at the
end of 'platform(s)'. And judging by what you write, you ponder your
target platforms as diligently as any good programmer would. Otherwise
your would not choose C90.
> It shouldn't be difficult to meet such a requirement. The fact that C
> provides no mechanism for determining whether or not you can safely call
> a particular function without overflowing the stack makes it
> unnecessarily difficult to do so.
>
> >> 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.
>
> > Nice. So what?
>
> So, it would be ridiculous to blindly prohibit the use of techniques
> that take advantage of the capabilities of such platforms, just because
> they won't work on other platforms.
Replacing a recursive algorithm with a non-recursive one is not
detrimental to performance on high-volume machines. In fact, it may
improve performance quite dramatically, depending on what gets
replaced with what.
Besides, i'm not 'prohibiting' anything, 'blindly' or otherwise. I'm
providing a simple bit of advice: 'lay off recursion, if at all
possible. Often, there are other ways'.
> It's a problem with C (though it's
> not unique to C) that it provides no way for my code to determine
> whether it can safely take advantage of such capabilities.
So pick another language. Besides, you realize that you are argueing
my point? That is if 'such capabilities' did indeed refer to
'employing recursion safely'.
Depending on your definition of 'safety' recursion can be safely
employed. If the greatest risk you run is getting a SIGSEGV and you
and your customer can live with that, recursion isn't really a
problem, especially since the risk of an actual stack-overflow and
consequent SIGSEGV is mostly hypothetical in many cases.
In other cases, it may kill someone.
> >>> 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"?
>
> > Avoid recursion if at all possible, for instance by using things like
> > finite state machines for parsing data. Recursion is quite costly. I'm
> > surprised i have to explain this in this forum.
>
> > And no, it's not _always_ possible to avoid recursion, not is it
> > _always_ wise to do so, but as a rule of thumb, it's good.
>
> I'm not strongly tempted by recursion, except for traversal of certain
> tree-like data structures - an issue which has seldom come up in my work.
>
> But arbitrarily avoiding recursion makes as much sense to me as
> arbitrarily avoiding binary trees, or any other design option.
The word "arbitrarily" should be taken out of that sentence and shot
at dawn. That's the second time your argumen is maily in the
adjectives and i resent that. There is nothing arbitrary about it.
[toc] | [prev] | [next] | [standalone]
| From | Marco Parrone <marco@marcoparrone.com> |
|---|---|
| Date | 2011-05-06 17:32 +0200 |
| Message-ID | <m3hb97lu9i.fsf@marcoparrone.com> |
| In reply to | #3382 |
"Kleuskes & Moos" <kleuske@xs4all.nl> writes: > On May 6, 1:08 pm, James Kuyper <jameskuy...@verizon.net> wrote: >> >>> 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"? >> >> > Avoid recursion if at all possible, for instance by using things like >> > finite state machines for parsing data. Recursion is quite costly. I'm >> > surprised i have to explain this in this forum. >> >> > And no, it's not _always_ possible to avoid recursion, not is it >> > _always_ wise to do so, but as a rule of thumb, it's good. >> >> I'm not strongly tempted by recursion, except for traversal of certain >> tree-like data structures - an issue which has seldom come up in my work. >> >> But arbitrarily avoiding recursion makes as much sense to me as >> arbitrarily avoiding binary trees, or any other design option. > > The word "arbitrarily" should be taken out of that sentence and shot > at dawn. That's the second time your argumen is maily in the > adjectives and i resent that. There is nothing arbitrary about it. What about tail-calls? Sure not all recursive functions use tail-calls, but for tail-calls gcc (and I guess other good compilers) do tail-call-optimization. Can they be considered safe? -- Marco Parrone <marco@marcoparrone.com> PGP Key fingerprint = 5E21 BED2 BF47 B3FB F17F 1DB4 D9BE B2B7 3C3A 07E2
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-06 08:51 -0700 |
| Message-ID | <c2ac827f-2e79-4b36-a48f-e140e4b28c79@m10g2000yqd.googlegroups.com> |
| In reply to | #3383 |
On May 6, 5:32 pm, Marco Parrone <ma...@marcoparrone.com> wrote: > "Kleuskes & Moos" <kleu...@xs4all.nl> writes: > > > > > > > > > > > On May 6, 1:08 pm, James Kuyper <jameskuy...@verizon.net> wrote: > >> >>> 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"? > > >> > Avoid recursion if at all possible, for instance by using things like > >> > finite state machines for parsing data. Recursion is quite costly. I'm > >> > surprised i have to explain this in this forum. > > >> > And no, it's not _always_ possible to avoid recursion, not is it > >> > _always_ wise to do so, but as a rule of thumb, it's good. > > >> I'm not strongly tempted by recursion, except for traversal of certain > >> tree-like data structures - an issue which has seldom come up in my work. > > >> But arbitrarily avoiding recursion makes as much sense to me as > >> arbitrarily avoiding binary trees, or any other design option. > > > The word "arbitrarily" should be taken out of that sentence and shot > > at dawn. That's the second time your argumen is maily in the > > adjectives and i resent that. There is nothing arbitrary about it. > > What about tail-calls? Sure not all recursive functions use tail-calls, > but for tail-calls gcc (and I guess other good compilers) do > tail-call-optimization. Can they be considered safe? Who do you think i am? The Omniscient Oracle of C-Implementations? well i'm not. If tail-recursion can be optimized away, then i guess it should be no problem on platforms that actually do that. But if portability is a issue, then it may produces a lot of other headaches, since not ll compiler may support it, or support it in a subtly different way. RTFM, would be my advice, and use your own brain instead of mine.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-06 21:46 -0400 |
| Message-ID | <iq28ac$1nm$1@dont-email.me> |
| In reply to | #3382 |
On 05/06/2011 11:18 AM, Kleuskes & Moos wrote: > On May 6, 1:08�pm, James Kuyper <jameskuy...@verizon.net> wrote: ... >> I'm not complaining about it being too much work to deal with this >> problem; I'm complaining about the fact that there's absolutely no >> portable way to deal with it, at all. There's not too many non-portable >> ways, either, and none that I'm aware of that are not prohibitively >> expensive in terms of developer time. > > Of course there are portable ways of dealing with it. For instance: > it's simple enough to pass long an extra integer parameter and > decrementing some initial setting on every recursion. If the counter > reaches zero, print an error message and abort. Portable as hell. That has nothing to do with the issue I was referring to. > ... The > only thing you need to take a stab at are sensible initial values, That is the issue I was referring to: there's so portable solution to determining what initial values are "sensible". >> My own programs are allowed to assume support for C90, a correspondingly >> early version of POSIX, and three widely ported third-party libraries. >> They are required to either work correctly or fail gracefully (if, for >> instance, malloc() returns a null pointer) on any platform which meets >> those requirements. Thankfully, one of those libraries (HDF) handles a >> lot of the portability issues itself, freeing my code to concentrate on >> other issues. If my code has to take into consideration >> platform-specific characteristics that cannot be tested using code that >> meets these requirements, then it has violated a design requirement. > > Wonderful. Sounds like you're doing your job. I wasn't talking about > introducing anything platform specific, though. ... Any non-zero "sensible initial value' is definitely platform specific. > ... Hence the '(s)' at the > end of 'platform(s)'. And judging by what you write, you ponder your > target platforms as diligently as any good programmer would. Otherwise > your would not choose C90. Don't give me the credit for that decision; it was made by our clients at a time when C90 was half the age that C99 is now. At the time they made that choice, C90 was substantially more widely supported than C99 is now, but it was still a decision that cost them significant portability at that time. If it were up to me, right now, I'd choose C99 and C++98. >>>> 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. >> >>> Nice. So what? >> >> So, it would be ridiculous to blindly prohibit the use of techniques >> that take advantage of the capabilities of such platforms, just because >> they won't work on other platforms. > > Replacing a recursive algorithm with a non-recursive one is not > detrimental to performance on high-volume machines. In fact, it may > improve performance quite dramatically, depending on what gets > replaced with what. The main reason I'd go for a recursive algorithm, when appropriate, would be maintainability, not performance, because the code would be easier to write and easier to read. My comments about those platform-specific capabilities is that I don't like being forced away from that choice by reason of the existence of platforms where there wasn't enough stack to support the recursion, unless it's actually necessary to port my code to such platforms. > Besides, i'm not 'prohibiting' anything, 'blindly' or otherwise. I'm > providing a simple bit of advice: 'lay off recursion, if at all > possible. Often, there are other ways'. Your use of "if at all possible" is a bit disingenuous. As I'm sure you already know, it's always possible to avoid recursion; it's never a mandatory approach - just a convenient one. >> It's a problem with C (though it's >> not unique to C) that it provides no way for my code to determine >> whether it can safely take advantage of such capabilities. > > So pick another language. I'm not aware of any other language that provides a mechanism for avoiding or dealing with this problem, either. There might be one, but I don't know it's name. > ... Besides, you realize that you are argueing > my point? That is if 'such capabilities' did indeed refer to > 'employing recursion safely'. I was thinking more broadly than that: "employing function calls safely". C provides no mechanism for determining whether or not there's enough stack left to safely call any function - recursively or not - note even the initial call to main(). Nor does it provide a mechanism for dealing with the consequences, if there's not enough stack. As I said above, I don't know of any other language that provides such mechanisms, either. ... >> But arbitrarily avoiding recursion makes as much sense to me as >> arbitrarily avoiding binary trees, or any other design option. > > The word "arbitrarily" should be taken out of that sentence and shot > at dawn. That's the second time your argumen is maily in the > adjectives and i resent that. There is nothing arbitrary about it. Your choice seems insufficiently motivated to me; "arbitrary" is a fine word for conveying that judgment. It might be a mistaken judgment, but then the fault is in the judgment, not in the word used to express it. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-07 00:28 -0700 |
| Message-ID | <4b2830f1-dce5-4605-a99a-663af3a5be1d@35g2000yqy.googlegroups.com> |
| In reply to | #3401 |
On May 7, 3:46 am, James Kuyper <jameskuy...@verizon.net> wrote: > On 05/06/2011 11:18 AM, Kleuskes & Moos wrote: > > > On May 6, 1:08 pm, James Kuyper <jameskuy...@verizon.net> wrote: > ... > >> I'm not complaining about it being too much work to deal with this > >> problem; I'm complaining about the fact that there's absolutely no > >> portable way to deal with it, at all. There's not too many non-portable > >> ways, either, and none that I'm aware of that are not prohibitively > >> expensive in terms of developer time. > > > Of course there are portable ways of dealing with it. For instance: > > it's simple enough to pass long an extra integer parameter and > > decrementing some initial setting on every recursion. If the counter > > reaches zero, print an error message and abort. Portable as hell. > > That has nothing to do with the issue I was referring to. In that case, you failed to make it clear what you were talking about. I took it to be "applying recursion safely", but if it did not, please... > > ... The > > only thing you need to take a stab at are sensible initial values, > > That is the issue I was referring to: there's so portable solution to > determining what initial values are "sensible". Usually there are. You can inspect the application domain and make an estimate how deep the recursion could sensibly be. It is application dependent, but then again, any software is application specific. <snip> > Any non-zero "sensible initial value' is definitely platform specific. Nope, it's application specific, and merely assumes the platform has enough memory to cope, and that's an assumption inherent to any program, even your ultra-portable stuff. If you're not capable of making an estimate of the maximum depth of reccusion which will occur and how that jives with your target platforms, every installation of your software is equivalent to just rolling the dice. And you don't strike me as a gambler. You rely on SIGSEGV so cap it, I suggest you cap it yourself, since SIGSEGV is a luxury item on many platforms. > > ... Hence the '(s)' at the > > end of 'platform(s)'. And judging by what you write, you ponder your > > target platforms as diligently as any good programmer would. Otherwise > > your would not choose C90. > > Don't give me the credit for that decision; it was made by our clients > at a time when C90 was half the age that C99 is now. At the time they > made that choice, C90 was substantially more widely supported than C99 > is now, but it was still a decision that cost them significant > portability at that time. If it were up to me, right now, I'd choose C99 > and C++98. And why? Perhaps because you know that version is supported on all your target platforms? If you're not sure that it's supported across all your targets, your choice would be irresponsable, and you do not strike me as being that. Besides, my point was only to note that target platforms must be considered, and i consider it made and acknowledged. <snip> > > Replacing a recursive algorithm with a non-recursive one is not > > detrimental to performance on high-volume machines. In fact, it may > > improve performance quite dramatically, depending on what gets > > replaced with what. > > The main reason I'd go for a recursive algorithm, when appropriate, > would be maintainability, not performance, because the code would be > easier to write and easier to read. My comments about those > platform-specific capabilities is that I don't like being forced away > from that choice by reason of the existence of platforms where there > wasn't enough stack to support the recursion, unless it's actually > necessary to port my code to such platforms. Nobody's forcing anybody. You're right o consider readability and maintainability important objectives. As a matter of fact, so do i. However in my experience, the difference between recursive and non- recursive algorithm's isn't that big. Unless of course you merely produce a kludge instead of a design. > > Besides, i'm not 'prohibiting' anything, 'blindly' or otherwise. I'm > > providing a simple bit of advice: 'lay off recursion, if at all > > possible. Often, there are other ways'. > > Your use of "if at all possible" is a bit disingenuous. As I'm sure you > already know, it's always possible to avoid recursion; it's never a > mandatory approach - just a convenient one. Perhaps, and i tend to disagree without your providing some sort of proof for that suggested theorem. It' also a costly and (at times) risky one. For the reasons me, you and others have already mentioned. The risk is in fact what gave rise to this thread. The advice i provided still seems reasonable. > >> It's a problem with C (though it's > >> not unique to C) that it provides no way for my code to determine > >> whether it can safely take advantage of such capabilities. > > > So pick another language. > > I'm not aware of any other language that provides a mechanism for > avoiding or dealing with this problem, either. There might be one, but I > don't know it's name. So why say it's a problem with 'C', when in fact it's a problem in any given language you know of? > > ... Besides, you realize that you are argueing > > my point? That is if 'such capabilities' did indeed refer to > > 'employing recursion safely'. > > I was thinking more broadly than that: "employing function calls > safely". Oh, wow... > C provides no mechanism for determining whether or not there's > enough stack left to safely call any function - recursively or not - > note even the initial call to main(). Nor does it provide a mechanism > for dealing with the consequences, if there's not enough stack. > As I said above, I don't know of any other language that provides such > mechanisms, either. C does not have a mechanism to guarantee 'any' statement will execute successfully. Nor does any other (compiled) language. In interpreted languages, however, it's a doddle. But then again, the interpreter for such a language is compiled and so the problem is merely shifted. Is there a point in any of this, or are you merely providing verbal foliage? > >> But arbitrarily avoiding recursion makes as much sense to me as > >> arbitrarily avoiding binary trees, or any other design option. > > > The word "arbitrarily" should be taken out of that sentence and shot > > at dawn. That's the second time your argumen is maily in the > > adjectives and i resent that. There is nothing arbitrary about it. > > Your choice seems insufficiently motivated to me; "arbitrary" is a fine > word for conveying that judgment. It might be a mistaken judgment, but > then the fault is in the judgment, not in the word used to express it. Well, pigheadedness seems a nice word to describe my judgment, so i'll guess i'll use that. Have a nice day. Remind me never to buy your software.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-07 09:01 -0400 |
| Message-ID | <iq3fs7$pc7$1@dont-email.me> |
| In reply to | #3402 |
On 05/07/2011 03:28 AM, Kleuskes & Moos wrote: > On May 7, 3:46�am, James Kuyper <jameskuy...@verizon.net> wrote: >> On 05/06/2011 11:18 AM, Kleuskes & Moos wrote: >> >>> On May 6, 1:08 pm, James Kuyper <jameskuy...@verizon.net> wrote: ... >>> ... The >>> only thing you need to take a stab at are sensible initial values, >> >> That is the issue I was referring to: there's so portable solution to >> determining what initial values are "sensible". > > Usually there are. You can inspect the application domain and make an > estimate how deep the recursion could sensibly be. It is application > dependent, but then again, any software is application specific. If your application must run on a given platform, and that platform doesn't provide enough room on the stack to handle the worst case, it would be helpful to have some way of detecting, from within the program, that it is in fact the worst case - before it causes your program to abort. That is just as much a problem with recursive solutions, as non-recursive ones. ... > And you don't strike me as a gambler. You rely on SIGSEGV so cap it, I > suggest you cap it yourself, since SIGSEGV is a luxury item on many > platforms. I don't rely on SIGSEGV. Among the restrictions placed on my code by our client is a prohibition on using the features of <signal.h>. My code has to play nicely with a library provided by another vendor, and that library presumably (I've never checked) does things with signals that my code is not allowed to interfere with. ... >>>> It's a problem with C (though it's >>>> not unique to C) that it provides no way for my code to determine >>>> whether it can safely take advantage of such capabilities. >> >>> So pick another language. >> >> I'm not aware of any other language that provides a mechanism for >> avoiding or dealing with this problem, either. There might be one, but I >> don't know it's name. > > So why say it's a problem with 'C', when in fact it's a problem in any > given language you know of? Yes. The fact that it's a problem with every language I know of implies, in particular, that it is a problem with C. There's no contradiction there, and I even emphasized precisely that point by saying "(though it's not unique to C)". ... > Have a nice day. Remind me never to buy your software. You can't buy it - it's only available for free - another requirement imposed by our client. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-07 06:35 -0700 |
| Message-ID | <c8e8e850-aa1a-4dd3-9f58-94ed708d25a8@z13g2000yqg.googlegroups.com> |
| In reply to | #3415 |
On May 7, 3:01 pm, James Kuyper <jameskuy...@verizon.net> wrote: > On 05/07/2011 03:28 AM, Kleuskes & Moos wrote: > > > On May 7, 3:46 am, James Kuyper <jameskuy...@verizon.net> wrote: > >> On 05/06/2011 11:18 AM, Kleuskes & Moos wrote: > > >>> On May 6, 1:08 pm, James Kuyper <jameskuy...@verizon.net> wrote: > ... > >>> ... The > >>> only thing you need to take a stab at are sensible initial values, > > >> That is the issue I was referring to: there's so portable solution to > >> determining what initial values are "sensible". > > > Usually there are. You can inspect the application domain and make an > > estimate how deep the recursion could sensibly be. It is application > > dependent, but then again, any software is application specific. > > If your application must run on a given platform, and that platform > doesn't provide enough room on the stack to handle the worst case, it > would be helpful to have some way of detecting, from within the program, > that it is in fact the worst case - before it causes your program to > abort. That is just as much a problem with recursive solutions, as > non-recursive ones. Sure, and theres a slew of profilers and other nifty gadgets around that will help you with such problems. That's still at compile time, but if you need to inspect such things at runtime, either the design (and with that, the hardware restrictions such as minimum required memory size) or the implementation is seriously flawed. In non-recursive software, the problem is relatively easily solved using such tools, recursive software is a bit more tricky, since you CANNOT calculate a maximum call-tree height in advance. Hence my suggestion not to use recursive algorithms, if you can avoid it. > > And you don't strike me as a gambler. You rely on SIGSEGV so cap it, I > > suggest you cap it yourself, since SIGSEGV is a luxury item on many > > platforms. > > I don't rely on SIGSEGV. Among the restrictions placed on my code by our > client is a prohibition on using the features of <signal.h>. Let me see if i got that straight... You've been arguing that there's no portable way to cap recursion and a runaway recursive process will overflow the stack, resulting in a SIGSEGV... That means the only cap placed on recursion in such a case is the kernel THROWING a SIGSEGV. This will terminate the process in question quite effectively, but not to the liking f your client, i imagine. > My code has > to play nicely with a library provided by another vendor, and that > library presumably (I've never checked) does things with signals that my > code is not allowed to interfere with. I guess it's more a question of portability, even the POSIX standard leaves room for variation across platforms, so using <signal.h> would be a major liability if portability is a major concern. <snip> > > So why say it's a problem with 'C', when in fact it's a problem in any > > given language you know of? > > Yes. The fact that it's a problem with every language I know of implies, > in particular, that it is a problem with C. There's no contradiction > there, and I even emphasized precisely that point by saying "(though > it's not unique to C)". It's like telling a man "the problem with this car is that you might run out of gas driving it, if you don't pay attention to the fuel- gauge". No contradiction, but that doesn't mean nothing is wrong with it. > > Have a nice day. Remind me never to buy your software. > > You can't buy it - it's only available for free - another requirement > imposed by our client. I like your client.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-07 22:52 -0400 |
| Message-ID | <iq50gu$46r$1@dont-email.me> |
| In reply to | #3417 |
On 05/07/2011 09:35 AM, Kleuskes & Moos wrote: > On May 7, 3:01�pm, James Kuyper <jameskuy...@verizon.net> wrote: >> On 05/07/2011 03:28 AM, Kleuskes & Moos wrote: ... >>> And you don't strike me as a gambler. You rely on SIGSEGV so cap it, I >>> suggest you cap it yourself, since SIGSEGV is a luxury item on many >>> platforms. >> >> I don't rely on SIGSEGV. Among the restrictions placed on my code by our >> client is a prohibition on using the features of <signal.h>. > > Let me see if i got that straight... You've been arguing that there's > no portable way to cap recursion and a runaway recursive process will Nor any portable way to cap non-recursive function calls that overflow the stack, either. My complaint has nothing to do with recursion; which is really the point of my objection to your objections to recursion - the problem you're trying to avoid cannot be absolutely avoided in any context; and it can be avoided (with less than absolute success) for recursive programs just as it can be with non-recursive ones. > overflow the stack, resulting in a SIGSEGV... Not necessarily; that's just what happens on systems which have SIGSEGV, or some equivalent mechanism. > That means the only cap placed on recursion in such a case is the > kernel THROWING a SIGSEGV. This will terminate the process in question > quite effectively, but not to the liking f your client, i imagine. I'm commenting on two entirely distinct issues. 1. The lack of any portable way for a C code to avoid making a function call that requires more stack space than is currently available; there's not even a portable way to recover from the fact that such a call was made, which would be a markedly inferior solution to this problem. Handling a SIGSEGV is indeed an example of such an inferior solution, but it's not mandated by the C standard. 2. You made a comment about me relying on SIGSEGV; I don't, and I explained why I can't; but this is only a side issue, not directly relevant to the first point. My first point would still apply even if I had no such restrictions placed on my code, and even if it ran on a platform which misbehaved in some entirely different way when it ran out of automatically allocated memory. It doesn't even matter whether or not it uses a stack to provide that memory, or some other mechanism, such as activation records. >>> So why say it's a problem with 'C', when in fact it's a problem in any >>> given language you know of? >> >> Yes. The fact that it's a problem with every language I know of implies, >> in particular, that it is a problem with C. There's no contradiction >> there, and I even emphasized precisely that point by saying "(though >> it's not unique to C)". > > It's like telling a man "the problem with this car is that you might > run out of gas driving it, if you don't pay attention to the fuel- > gauge". No contradiction, but that doesn't mean nothing is wrong with > it. Every car I've looked at since my second car search, about 1994, has had as standard equipment either a buzzer or a flashing light (usually both) that would provided advance warning if the fuel level was too low. I would in fact consider any car lacking such warning mechanisms to be seriously defective. Where's the buzzer/warning light for approaching the stack limits in C? The non-portable best that I can do is handling SIGSEGV, which is a little late; the problem I wanted to avoid has already happened by the time that signal is raised. For that matter, I'd settle for the analog of a gas gauge - where can I find it? I don't want to make this sound like more of a problem than it really is; I've been writing programs in C for 30 years now despite the lack of this feature - it hasn't stopped me, and has only occasionally slowed me down. However, but I'm aware of the problems that the lack of such a feature can cause, and of my helplessness in dealing with those problems. My point is that recursive code makes only a quantitative difference in how difficult it is to avoid such problems; it's not a fundamental qualitative difference. The improvement in the maintainability of the code because of the use of a recursive algorithm can easily be sufficient to make up for that difference. Your advice to "avoid recursion, if at all possible" is an overreaction. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-08 01:26 -0700 |
| Message-ID | <8b83b86f-2e67-474f-ac0e-62bddb0c3d1d@u16g2000yqj.googlegroups.com> |
| In reply to | #3477 |
On May 8, 4:52 am, James Kuyper <jameskuy...@verizon.net> wrote: > On 05/07/2011 09:35 AM, Kleuskes & Moos wrote: > > > On May 7, 3:01 pm, James Kuyper <jameskuy...@verizon.net> wrote: > >> On 05/07/2011 03:28 AM, Kleuskes & Moos wrote: > ... > >>> And you don't strike me as a gambler. You rely on SIGSEGV so cap it, I > >>> suggest you cap it yourself, since SIGSEGV is a luxury item on many > >>> platforms. > > >> I don't rely on SIGSEGV. Among the restrictions placed on my code by our > >> client is a prohibition on using the features of <signal.h>. > > > Let me see if i got that straight... You've been arguing that there's > > no portable way to cap recursion and a runaway recursive process will > > Nor any portable way to cap non-recursive function calls that overflow > the stack, either. Of course there is. Do not make the call-tree big enough to do that, and if there's no recursion involved, it's rather easy to derive a max stack size and put it in your hardware requirements. > My complaint has nothing to do with recursion; which > is really the point of my objection to your objections to recursion - > the problem you're trying to avoid cannot be absolutely avoided in any > context; and it can be avoided (with less than absolute success) for > recursive programs just as it can be with non-recursive ones. So, basically, you're saying, since your cannot avoid it absolutely anyway, all advice is useless, and it's OK to use tail-recursion to skip through a 2 Mb file. Ok. > > overflow the stack, resulting in a SIGSEGV... > > Not necessarily; that's just what happens on systems which have SIGSEGV, > or some equivalent mechanism. Aye. And on systems that haven't got it, results are undefined and (under some circumstances) may kill someone. As i said, a SIGSEGV is a luxury item, if you overflow he stack and your system does NOT signal a segfault, you're in even more trouble. Or rather, the poor sod who's using your software is in deep shit. You're like a mechanic telling me how brakes are useless since they cannot guarantee that you won't run into anything, anyway. Even when applying the brakes, you can still run over a pedestrian or a 20-ton truck, so basically brakes are useless. > > That means the only cap placed on recursion in such a case is the > > kernel THROWING a SIGSEGV. This will terminate the process in question > > quite effectively, but not to the liking f your client, i imagine. > > I'm commenting on two entirely distinct issues. > > 1. The lack of any portable way for a C code to avoid making a function > call that requires more stack space than is currently available; there's > not even a portable way to recover from the fact that such a call was > made, which would be a markedly inferior solution to this problem. > Handling a SIGSEGV is indeed an example of such an inferior solution, > but it's not mandated by the C standard. Nope, it's mandated by the POSIX standard instead. But i'm getting curious, pray describe the superior solution you have in mind. Secondly if you are making function calls that exhaust the stack (this time in one go, apparently) either the software you write is pretty shitty or the platform you're running it on is not suited to your software and your analysis was pretty shitty. > 2. You made a comment about me relying on SIGSEGV; I don't, and I > explained why I can't; but this is only a side issue, not directly > relevant to the first point. Ok. So you have different ways of dealing with a stack-overflow. Again i'm curious how you do that. Portably, since you've stressed the importance of that quality in your software. > My first point would still apply even if I > had no such restrictions placed on my code, and even if it ran on a > platform which misbehaved in some entirely different way when it ran out > of automatically allocated memory. Ok. lets say that if your software crashes, chances are someone gets killed. It may seem ridiculous to you, but on one of the projects i worked on, that was a possible consequence. The project employed 16kB of ROM and 16kB of RAM, has a clock-frequency of 1-kHz and needs to run for 10 years on a single battery charge. So your point applies, and i can't guarantee that a single function- call won't crash the system. Mission impossible? Mission irresponsable? What alternatives do you have? I'm just glad i _can_ guarantee it does not run out of stack space, since the call-tree wasn't that high. > It doesn't even matter whether or not > it uses a stack to provide that memory, or some other mechanism, such as > activation records. I'm getting curious again, what sort of killer-functioncall did you have in mind? Something which allocates a 2Gb array on stack and passes it around by value? If that's the case, your design stinks. > >>> So why say it's a problem with 'C', when in fact it's a problem in any > >>> given language you know of? > > >> Yes. The fact that it's a problem with every language I know of implies, > >> in particular, that it is a problem with C. There's no contradiction > >> there, and I even emphasized precisely that point by saying "(though > >> it's not unique to C)". > > > It's like telling a man "the problem with this car is that you might > > run out of gas driving it, if you don't pay attention to the fuel- > > gauge". No contradiction, but that doesn't mean nothing is wrong with > > it. > > Every car I've looked at since my second car search, about 1994, has had > as standard equipment either a buzzer or a flashing light (usually both) > that would provided advance warning if the fuel level was too low. I > would in fact consider any car lacking such warning mechanisms to be > seriously defective. That wasn't the point. > Where's the buzzer/warning light for approaching the stack limits in C? If your design is good, you don't need one. If you feel you need one, C is not the language for you. > The non-portable best that I can do is handling SIGSEGV, which is a > little late; the problem I wanted to avoid has already happened by the > time that signal is raised. True. And catching a SIGSEGV isn't a good idea, unless you're writing a debugger. The only portable option (and it's been dubbed a kludge) is to keep track of recursions manually and implement the damn buzzer yourself. A better solution is to avoid that kind of situation in the first place. Laying off recursion goes a long way of achieving that. > For that matter, I'd settle for the analog of a gas gauge - where can I > find it? Again, if you feel you need thngs like that, C is not the language for you. Get used to doing you thinking in design-time instead of at run- time. > I don't want to make this sound like more of a problem than it really > is; I've been writing programs in C for 30 years now despite the lack of > this feature - it hasn't stopped me, and has only occasionally slowed me > down. Glad to hear that. > However, but I'm aware of the problems that the lack of such a > feature can cause, and of my helplessness in dealing with those problems. You're NOT helpless. You're merely LATE. > My point is that recursive code makes only a quantitative difference in > how difficult it is to avoid such problems; it's not a fundamental > qualitative difference. It's perhaps the difference between p=1E10-6 and 0.9, which makes it a pretty big quantitative difference. And again, with proper analysis beforehand (and that has been my job for a number of years) you can reduce it to p=0, which makes it a quantitative difference. > The improvement in the maintainability of the > code because of the use of a recursive algorithm can easily be > sufficient to make up for that difference. Perhaps on your job. As i mentioned earlier, if you and your customer can live with the occasional crash, there's no real problem. But that's your design choice. > Your advice to "avoid recursion, if at all possible" is an overreaction. In the thread at hand, which started with someone being worried about stack overflow, it still makes more sense than your "It's the fault of C for not providing me with a buzzer, flashing lights and a fuel- gauge. there's nothing you can do about it, so live with it and recurse the hell out of your processor, since it's much easier that way." So i'll stick with my advice, thank-you-very-much.
[toc] | [prev] | [next] | [standalone]
| From | Dr Nick <3-nospam@temporary-address.org.uk> |
|---|---|
| Date | 2011-05-08 09:37 +0100 |
| Message-ID | <87zkmxlh9b.fsf@temporary-address.org.uk> |
| In reply to | #3508 |
"Kleuskes & Moos" <kleuske@xs4all.nl> writes: > You're like a mechanic telling me how brakes are useless since they > cannot guarantee that you won't run into anything, anyway. Even when > applying the brakes, you can still run over a pedestrian or a 20-ton > truck, so basically brakes are useless. No, you're the person who is telling me that because I can drive too fast and kill people I shouldn't be using the accelerator. -- Online waterways route planner | http://canalplan.eu Plan trips, see photos, check facilities | http://canalplan.org.uk
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-05-08 03:21 -0700 |
| Message-ID | <ad656215-cd99-468b-8747-4e632f3f5187@a18g2000yqj.googlegroups.com> |
| In reply to | #3508 |
On May 8, 11:26 am, "Kleuskes & Moos" <kleu...@xs4all.nl> wrote: > > The only portable option (and it's been dubbed a kludge) > is to keep track of recursions manually and implement the damn buzzer > yourself. A better solution is to avoid that kind of situation in the > first place. Laying off recursion goes a long way of achieving that. > The problem is that if a data structure is inherently recursive then it can be very difficult to write non-recursive code to traverse it. The usual solution is to use a stack. However this doesn't really solve the problem, it just means that the stack overflow occurs, if it occurs, in a different place.
[toc] | [prev] | [next] | [standalone]
| From | Willem <willem@toad.stack.nl> |
|---|---|
| Date | 2011-05-08 10:44 +0000 |
| Message-ID | <slrnisct0q.141t.willem@toad.stack.nl> |
| In reply to | #3514 |
Malcolm McLean wrote:
) The problem is that if a data structure is inherently recursive then
) it can be very difficult to write non-recursive code to traverse it.
) The usual solution is to use a stack. However this doesn't really
) solve the problem, it just means that the stack overflow occurs, if it
) occurs, in a different place.
In a place where you can catch the error and terminate cleanly.
One of the major problems with C is that you cannot reliably handle
stack overflows, unless you roll your own stack.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-08 07:23 -0700 |
| Message-ID | <e154ec52-5ee3-41de-ad60-37f604e594f6@b19g2000yqg.googlegroups.com> |
| In reply to | #3515 |
On May 8, 12:44 pm, Willem <wil...@toad.stack.nl> wrote: > Malcolm McLean wrote: > > ) The problem is that if a data structure is inherently recursive then > ) it can be very difficult to write non-recursive code to traverse it. > ) The usual solution is to use a stack. However this doesn't really > ) solve the problem, it just means that the stack overflow occurs, if it > ) occurs, in a different place. > > In a place where you can catch the error and terminate cleanly. > > One of the major problems with C is that you cannot reliably handle > stack overflows, unless you roll your own stack. Exactly. And since implementing a stack mechanism with all the goodities and niceties a demanding programmer wants, is in the range of Computer Science 101, it's rather superfluous as a language element. The language C is so powerful and lean since it does put responsability on the programmer. So take it.
[toc] | [prev] | [next] | [standalone]
| From | boltar2003@boltar.world |
|---|---|
| Date | 2011-05-09 11:30 +0000 |
| Message-ID | <iq8j7v$28f$1@speranza.aioe.org> |
| In reply to | #3524 |
On Sun, 8 May 2011 07:23:46 -0700 (PDT) "Kleuskes & Moos" <kleuske@xs4all.nl> wrote: >> In a place where you can catch the error and terminate cleanly. >> >> One of the major problems with C is that you cannot reliably handle >> stack overflows, unless you roll your own stack. > >Exactly. And since implementing a stack mechanism with all the >goodities and niceties a demanding programmer wants, is in the range >of Computer Science 101, it's rather superfluous as a language >element. Best not to mention that to the STL fanboys on comp.lang.c++ ;) B2003
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Date | 2011-05-09 13:36 +0100 |
| Message-ID | <8762pkhwyw.fsf@sapphire.mobileactivedefense.com> |
| In reply to | #3600 |
boltar2003@boltar.world writes: > On Sun, 8 May 2011 07:23:46 -0700 (PDT) > "Kleuskes & Moos" <kleuske@xs4all.nl> wrote: >>> In a place where you can catch the error and terminate cleanly. >>> >>> One of the major problems with C is that you cannot reliably handle >>> stack overflows, unless you roll your own stack. >> >>Exactly. And since implementing a stack mechanism with all the >>goodities and niceties a demanding programmer wants, is in the range >>of Computer Science 101, it's rather superfluous as a language >>element. > > Best not to mention that to the STL fanboys on comp.lang.c++ ;) The STL and Std::String were two of three reasons[*] why it stopped using C++ in 2001. All common data structures are easily implementable with a couple of hundreds of lines of code and I certainly don't ever want to go digging for a programming error in this horrendous mess of 'optimizations' intended to provide a generally useful implementation of something which is rather simple in itself. [*] The third one was that I had written an 'open source' 802.1x implementation in C++ which was turned into 0xdeadbeef because it relied on a particular g++ feature (the ability to define string contants in headers) which was later removed because the people working on the compiler reportedly couldn't agree on a way to implement it.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-05-09 07:08 -0700 |
| Message-ID | <cff79cd4-0732-4217-92a6-fa5bbe794487@p6g2000vbn.googlegroups.com> |
| In reply to | #3605 |
On May 9, 3:36 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote: > > The STL and Std::String were two of three reasons[*] why it stopped > using C++ in 2001. > Yes, the problem was the syntax for simple arrays got too baroque.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-10 07:38 +1200 |
| Message-ID | <92qu5rF51pU1@mid.individual.net> |
| In reply to | #3610 |
On 05/10/11 02:08 AM, Malcolm McLean wrote: > On May 9, 3:36 pm, Rainer Weikusat<rweiku...@mssgmbh.com> wrote: >> >> The STL and Std::String were two of three reasons[*] why it stopped >> using C++ in 2001. >> > Yes, the problem was the syntax for simple arrays got too baroque. Tait's because it's the same as C! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-10 07:44 +1200 |
| Message-ID | <92qugjF51pU2@mid.individual.net> |
| In reply to | #3605 |
On 05/10/11 12:36 AM, Rainer Weikusat wrote: > > [*] The third one was that I had written an 'open source' > 802.1x implementation in C++ which was turned into 0xdeadbeef > because it relied on a particular g++ feature (the ability to > define string contants in headers) which was later removed > because the people working on the compiler reportedly couldn't > agree on a way to implement it. So you're one of those annoying buggers who writes "portable" code that only compiles with gcc. At least this time you got your comeuppance! Posted as one who has spent way too much of his working life porting such "portable" code. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Date | 2011-05-09 21:44 +0100 |
| Message-ID | <87sjsnzjr4.fsf@sapphire.mobileactivedefense.com> |
| In reply to | #3636 |
Ian Collins <ian-news@hotmail.com> writes: > On 05/10/11 12:36 AM, Rainer Weikusat wrote: >> >> [*] The third one was that I had written an 'open source' >> 802.1x implementation in C++ which was turned into 0xdeadbeef >> because it relied on a particular g++ feature (the ability to >> define string contants in headers) which was later removed >> because the people working on the compiler reportedly couldn't >> agree on a way to implement it. > > So you're one of those annoying buggers who writes "portable" code > that only compiles with gcc. By that time (2001), I simply wasn't aware that 'string constants' defined in C++ headers were 'something special' compared to numeric constants. In particlar, I didn't know that this required the compiler to allocate space for the string literal somewhere in the object code files it was supposed to generate. I simply took it for granted because the feature had always been there. Also, I wasn't exactly in the position to even contemplate to get access to a ANSI/ISO standards document, rather in the position where I was happy during the time of the month where I had the money to buy food without wandering all over the city in order to collect deposit bottles first. And the program even worked in Linux and NetBSD and compiled and ran (to the degree I could test it) on Solaris 8 (IIRC). That's not something I would spend any time on today: I use Linux, if you use something else, feel free to port it yourself :->.
[toc] | [prev] | [next] | [standalone]
Page 4 of 13 — ← Prev page 1 2 3 [4] 5 6 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web