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 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-11 07:41 -0400 |
| Message-ID | <iqdslv$86n$1@dont-email.me> |
| In reply to | #3710 |
On 05/10/2011 10:43 PM, Michael Press wrote: > In article <92tkh8F51qU3@mid.individual.net>, > Ian Collins <ian-news@hotmail.com> wrote: > >> On 05/11/11 07:51 AM, Michael Press wrote: >>> In article<92reltF51pU8@mid.individual.net>, >>> Ian Collins<ian-news@hotmail.com> wrote: ... >>>> If it has to be written, you have to write and test the compare routine >>>> whether you use a library for the search or not. >>> >>> Or embed it in the binary search code. >>> It's typically one line. >> >> Which is what the C++ search functions do. > > _You_ must _write_ the callback routine, > or am I mistaken here? It's true in C. You don't always need to write a callback; one may already be available. For each of the binary search function templates (lower_bound, upper_bound, equal_range, and binary_search) there is an overload which requires no comparison function object. That overload uses '<' to perform the comparison. This works for any element type which is: a) a built-in type for which '<' is already provided b) a C++ standard library class for which operator<() is already provided c) a user-defined class for which you have already overload operator<() for some other purpose, so there's no additional cost to also using it in the binary search. But you're right, in general: you do need to write a comparison function; the most reasonable way to do it is write one that is an operator<() overload, taking advantage of the feature described above. That's not always feasible. I recently had a need for a sequence of elements which was simultaneously sorted by two different fields; the sort order was required to be the same for both fields. Insertions of elements for which that requirement could not be met was disallowed. For that purpose, I needed two different comparison functions, one for each field. Only one of them could be operator<(); the other would have to be a separate comparison function. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-05-11 19:51 -0700 |
| Message-ID | <rubrum-B8A30C.19512711052011@news.albasani.net> |
| In reply to | #3739 |
In article <iqdslv$86n$1@dont-email.me>, James Kuyper <jameskuyper@verizon.net> wrote: > On 05/10/2011 10:43 PM, Michael Press wrote: > > In article <92tkh8F51qU3@mid.individual.net>, > > Ian Collins <ian-news@hotmail.com> wrote: > > > >> On 05/11/11 07:51 AM, Michael Press wrote: > >>> In article<92reltF51pU8@mid.individual.net>, > >>> Ian Collins<ian-news@hotmail.com> wrote: > ... > >>>> If it has to be written, you have to write and test the compare routine > >>>> whether you use a library for the search or not. > >>> > >>> Or embed it in the binary search code. > >>> It's typically one line. > >> > >> Which is what the C++ search functions do. > > > > _You_ must _write_ the callback routine, > > or am I mistaken here? It's true in C. > > You don't always need to write a callback; one may already be available. > For each of the binary search function templates (lower_bound, > upper_bound, equal_range, and binary_search) there is an overload which > requires no comparison function object. That overload uses '<' to > perform the comparison. This works for any element type which is: > a) a built-in type for which '<' is already provided > b) a C++ standard library class for which operator<() is already provided > c) a user-defined class for which you have already overload operator<() > for some other purpose, so there's no additional cost to also using it > in the binary search. > > But you're right, in general: you do need to write a comparison > function; the most reasonable way to do it is write one that is an > operator<() overload, taking advantage of the feature described above. > > That's not always feasible. I recently had a need for a sequence of > elements which was simultaneously sorted by two different fields; the > sort order was required to be the same for both fields. Insertions of > elements for which that requirement could not be met was disallowed. For > that purpose, I needed two different comparison functions, one for each > field. Only one of them could be operator<(); the other would have to be > a separate comparison function. Right. Sometimes it is simpler to write a dedicated routine. -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Date | 2011-05-11 12:45 +0100 |
| Message-ID | <878vudtq8n.fsf@sapphire.mobileactivedefense.com> |
| In reply to | #3695 |
Ian Collins <ian-news@hotmail.com> writes:
[ binary search ]
> It is better design to decouple the algorithm from the result
> processing. If nothing else, it gives you a reusable algorithm.
The algorithm is something abstract and as such, inherently reusable
(although the practical usefulness of an algorithm may be limited
outside the problem situation it was intended to help with): Provided
you need to write code which has to search for something in a sorted
array, you can use the reusable 'binary search' algorithm instead of
inventing your own searching algorithm ('binary search' is a really
bad example here because it is so absolutely trivial to implement). It
is also possible to create a reusable implementation of an algorithm,
which amounts to exchanging the problem of implementing the algorithm
for the problem of dealing with an external dependency whose exact
behaviour cannot be determined by inspecting the source code of a
particular program alone, whose exact behaviour may change independently
of the code of the the programs using it, whose implementation isn't
necessarily particularly well-suited for solving the specific problem
at hand and whose implementation may now (or at any time in future)
contain errors independent of the source code of any program using it.
In nutshell, the means such a
program-using-the-reusable-implementation-of-a-reusable algorithm can
possibly/ probably be written faster but it becomes harder to debug
and maintain in exchange for that. Except if the functionality gained
in this way is non-trivial, this is usually a bad tradeoff since
debugging and maintaining code is generally more difficult and
time-consuming than writing it.
I recently spent roughly a complete work day trying to 'decrypt'
Ulrich Drepperts custom macro orgies inside glibc in order to
determine what code is actually being executed by a program which
failed inside the getpsnam library routine before I was able to
identify the actual problem and what was causing it and fix that which
provides a nice example of the maintenance problem I wrote about in
the first paragraph. And I'd wager a bet that a majority of
'developers' won't even contemplate to try to determine why some
seemingly correct code fails inside a library call but just stack
workaround onto workaround in order to mitigate the practical
consequences whenever the reliability problems caused by the actual
error happens to reach them (and this is bound to be much less often
than the problem affecting a user of the code in some significant
way).
> Better still if this can be done with little or no overhead.
Computers are really fast nowadays and avoiding the inherent overhead
of 'the most general "optimized" solution we were able to find'
usually turns 'performance problems' into non-issues: Only heavy users
of insanely huge and complex third-party libraries are still affected
by that (this is a somewhat hyperbolic statement with a true core).
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-10 07:50 -0700 |
| Message-ID | <56eb5eae-f200-4445-9ab3-3579e0a17a5e@q32g2000yqn.googlegroups.com> |
| In reply to | #3644 |
On May 10, 12:05 am, Michael Press <rub...@pacbell.net> wrote: > In article > <cdc2bce7-4168-4bad-92b7-fdaa78e55...@b19g2000yqg.googlegroups.com>, > "Kleuskes & Moos" <kleu...@xs4all.nl> wrote: > > > > > > > > > > > On May 9, 1:30 pm, boltar2...@boltar.world wrote: > > > On Sun, 8 May 2011 07:23:46 -0700 (PDT) > > > "Kleuskes & Moos" <kleu...@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++ ;) > > > STL is a library, not a language element. A superbly useful library at > > that. That's exactly where stuff like lists, queues, stack and what > > have SHOULD be implemented. After all, it's no use inventing the wheel > > all over again every time you need one. > > There are good reasons to write it oneself. Oh sure... Please... It was merely an observations that there are good reasons to have libs like BOOST and STL, too. Not some kind of fatwa prohibiting this, that or the other. If you feel you're better off rolling your own, then you should. > When I want > a binary search I simply write it on the fly; and embed > whatever I want to do with the search result right there. > It takes as long or longer to write the interfaces to a > library binary search as it does to write one that does > exactly what I want. If that's the best solution for you... Who am i to protest?
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Date | 2011-05-10 11:04 +0100 |
| Message-ID | <871v06lvmm.fsf@sapphire.mobileactivedefense.com> |
| In reply to | #3641 |
"Kleuskes & Moos" <kleuske@xs4all.nl> writes: > On May 9, 1:30 pm, boltar2...@boltar.world wrote: >> On Sun, 8 May 2011 07:23:46 -0700 (PDT) >> "Kleuskes & Moos" <kleu...@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++ ;) > > STL is a library, not a language element. A superbly useful library at > that. That's exactly where stuff like lists, queues, stack and what > have SHOULD be implemented. After all, it's no use inventing the wheel > all over again every time you need one. Funny as it may seem, but that's what people who construct vehicles actually often do: They design different types of wheels for different types of vehicles and actually even construct new types of wheels in order to improve the designs of existing of wheels. But they don't usually claim that they invented the basic design because they also created an implementation of it. It takes a programmer-turned-math-geek to be so out of touch with reality to not notice that this analogy is nowhere near being accurate and to also avoid noticing that a one-size-fits-all-wheel simply doesn't exist while - at the same time - claiming to have invented something comparable to 'the wheel' when all he has actually done is create another implementation of an algorithm which has been well-known for thirty years or so and was usually the topic of some kind of undergraduate course. Given these glaring deficiencies in judgement and the completely ludicrous self-assessment, such a person is not one one can expect to give sensible advice to others.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-08 09:27 -0400 |
| Message-ID | <iq65n6$g8v$1@dont-email.me> |
| In reply to | #3508 |
On 05/08/2011 04:26 AM, Kleuskes & Moos wrote: > 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: ... >> 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. Imposing a hardware requirement is what makes that solution non-portable. It's not a bad solution; but it cannot be ported to a machine that doesn't meet those requirements. Some mechanism for determining, within your program, whether a given function call would require more stack than is currently available would make it possible to write code which at least fails gracefully on such hardware, instead of simply aborting (or worse). > 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. No, I'm saying that any precautions you need to take to make recursion safe necessarily limit the portability of your code; the same is true of making non-recursive function calls safe; it's just a little easier to take the appropriate precautions with non-recursive code. As long as you take those precautions, and consider the associated limitations on the portability of your code acceptable, there's no other reason to avoid recursion. And, where it's appropriate, there can be strong reasons to favor a recursive approach. ... > 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 should not confuse non-portable with useless. ... >> 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. I haven't come up with an alternative that is easy to use. The simplest approach I can think of, from the point of view of the implementor, would be two constructs. I would call them standard library functions, and using function-call syntax might be the appropriate way to specify them in the standard, but they must be implemented in such a way that they can always be called safely, regardless of how little stack there is left. One function determines how much memory is currently available for objects with automatic storage duration (if the exact amount is hard to determine, it may instead return a guaranteed minimum amount). The second function takes a function pointer as an argument, and reports the amount of memory required for objects with automatic storage duration needed to call that function. It would not include the memory needed by function calls within the pointed-at function; avoiding stack overflow due to those calls would be the responsibility of the function that directly performs them. There's a number of reasons why this simple approach would be inadequate for C: VLAs and objects with automatic storage duration defined inside conditionally executed blocks are the two biggest problems I can see; I'm sure there are others. However, a C-like language without those features could implement such constructs. It might be possible to implement some variant of this idea in C itself. The key advantage of this idea, over SIGSEGV, is that it allows a program to avoid the problem, rather than merely react to the problem after it has already happened. Understand: I am not advocating the creation of such a mechanism; my main point is that the problem that such a mechanism would solve, exists whether or not the program in question uses recursion. You shouldn't avoid recursion just because that problem is a little harder to deal with in recursive code than in non-recursive code. ... >> 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. I can't - because neither C, nor any other language that I'm familiar with, has portable methods to avoid stack overflow. I use non-portable methods that are probably not too different from yours. They basically amount to making sure that it works on every machine I have available to test it on, and hoping that it works elsewhere. While my software is required to be available to the public, the only machines it absolutely must run on are machines operated by my own company, and I have development machines I can test my code on that are (supposed to be) configured identically to the production machines. But if a user is having trouble porting my code to their machine, and is willing to give me access to that machine for testing, I would certainly be glad to fix the problem. I have anecdotal evidence suggesting that most users don't bother; many of them simply make the fix themselves, without even bothering to complain about it. I found a bug last year when we first ported our code to a 64-bit CentOS machine, and when I announced my bug fix, three users wrote to tell me they'd already noticed the problem and fixed it in their own copies of the code, without bothering to tell me about the bug. ... > 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? None - which is the substance of my complaint. >> 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. No, just a function that requires more total stack space than is available; it doesn't all have to be allocated in a single object. Virtual memory makes such a limit harder to exceed, but not all systems have virtual memory. On some small machines, it could take a whole lot less than 2GB to exceed that limit. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-08 08:04 -0700 |
| Message-ID | <eee7408c-f3c8-45c0-8509-0b399db9b810@w24g2000yqb.googlegroups.com> |
| In reply to | #3522 |
On May 8, 3:27 pm, James Kuyper <jameskuy...@verizon.net> wrote: > On 05/08/2011 04:26 AM, Kleuskes & Moos wrote: > > > 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: > ... > >> 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. > > Imposing a hardware requirement is what makes that solution > non-portable. That may be true, but still, there's no way around it. At leats your requrements should include a fair estimate of memory needed to run the program. Besides, no software, however portable, will run on all systems. The differences are simply too big. So wether you want to or not, hardware requirements are a fact of life. > It's not a bad solution; but it cannot be ported to a > machine that doesn't meet those requirements. Nope. That's the basic meaning of hardware requirements. > Some mechanism for determining, within your program, whether a given >function call would require more stack than is currently available would > make it possible to write code which at least fails gracefully on such > hardware, instead of simply aborting (or worse). Some mechanism of checking RAM size and seeing wether or not that meets the minimum requirements is much simpler. Then it's up to the programmer to halt the program or inform the user that he's on his own and the programmer can't guarantee safe execution. > > 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. > > No, I'm saying that any precautions you need to take to make recursion > safe necessarily limit the portability of your code; the same is true of > making non-recursive function calls safe; it's just a little easier to > take the appropriate precautions with non-recursive code. As long as you > take those precautions, and consider the associated limitations on the > portability of your code acceptable, there's no other reason to avoid > recursion. And, where it's appropriate, there can be strong reasons to > favor a recursive approach. Still curious what "precautions" you are talking about, after first telling me there's no safe and portable way. So please expound. > > 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 should not confuse non-portable with useless. Oh, trust me... I don't. Some of the most useful software i ever wrote was totally and utterly non-portable. In a software design-sense, that is. It even required a custom processor to run in the first place. > >> 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. > > I haven't come up with an alternative that is easy to use. > The simplest approach I can think of, from the point of view of the > implementor, would be two constructs. I would call them standard library > functions, and using function-call syntax might be the appropriate way > to specify them in the standard, but they must be implemented in such a > way that they can always be called safely, regardless of how little > stack there is left. If you're out of stack, you can't call anything, for lack of stack- space to hold a return address. But still, you could reserve some space for an "emergency stack". > One function determines how much memory is > currently available for objects with automatic storage duration (if the > exact amount is hard to determine, it may instead return a guaranteed > minimum amount). Ok. > The second function takes a function pointer as an argument, and reports > the amount of memory required for objects with automatic storage > duration needed to call that function. It would not include the memory > needed by function calls within the pointed-at function; avoiding stack > overflow due to those calls would be the responsibility of the function > that directly performs them. > > There's a number of reasons why this simple approach would be inadequate > for C: VLAs and objects with automatic storage duration defined inside > conditionally executed blocks are the two biggest problems I can see; > I'm sure there are others. However, a C-like language without those > features could implement such constructs. It might be possible to > implement some variant of this idea in C itself. It might. > The key advantage of this idea, over SIGSEGV, is that it allows a > program to avoid the problem, rather than merely react to the problem > after it has already happened. Tja... It seems to me such a solution would have a few problems. First off, on many systems the amount of memory available to automatic variables variable itself. Secondly it would introduce a shitload of overhead, since before calling any function a check must be made. And that's apart from problems you already mentioned. > Understand: I am not advocating the creation of such a mechanism; my > main point is that the problem that such a mechanism would solve, exists > whether or not the program in question uses recursion. You shouldn't > avoid recursion just because that problem is a little harder to deal > with in recursive code than in non-recursive code. No. You should avoid it because it's fundamentally unsafe, unless you and your customers are prepared to live with the consequences. In the latter case, and this is quite frequent, recurse the hell out of your system if it makes your software easier to read and maintain. As i mentioned earlier, it _is_ the saving grace of recursion. > >> 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. > > I can't - because neither C, nor any other language that I'm familiar > with, has portable methods to avoid stack overflow. I use non-portable > methods that are probably not too different from yours. They basically > amount to making sure that it works on every machine I have available to > test it on, and hoping that it works elsewhere. Ok. I'm specialized i software where "hoping it doesn't crash" just does not cut it. People get killed that way (no joke). > While my software is required to be available to the public, the only > machines it absolutely must run on are machines operated by my own > company, and I have development machines I can test my code on that are > (supposed to be) configured identically to the production machines. > But if a user is having trouble porting my code to their machine, and is > willing to give me access to that machine for testing, I would certainly > be glad to fix the problem. I have anecdotal evidence suggesting that > most users don't bother; many of them simply make the fix themselves, > without even bothering to complain about it. I found a bug last year > when we first ported our code to a 64-bit CentOS machine, and when I > announced my bug fix, three users wrote to tell me they'd already > noticed the problem and fixed it in their own copies of the code, > without bothering to tell me about the bug. Perhaps they thought you already knew about it. In many applications a crashing program isn't the end of the world, and customers just shrug and try again. That is also my expirience. > > 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? > > None - which is the substance of my complaint. Ok. In that case, try to avoid recursion, if at all possible, especially if you suspect you stack might me overrun. Your customers do not mind a crash every now and then, mine do and consider it a matter of life and death or at least a substantial amount of cash. They don't come complaining to me, but their lawyers start complaining to my boss. > >> 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. > > No, just a function that requires more total stack space than is > available; it doesn't all have to be allocated in a single object. > Virtual memory makes such a limit harder to exceed, but not all systems > have virtual memory. On some small machines, it could take a whole lot > less than 2GB to exceed that limit. True. So take heed that does not happen.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-08 22:50 -0400 |
| Message-ID | <iq7kpu$ph5$1@dont-email.me> |
| In reply to | #3527 |
On 05/08/2011 11:04 AM, Kleuskes & Moos wrote: > On May 8, 3:27�pm, James Kuyper <jameskuy...@verizon.net> wrote: ... >> whether or not the program in question uses recursion. You shouldn't >> avoid recursion just because that problem is a little harder to deal >> with in recursive code than in non-recursive code. > > No. You should avoid it because it's fundamentally unsafe, I guess we'll just have to agree to disagree on that point; I don't wee either of us making any progress in convincing the other. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-09 00:18 -0700 |
| Message-ID | <086cf53d-11ff-4d0b-8fd5-4b1d70b767ac@28g2000yqu.googlegroups.com> |
| In reply to | #3572 |
On May 9, 4:50 am, James Kuyper <jameskuy...@verizon.net> wrote: > On 05/08/2011 11:04 AM, Kleuskes & Moos wrote: > > > On May 8, 3:27 pm, James Kuyper <jameskuy...@verizon.net> wrote: > ... > >> whether or not the program in question uses recursion. You shouldn't > >> avoid recursion just because that problem is a little harder to deal > >> with in recursive code than in non-recursive code. > > > No. You should avoid it because it's fundamentally unsafe, > > I guess we'll just have to agree to disagree on that point; I don't wee > either of us making any progress in convincing the other. That's a sensible outcome. It was a pleasure exchanging views with you.
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2011-05-08 19:49 +0100 |
| Message-ID | <pan.2011.05.08.18.48.53.625000@nowhere.com> |
| In reply to | #3508 |
On Sun, 08 May 2011 01:26:13 -0700, Kleuskes & Moos wrote: >> 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. Unless you're using any library functions which don't document their stack requirements, which is almost certainly the case. I've only ever seen (note: seen, not used) one library which documented its stack requirements.
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2011-05-08 20:05 +0100 |
| Message-ID | <yw1x7ha1ggin.fsf@unicorn.mansr.com> |
| In reply to | #3547 |
Nobody <nobody@nowhere.com> writes: > On Sun, 08 May 2011 01:26:13 -0700, Kleuskes & Moos wrote: > >>> 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. > > Unless you're using any library functions which don't document their stack > requirements, which is almost certainly the case. I've only ever seen > (note: seen, not used) one library which documented its stack requirements. It is relatively simple to examine the code and determine the stack requirements. -- Måns Rullgård mans@mansr.com
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-08 13:44 -0700 |
| Message-ID | <lnsjsoorc5.fsf@nuthaus.mib.org> |
| In reply to | #3508 |
"Kleuskes & Moos" <kleuske@xs4all.nl> writes:
> On May 8, 4:52 am, James Kuyper <jameskuy...@verizon.net> wrote:
[...]
>> 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.
[...]
No, he didn't say anything like that.
I've found that debates like this are much more productive if each party
states his own opinions, rather than arguing against some exaggerated
parody of the other party's position.
--
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 | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-09 00:22 -0700 |
| Message-ID | <cb3f3a6e-b21a-4141-b2a9-c6cc394ed225@x1g2000yqb.googlegroups.com> |
| In reply to | #3556 |
On May 8, 10:44 pm, Keith Thompson <ks...@mib.org> wrote: > "Kleuskes & Moos" <kleu...@xs4all.nl> writes:> On May 8, 4:52 am, James Kuyper <jameskuy...@verizon.net> wrote: > [...] > >> 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. > > [...] > > No, he didn't say anything like that. > > I've found that debates like this are much more productive if each party > states his own opinions, rather than arguing against some exaggerated > parody of the other party's position. Every now and then it pays to be a little provocative. I call it, "kicking the pear tree". And yes, the exaggeration was intentional and designed to provoke a response. It payed off, i'm glad to say.
[toc] | [prev] | [next] | [standalone]
| From | Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> |
|---|---|
| Date | 2011-05-15 17:05 +0100 |
| Subject | Re: Avoiding recursive stack overflow in C? |
| Message-ID | <IU.D20110515.T160558.P4093.Q0@J.de.Boyne.Pollard.localhost> |
| In reply to | #3477 |
> [...] 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?
>
For what it's worth, if you expand your horizons outside of just Unix
and Linux, things are rather different. For one thing, the problem that
you want to avoid has not "already happened" on systems such as Win32
and OS/2 when the exception that one has to handle is raised. This is
because on such systems the decommitted stack scheme relies upon all
functions performing stack probes. Stack probes happen in the function
perilogue, at the beginning before the meat of the function begins
execution, and it is during those probes that the exceptions will be
raised, as guard pages and non-stack areas are referenced by the probing.
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-perilogues.html#StackProbes
Specifically, what happens is that a (OS/2 or Win32, not C++) exception
is raised when a new guard page cannot be set. Microsoft KnowledgeBase
article Q315937 shows how to catch such exceptions, and the small amount
of cleanup that is necessary to handle the fact that the exception is
raised partway through the stack growth process. OS/2 has the same
mechanism, and the exception to catch is the fairly straightforwardly
named XCPT_UNABLE_TO_GROW_STACK . (Notice that on OS/2 this exception
is raised by code that is itself an exception handler, for the
XCPT_GUARD_PAGE_VIOL exception.)
http://cyberkinetica.homeunix.net/os2tk45/cp2/851_L3_XCPT_GUARD_PAGE_VIOL.html
Again, these exceptions are raised as a result of actions taken in the
function perilogue, not the function body proper. You'll note from the
function perilogues FGA page that there's a problem with some compilers
that don't properly account for the calling parameters area; but, that
poor quality compiler issue set aside, this means that (except for
alloca() and variable-length arrays) one can be assured that one won't
have to deal with this once a function's activation record has been
fully pushed onto the stack by the perilogue.
As for the "gas gauge": That's a matter of comparing the current stack
pointer with the stack bottom recorded in the Thread Information Block,
code for most of which (obtaining the amount still remaining instead of
the amount already used being a minor exercise for the reader) is on the
quite appropriately named StackOverflow, in an answer to a question on
this very subject.
http://stackoverflow.com/questions/1740888/determining-stack-space-with-visual-studio/1747249#1747249
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-15 14:07 -0400 |
| Subject | Re: Avoiding recursive stack overflow in C? |
| Message-ID | <iqp4od$1mk$1@dont-email.me> |
| In reply to | #4024 |
On 05/15/2011 12:05 PM, Jonathan de Boyne Pollard wrote: >> [...] 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? >> > For what it's worth, if you expand your horizons outside of just Unix > and Linux, things are rather different. My horizon is a lot larger than that, which is why a Windows-specific solution is just as unhelpful to me as a Unix-specific one. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> |
|---|---|
| Date | 2011-05-15 22:49 +0100 |
| Subject | Re: Avoiding recursive stack overflow in C? |
| Message-ID | <IU.D20110515.T215017.P4453.Q0@J.de.Boyne.Pollard.localhost> |
| In reply to | #4028 |
>>> [...] 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? >>> >> For what it's worth, if you expand your horizons outside of just Unix >> and Linux, things are rather different. >> > My horizon is a lot larger than that, which is why a Windows-specific > solution is just as unhelpful to me as a Unix-specific one. > You weren't given a Windows-specific solution. Go and read what I wrote, but properly this time, instead of stopping after the first sentence as you did above. Your horizons certainly in this thread so far have most definitely been confined to Unix and Linux. You keep going on about SIGSEGV, for starters. If your horizon were wider, you'd not be doing so. Nor would you be bringing up as problems things that simply aren't the case outwith the narrow confines of Unix and Linux. And indeed, I quote you from a couple of messages back: > My own programs are allowed to assume [...] a correspondingly early > version of POSIX, [...] > There's that narrow horizon right there, in your very own words.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-15 21:08 -0400 |
| Subject | Re: Avoiding recursive stack overflow in C? |
| Message-ID | <iqpteg$ba2$1@dont-email.me> |
| In reply to | #4036 |
On 05/15/2011 05:49 PM, Jonathan de Boyne Pollard wrote: ... > not be doing so. Nor would you be bringing up as problems things that > simply aren't the case outwith the narrow confines of Unix and Linux. "outwith" => "outside"? If it's a problem for any fully conforming versions of C, it's a problem my code should, ideally, be able to deal with properly, regardless of whether there's other fully conforming versions where it is not. > And indeed, I quote you from a couple of messages back: > >> My own programs are allowed to assume [...] a correspondingly early >> version of POSIX, [...] >> > There's that narrow horizon right there, in your very own words. What I'm allowed to assume for the project I'm working on, and what I'm willing to assume in general, are two very different things. Even on this particular project, my code actually relies very little upon that particular assumption. That's possible primarily because one of the third-party libraries I'm required to use hides a lot of the implementation-specific details within it's own code. Because there's no requirement that my code operate on non-POSIX platforms, I could not get permission to spend any significant amount of time making sure that it did; but if that requirement were changed, I doubt that my own code would require many fixes. A very small portion of my code relies upon the POSIX guarantee that CHAR_BITS==8; most of it is carefully written to avoid making that assumption. Those five programs rely upon that guarantee in order to parse some data structures. If I could no longer rely upon POSIX, that would be the most difficult part to fix. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Date | 2011-05-16 11:10 +0100 |
| Subject | Re: Avoiding recursive stack overflow in C? |
| Message-ID | <87sjsfymz6.fsf@sapphire.mobileactivedefense.com> |
| In reply to | #4036 |
Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> writes: [...] >> My own programs are allowed to assume [...] a correspondingly early >> version of POSIX, [...] >> > There's that narrow horizon right there, in your very own words. Indeed. The 'narrow horizon' of an IEEE standard, compared to the wide world of the single company (mostly accurate) which usually doesn't bother complying to standards it didn't invent itself. This, of course, not only being total nonsense but also crossposted to four different groups and being off topic everyhwere because it is essentially advocacy or - more accurelaty - a fan with an 'obsessive compulsive' habit of trying to proselytize among the heathens. F'up2 in appropriate group set. Don't reply to this posting.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Zakharevich <nospam-abuse@ilyaz.org> |
|---|---|
| Date | 2011-05-16 08:04 +0000 |
| Subject | Re: Avoiding recursive stack overflow in C? |
| Message-ID | <slrnit1mks.o96.nospam-abuse@chorin.math.berkeley.edu> |
| In reply to | #4024 |
On 2011-05-15, Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> wrote: > For what it's worth, if you expand your horizons outside of just Unix > and Linux, things are rather different. For one thing, the problem that > you want to avoid has not "already happened" on systems such as Win32 > and OS/2 when the exception that one has to handle is raised. This is > because on such systems the decommitted stack scheme relies upon all > functions performing stack probes. Stack probes happen in the function > perilogue, at the beginning before the meat of the function begins > execution, and it is during those probes that the exceptions will be > raised, as guard pages and non-stack areas are referenced by the probing. What you describe has nothing to do with the OS, but with particular compilers only (at least on OS/2). Hope this helps, Ilya
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2011-05-07 19:11 +0300 |
| Message-ID | <92l9a8F413U1@mid.individual.net> |
| In reply to | #3401 |
James Kuyper wrote:
> I'm not aware of any other language that provides a mechanism for
> avoiding or dealing with this problem, either. There might be one, but I
> don't know it's name.
Stack overflow in the Ada language is expected to raise the
Storage_Error exception, which can be caught and handled in the Ada
program itself. However, this can depend on compilation options, for
example the GNU Ada compiler gnat needs the option -fstack-check for
Storage_Error to work in this way, otherwise stack overflow just signals
a SIGSEGV.
You can also do the recursive computation in a dedicated thread (an Ada
"task") and control the amount of stack space allocated to the thread by
means of pragma Storage_Size, with a static constant value or a
dynamically calculated value, when the thread is created.
If you expect that Storage_Error may be raised by stack overflow during
recursion, it is a good idea to put the handler for Storage_Error
outside the recursion, so that the recursion unwinds and stack space is
again available before the handler is entered.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
Page 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web