Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.unix.programmer > #306 > unrolled thread
| Started by | boltar2003@boltar.world |
|---|---|
| First post | 2011-05-05 09:37 +0000 |
| Last post | 2011-05-05 12:18 -0700 |
| Articles | 20 on this page of 270 — 46 participants |
Back to article view | Back to comp.unix.programmer
Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 09:37 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? China Blue Veins <chine.bleu@yahoo.com> - 2011-05-05 02:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 09:58 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? China Blue Veins <chine.bleu@yahoo.com> - 2011-05-05 04:47 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-07 23:22 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-05 11:58 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2011-05-05 13:40 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 13:52 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Azazel <azazel@remove.azazel.net> - 2011-05-05 09:22 -0500
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 14:41 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Azazel <azazel@remove.azazel.net> - 2011-05-05 10:30 -0500
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-07 23:23 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-05 18:55 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-05 11:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-06 14:36 +0200
RLIMIT_STACK (was: Avoiding recursive stack overflow in C on Unix/Linux?) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2011-05-10 14:19 +0100
Re: RLIMIT_STACK Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-11 08:28 +0200
Re: RLIMIT_STACK scott@slp53.sl.home (Scott Lurndal) - 2011-05-11 16:18 +0000
Re: RLIMIT_STACK Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-11 18:37 +0200
Re: RLIMIT_STACK scott@slp53.sl.home (Scott Lurndal) - 2011-05-11 19:53 +0000
Re: RLIMIT_STACK Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2011-05-11 17:43 +0100
Re: RLIMIT_STACK Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-11 20:03 +0200
Re: RLIMIT_STACK Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-11 20:20 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-06 03:27 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-06 00:03 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 09:18 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-06 02:56 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Noob <root@127.0.0.1> - 2011-06-01 15:19 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-05 12:24 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Lowell Gilbert <lgusenet@be-well.ilk.org> - 2011-05-05 15:40 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:18 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-05 21:17 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-05-05 18:45 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:44 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 09:58 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Richard Kettlewell <rjk@greenend.org.uk> - 2011-05-06 11:11 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 10:16 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Richard Kettlewell <rjk@greenend.org.uk> - 2011-05-06 11:28 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:34 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-06 15:09 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 13:03 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 09:01 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 14:32 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-07 16:27 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 16:43 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-08 06:19 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-08 17:18 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-08 09:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-09 11:34 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-11 03:48 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-11 10:51 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-11 08:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-11 15:47 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-12 15:05 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-07 16:23 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 18:12 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 10:30 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:01 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 12:37 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 18:15 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-08 15:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 09:32 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-08 10:46 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 21:49 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 09:59 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 20:24 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-07 15:04 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 15:15 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-07 21:02 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 19:57 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 20:26 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 21:06 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-07 23:27 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-05 20:07 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-06 02:53 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 19:27 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-06 10:07 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-06 10:29 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-06 03:04 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 06:33 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-06 12:04 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? David Schwartz <davids@webmaster.com> - 2011-05-07 04:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-07 13:07 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? David Schwartz <davids@webmaster.com> - 2011-05-07 21:13 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-08 10:46 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? David Schwartz <davids@webmaster.com> - 2011-05-08 05:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Golden California Girls <gldncagrls@aol.com.mil> - 2011-05-07 08:59 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 07:08 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 08:18 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Marco Parrone <marco@marcoparrone.com> - 2011-05-06 17:32 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 08:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 21:46 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 00:28 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-07 09:01 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 06:35 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-07 22:52 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 01:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-08 09:37 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-08 03:21 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Willem <willem@toad.stack.nl> - 2011-05-08 10:44 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 07:23 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-09 11:30 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-09 13:36 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-09 07:08 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 07:38 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 07:44 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-09 21:44 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 13:59 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 14:19 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 15:05 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 10:20 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 19:04 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-14 11:13 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-09 15:40 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-09 23:44 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 11:06 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-10 00:11 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 11:17 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-10 07:10 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 12:24 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-05-10 13:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:48 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:54 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-05-12 05:56 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 00:44 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 19:36 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 23:21 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 07:08 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-11 11:48 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 10:03 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 10:12 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 21:23 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nicolas George <nicolas$george@salle-s.org> - 2011-05-11 21:07 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-12 09:45 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:00 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:35 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-12 06:51 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-12 14:36 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-12 22:57 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-11 11:47 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:07 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-10 21:16 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-11 02:40 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 09:39 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:42 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-15 00:23 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? pacman@kosh.dhis.org (Alan Curry) - 2011-05-14 22:30 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2011-05-15 18:21 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-16 04:19 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-16 08:40 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-16 17:53 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nicolas George <nicolas$george@salle-s.org> - 2011-05-16 16:58 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-16 21:39 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 09:12 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-17 10:20 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-17 15:00 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? pacman@kosh.dhis.org (Alan Curry) - 2011-05-17 20:28 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 14:45 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 14:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-17 16:23 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-17 23:06 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-18 01:02 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-18 01:29 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-18 04:03 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Pfaff <blp@cs.stanford.edu> - 2011-05-17 16:47 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 17:21 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-23 21:57 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-23 21:57 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-23 17:45 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-24 11:43 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-24 10:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Sherm Pendley <sherm.pendley@gmail.com> - 2011-05-11 11:11 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:48 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-09 16:22 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 21:25 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Seebs <usenet-nospam@seebs.net> - 2011-05-10 17:28 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 17:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 12:20 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 03:53 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 20:18 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 04:42 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-10 09:12 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-10 03:21 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-10 10:53 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-10 08:12 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 09:39 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 12:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-11 08:12 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-10 15:16 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 19:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 07:41 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-11 12:45 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-10 07:50 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-10 11:04 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-08 09:27 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 08:04 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-08 22:50 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 00:18 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:49 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-08 20:05 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-08 13:44 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 00:22 -0700
Re: Avoiding recursive stack overflow in C? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-15 17:05 +0100
Re: Avoiding recursive stack overflow in C? James Kuyper <jameskuyper@verizon.net> - 2011-05-15 14:07 -0400
Re: Avoiding recursive stack overflow in C? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-15 22:49 +0100
Re: Avoiding recursive stack overflow in C? James Kuyper <jameskuyper@verizon.net> - 2011-05-15 21:08 -0400
Re: Avoiding recursive stack overflow in C? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-16 11:10 +0100
Re: Avoiding recursive stack overflow in C? Ilya Zakharevich <nospam-abuse@ilyaz.org> - 2011-05-16 08:04 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-05-07 19:11 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 07:17 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-05-08 10:16 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-09 09:03 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 08:59 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 03:01 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 07:13 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 09:02 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-06 15:41 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 02:53 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-07 16:17 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 10:08 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:20 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 14:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-07 14:31 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 22:49 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-07 23:27 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-07 17:22 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 10:24 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-07 17:32 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 11:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 10:57 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 08:09 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:41 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-08 17:59 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-09 09:01 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:41 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 12:48 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 11:01 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? gazelle@shell.xmission.com (Kenny McCormack) - 2011-05-08 13:10 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:51 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-08 22:21 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? gazelle@shell.xmission.com (Kenny McCormack) - 2011-06-04 12:54 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-06-04 12:59 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-06-07 06:30 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-06-10 21:56 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 13:53 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 15:16 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-07 23:42 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 19:37 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 07:17 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 09:24 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-08 10:36 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 13:29 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 08:37 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 11:13 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-09 15:46 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-08 00:28 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 23:06 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-08 07:30 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-08 15:51 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 13:33 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-14 11:08 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-14 15:53 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-10 22:14 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 11:08 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 08:15 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-10 08:30 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-11 03:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-05 12:18 -0700
Page 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
| From | Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> |
|---|---|
| Date | 2011-05-11 11:47 +0000 |
| Message-ID | <4dca7740$0$81481$e4fe514c@news.xs4all.nl> |
| In reply to | #496 |
pete <pfiland@mindspring.com> writes: >Michael Press wrote: > >> I could dash off qsort. Its only advantage is speed. >> When I want an O(n.log n) search I write heapsort. >> >> By the way, qsort(3) has an irremediable security hole. >I like to write sort functions with a qsort interface. >http://www.mindspring.com/~pfilandr/C/q_sort/ There is no rule that qsort() is actually a quick sort. Casper --
[toc] | [prev] | [next] | [standalone]
| From | pete <pfiland@mindspring.com> |
|---|---|
| Date | 2011-05-11 08:07 -0400 |
| Message-ID | <4DCA7C09.303D@mindspring.com> |
| In reply to | #522 |
Casper H.S. Dik wrote:
>
> pete <pfiland@mindspring.com> writes:
>
> >Michael Press wrote:
> >
> >> I could dash off qsort. Its only advantage is speed.
> >> When I want an O(n.log n) search I write heapsort.
> >>
> >> By the way, qsort(3) has an irremediable security hole.
>
> >I like to write sort functions with a qsort interface.
>
> >http://www.mindspring.com/~pfilandr/C/q_sort/
>
> There is no rule that qsort() is actually a quick sort.
The fastest ones that I have are either quicksort
or variations on quicksort.
But most of the sort functions that I have in that directory
aren't quicksort.
http://www.mindspring.com/~pfilandr/C/q_sort/pt_sort.c
slsort, "Nonstable simple selection sort:", \
b_sort, "Stable bubble sort:", \
i_sort, "Stable insertionsort:", \
bisort, "Stable binary insertion sort:", \
s0sort, "Nonstable Shell sort \n" \
"with original Shell increment scheme:", \
shsort, "Nonstable Shell sort \n" \
"with Sedgewick increment scheme:", \
hdsort, "Nonstable double sift down heapsort:", \
h_sort, "Nonstable sift down and up heapsort:", \
lqsort, "Nonstable Lomuto style quicksort:", \
q1sort, "Nonrecursive Lomuto style quicksort:", \
sqsort, "Nonstable Sedgewick style quicksort:", \
q2sort, "Nonrecursive Sedgewick style quicksort:", \
qrsort, "Random pivot introspective quicksort:", \
mqsort, "Nonstable quicksort, (nmemb / 2) median:", \
sfsort, "Leapfropg sample quicksort:", \
m_sort, "Stable merge sort uses half buffer:", \
rcsort, "Stable, array of pointers and full buffer:", \
ipsort, "Stable merge, uses two arrays of pointers:", \
llsort, "Stable merge sort uses linked list:", \
--
pete
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-10 21:16 -0700 |
| Message-ID | <lnwrhxlvms.fsf@nuthaus.mib.org> |
| In reply to | #492 |
Michael Press <rubrum@pacbell.net> writes:
[...]
> By the way, qsort(3) has an irremediable security hole.
Can you expand on that? Is it something Unix-specific, or does it
affect any C implementation (note the cross-post).
(I presume you're aware that qsort() needn't use the Quicksort
algorithm.)
--
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 | "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> |
|---|---|
| Date | 2011-05-11 02:40 -0700 |
| Message-ID | <3617b15c-1e1e-4353-a96a-0bf4e79881f0@e8g2000vbz.googlegroups.com> |
| In reply to | #497 |
On May 10, 11:16 pm, Keith Thompson <ks...@mib.org> wrote: > Michael Press <rub...@pacbell.net> writes: > > [...] > > > By the way, qsort(3) has an irremediable security hole. > > Can you expand on that? Is it something Unix-specific, or does it > affect any C implementation (note the cross-post). > > (I presume you're aware that qsort() needn't use the Quicksort > algorithm.) I assume he means that Quicksort can go quadratic, and carefully (mis)designed* input can be an effective denial of service attack. As you point out, of course, qsort() doesn't need to implement Quicksort (although most still do, with some having moved to Introsort). *Musser's original paper on Introsort is worth reading just for the section on the (surprising easy) automatic generation of worst case sequences for the common variants of Quicksort.
[toc] | [prev] | [next] | [standalone]
| From | pete <pfiland@mindspring.com> |
|---|---|
| Date | 2011-05-11 09:39 -0400 |
| Message-ID | <4DCA9197.260@mindspring.com> |
| In reply to | #516 |
robertwessel2@yahoo.com wrote:
>
> On May 10, 11:16 pm, Keith Thompson <ks...@mib.org> wrote:
> > Michael Press <rub...@pacbell.net> writes:
> >
> > [...]
> >
> > > By the way, qsort(3) has an irremediable security hole.
> >
> > Can you expand on that? Is it something Unix-specific, or does it
> > affect any C implementation (note the cross-post).
> >
> > (I presume you're aware that qsort() needn't use the Quicksort
> > algorithm.)
>
> I assume he means that Quicksort can go quadratic, and carefully
> (mis)designed* input can be an effective denial of service attack.
Leapfrogging samplesort is a variation on quicksort
which is O(n * (log(n)) * (log(n))) for worst case.
http://www.springerlink.com/content/p70564506802n575/
However, I dispute the claim by Eliezer A. Albacea, that
"(3) the expected number of data interchanges
is slightly higher than that of Quicksort."
The expected number of data interchanges is much higher.
http://www.mindspring.com/~pfilandr/C/e_driver/
/* BEGIN e_driver.c program output */
Counting comparisons and MOV's for 2 different sorting
Sorting arrays of N number of elements.
Distribution #1: Shuffled
N sqsort NFsort
CMPS MOVS CMPS MOVS
1999999 54273473 29450250 39349553 85578207
2000000 55635331 29418642 39348505 85573743
Total cmps
sqsort: 109908804 Plain Sedgewick quicksort
NFsort: 78698058 Sedgewick loop Leapfrog quicksort
Total movs
sqsort: 58868892
NFsort: 171151950
/* END e_driver.c program output */
--
pete
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-05-11 19:42 -0700 |
| Message-ID | <rubrum-67B442.19420811052011@news.albasani.net> |
| In reply to | #497 |
In article <lnwrhxlvms.fsf@nuthaus.mib.org>, Keith Thompson <kst-u@mib.org> wrote: > Michael Press <rubrum@pacbell.net> writes: > [...] > > By the way, qsort(3) has an irremediable security hole. > > Can you expand on that? Is it something Unix-specific, or does it > affect any C implementation (note the cross-post). > > (I presume you're aware that qsort() needn't use the Quicksort > algorithm.) Sorry. Meant quicksort. Quicksort can be induced to follow its O(n^2) worst case. -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2011-05-15 00:23 +0300 |
| Message-ID | <87r581ugbe.fsf@bazspaz.fatphil.org> |
| In reply to | #545 |
Michael Press <rubrum@pacbell.net> writes: > In article <lnwrhxlvms.fsf@nuthaus.mib.org>, > Keith Thompson <kst-u@mib.org> wrote: > > > Michael Press <rubrum@pacbell.net> writes: > > [...] > > > By the way, qsort(3) has an irremediable security hole. > > > > Can you expand on that? Is it something Unix-specific, or does it > > affect any C implementation (note the cross-post). > > > > (I presume you're aware that qsort() needn't use the Quicksort > > algorithm.) > > Sorry. Meant quicksort. Quicksort can be induced to > follow its O(n^2) worst case. If your security if governed by the speed at which operations are completed, you probably don't have any actual security anyway. In particular what you is strange given that it's often the case that in order to improve security you prefer things slower. And getting to the root of things, since when has "a worst-case O(n^2) algorithm may, in worst case, take O(n^2) operations" been a security hole. Citations, rather than flim-flam, would be nice. Phil -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." -- Matthew Vernon
[toc] | [prev] | [next] | [standalone]
| From | pacman@kosh.dhis.org (Alan Curry) |
|---|---|
| Date | 2011-05-14 22:30 +0000 |
| Message-ID | <iqmvpf$b0f$1@speranza.aioe.org> |
| In reply to | #563 |
In article <87r581ugbe.fsf@bazspaz.fatphil.org>, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote: > >And getting to the root of things, since when has "a worst-case >O(n^2) algorithm may, in worst case, take O(n^2) operations" been >a security hole. Citations, rather than flim-flam, would be nice. You must be sure that hostile input can't turn the worst case into the average. That's called an "algorithmic complexity attack". It's only denial of service, not privilege escalation, but still... it's been a recognized category of security issues for a few years. Look it up. -- Alan Curry
[toc] | [prev] | [next] | [standalone]
| From | "Ersek, Laszlo" <lacos@caesar.elte.hu> |
|---|---|
| Date | 2011-05-15 18:21 +0200 |
| Message-ID | <Pine.LNX.4.64.1105151819200.31276@login03.caesar.elte.hu> |
| In reply to | #564 |
On Sat, 14 May 2011, Alan Curry wrote: > In article <87r581ugbe.fsf@bazspaz.fatphil.org>, > Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote: >> >> And getting to the root of things, since when has "a worst-case >> O(n^2) algorithm may, in worst case, take O(n^2) operations" been >> a security hole. Citations, rather than flim-flam, would be nice. > > You must be sure that hostile input can't turn the worst case into the > average. That's called an "algorithmic complexity attack". It's only denial > of service, not privilege escalation, but still... it's been a recognized > category of security issues for a few years. Look it up. An example: http://en.wikipedia.org/wiki/ReDoS http://swtch.com/~rsc/regexp/regexp1.html lacos
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2011-05-16 04:19 +0300 |
| Message-ID | <87iptbv3up.fsf@bazspaz.fatphil.org> |
| In reply to | #564 |
pacman@kosh.dhis.org (Alan Curry) writes: > In article <87r581ugbe.fsf@bazspaz.fatphil.org>, > Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote: > > > >And getting to the root of things, since when has "a worst-case > >O(n^2) algorithm may, in worst case, take O(n^2) operations" been > >a security hole. Citations, rather than flim-flam, would be nice. > > You must be sure that hostile input can't turn the worst case into the > average. I'm aware of sentences that make sense, and that one doesn't. I would say "try again", but I would't mean it. Phil -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." -- Matthew Vernon
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-16 08:40 -0700 |
| Message-ID | <lnmximfyca.fsf@nuthaus.mib.org> |
| In reply to | #570 |
Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> pacman@kosh.dhis.org (Alan Curry) writes:
>> In article <87r581ugbe.fsf@bazspaz.fatphil.org>,
>> Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
>> >
>> >And getting to the root of things, since when has "a worst-case
>> >O(n^2) algorithm may, in worst case, take O(n^2) operations" been
>> >a security hole. Citations, rather than flim-flam, would be nice.
>>
>> You must be sure that hostile input can't turn the worst case into the
>> average.
>
> I'm aware of sentences that make sense, and that one doesn't.
> I would say "try again", but I would't mean it.
It seemed clear enough to me, though perhaps a bit awkwardly phrased.
Quicksort is O(n log n) in the average case, O(N^2) in the worst
case. But that "average case" assumes random input. If Quicksort
is running in an environment where an attacker can feed it carefully
crafted input, its average case can become O(N^2), where the averate
is computed over the set of inputs it actually receives. This can
be used as a denial-of=service attack, which can, in some cases,
constitute a security hole.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-05-16 17:53 +0100 |
| Message-ID | <0.87a5c50b680ce02d158c.20110516175320BST.87zkmmvb7j.fsf@bsb.me.uk> |
| In reply to | #574 |
Keith Thompson <kst-u@mib.org> writes: > Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes: >> pacman@kosh.dhis.org (Alan Curry) writes: >>> In article <87r581ugbe.fsf@bazspaz.fatphil.org>, >>> Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote: >>> > >>> >And getting to the root of things, since when has "a worst-case >>> >O(n^2) algorithm may, in worst case, take O(n^2) operations" been >>> >a security hole. Citations, rather than flim-flam, would be nice. >>> >>> You must be sure that hostile input can't turn the worst case into the >>> average. >> >> I'm aware of sentences that make sense, and that one doesn't. >> I would say "try again", but I would't mean it. > > It seemed clear enough to me, though perhaps a bit awkwardly phrased. > > Quicksort is O(n log n) in the average case, O(N^2) in the worst > case. But that "average case" assumes random input. If Quicksort > is running in an environment where an attacker can feed it carefully > crafted input, its average case can become O(N^2), where the averate > is computed over the set of inputs it actually receives. This can > be used as a denial-of=service attack, which can, in some cases, > constitute a security hole. This, too, seems awkward to me and it perpetuates a misunderstanding about Big O -- it's not a lower bound, only an upper bound. Carefully crafted input can't make quicksort become O(n^2) because it already is. It's also O(n^3). The simplest fix is just to say that it is "no longer O(n log n)" when the cost is taken over all these "bad" inputs. Picking a new, higher, upper bound does not help express the meaning. In day-to-day chat, O(f) has acquired a meaning much more like Theta(f) but, just as you don't like "implicit casts" it seems to me nonsensical to use it in this loose way. If you translate to a literal bound you can see how odd it sounds: "my sort takes less than a minute to run on average, but with malicious input it can be made to take less than a year". -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Nicolas George <nicolas$george@salle-s.org> |
|---|---|
| Date | 2011-05-16 16:58 +0000 |
| Message-ID | <4dd157cb$0$13296$426a74cc@news.free.fr> |
| In reply to | #574 |
Keith Thompson , dans le message <lnmximfyca.fsf@nuthaus.mib.org>, a écrit : > Quicksort is O(n log n) in the average case, O(N^2) in the worst > case. But that "average case" assumes random input. If Quicksort > is running in an environment where an attacker can feed it carefully > crafted input, its average case can become O(N^2), where the averate > is computed over the set of inputs it actually receives. This can > be used as a denial-of=service attack, which can, in some cases, > constitute a security hole. Real world input is not random, even when there is no attack going on. With real world data, sorting an array that is already almost sorted is quite common, and this precisely the case that makes the quick sort quadratic. Therefore, a good quick sort implementation needs to be more subtle than that. The simplest way of doing it is also the best: just randomize the choice of the pivot, and the quadratic case fade to a negligible probability, and assuming a good PRNG, even with crafted input.
[toc] | [prev] | [next] | [standalone]
| From | Barry Margolin <barmar@alum.mit.edu> |
|---|---|
| Date | 2011-05-16 21:39 -0400 |
| Message-ID | <barmar-91C45E.21395016052011@news.eternal-september.org> |
| In reply to | #574 |
In article <lnmximfyca.fsf@nuthaus.mib.org>, Keith Thompson <kst-u@mib.org> wrote: > Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes: > > pacman@kosh.dhis.org (Alan Curry) writes: > >> In article <87r581ugbe.fsf@bazspaz.fatphil.org>, > >> Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote: > >> > > >> >And getting to the root of things, since when has "a worst-case > >> >O(n^2) algorithm may, in worst case, take O(n^2) operations" been > >> >a security hole. Citations, rather than flim-flam, would be nice. > >> > >> You must be sure that hostile input can't turn the worst case into the > >> average. > > > > I'm aware of sentences that make sense, and that one doesn't. > > I would say "try again", but I would't mean it. > > It seemed clear enough to me, though perhaps a bit awkwardly phrased. > > Quicksort is O(n log n) in the average case, O(N^2) in the worst > case. But that "average case" assumes random input. If Quicksort > is running in an environment where an attacker can feed it carefully > crafted input, its average case can become O(N^2), where the averate > is computed over the set of inputs it actually receives. This can > be used as a denial-of=service attack, which can, in some cases, > constitute a security hole. If an attacker wants to make your system spend huge amounts of time sorting, he can simply feed it arbitrarily large inputs. Regardless of the algorithm, more input means more CPU time used. So it's kind of silly to worry about an attacker when designing something like this, and more useful to design the algorithm around the expected normal input. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-17 09:12 -0700 |
| Message-ID | <lnk4dpe273.fsf@nuthaus.mib.org> |
| In reply to | #577 |
Barry Margolin <barmar@alum.mit.edu> writes:
> In article <lnmximfyca.fsf@nuthaus.mib.org>,
> Keith Thompson <kst-u@mib.org> wrote:
[...]
>> Quicksort is O(n log n) in the average case, O(N^2) in the worst
>> case. But that "average case" assumes random input. If Quicksort
>> is running in an environment where an attacker can feed it carefully
>> crafted input, its average case can become O(N^2), where the averate
>> is computed over the set of inputs it actually receives. This can
>> be used as a denial-of=service attack, which can, in some cases,
>> constitute a security hole.
>
> If an attacker wants to make your system spend huge amounts of time
> sorting, he can simply feed it arbitrarily large inputs. Regardless of
> the algorithm, more input means more CPU time used.
>
> So it's kind of silly to worry about an attacker when designing
> something like this, and more useful to design the algorithm around the
> expected normal input.
(I don't remember who pointed this out, but yes, in an earlier
article I was sloppy in my use of big-O notation.)
It's probably easier to guard against unreasonably large inputs.
(A slow network connection will do the job nicely.) It's harder
to guard against attacks where a large input causes the program
to consume vastly more resources than another input of exactly the
same size.
If I were designing a program that needs to sort arrays whose
contents are not under my control, I'd avoid using an algorithm
whose run-time behavior can vary tremendously depending on the
nature of the input -- not just because of the possibility of
malicious attacks, but because even random data could conceivably
cause the same problem. Even if the problem is unlikely to occur,
it's good to have one less thing to worry about.
If this were difficult to do, I'd stop and consider whether it's
worth the effort, but it shouldn't be. Though a naive Quicksort
algorithm does suffer from this problem, my guess is that most,
perhaps all, library sorting algorithms avoid it, either by tweaking
Quicksort or by using a different algorithm.
A concrete question: Are there any existing C library implementations
of qsort() that are vulnerable to this kind of problem?
--
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 | "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> |
|---|---|
| Date | 2011-05-17 10:20 -0700 |
| Message-ID | <c314adca-7b06-4146-9afa-f02e5d523e96@g12g2000yqd.googlegroups.com> |
| In reply to | #586 |
On May 17, 11:12 am, Keith Thompson <ks...@mib.org> wrote: > Barry Margolin <bar...@alum.mit.edu> writes: > > In article <lnmximfyca....@nuthaus.mib.org>, > > Keith Thompson <ks...@mib.org> wrote: > [...] > >> Quicksort is O(n log n) in the average case, O(N^2) in the worst > >> case. But that "average case" assumes random input. If Quicksort > >> is running in an environment where an attacker can feed it carefully > >> crafted input, its average case can become O(N^2), where the averate > >> is computed over the set of inputs it actually receives. This can > >> be used as a denial-of=service attack, which can, in some cases, > >> constitute a security hole. > > > If an attacker wants to make your system spend huge amounts of time > > sorting, he can simply feed it arbitrarily large inputs. Regardless of > > the algorithm, more input means more CPU time used. > > > So it's kind of silly to worry about an attacker when designing > > something like this, and more useful to design the algorithm around the > > expected normal input. > > (I don't remember who pointed this out, but yes, in an earlier > article I was sloppy in my use of big-O notation.) > > It's probably easier to guard against unreasonably large inputs. > (A slow network connection will do the job nicely.) It's harder > to guard against attacks where a large input causes the program > to consume vastly more resources than another input of exactly the > same size. > > If I were designing a program that needs to sort arrays whose > contents are not under my control, I'd avoid using an algorithm > whose run-time behavior can vary tremendously depending on the > nature of the input -- not just because of the possibility of > malicious attacks, but because even random data could conceivably > cause the same problem. Even if the problem is unlikely to occur, > it's good to have one less thing to worry about. > > If this were difficult to do, I'd stop and consider whether it's > worth the effort, but it shouldn't be. Though a naive Quicksort > algorithm does suffer from this problem, my guess is that most, > perhaps all, library sorting algorithms avoid it, either by tweaking > Quicksort or by using a different algorithm. > > A concrete question: Are there any existing C library implementations > of qsort() that are vulnerable to this kind of problem? Based solely on personal experience, I believe most C qsorts actually implement some version of quicksort, and are vulnerable. A few do introsort, and introsort is fairly common for C++ sort. I've also seen one qsort that implemented heapsort* (which would not have the issue). I think the issue is mainly history - most of the C implementations have been around longer than introsort, and fall into the if-it-ain't-broke category. *arguably a better general purpose choice than quicksort, but that’s a different topic
[toc] | [prev] | [next] | [standalone]
| From | pete <pfiland@mindspring.com> |
|---|---|
| Date | 2011-05-17 15:00 -0400 |
| Message-ID | <4DD2C5BF.5CB0@mindspring.com> |
| In reply to | #588 |
robertwessel2@yahoo.com wrote: > > On May 17, 11:12 am, Keith Thompson <ks...@mib.org> wrote: > > Barry Margolin <bar...@alum.mit.edu> writes: > > > In article <lnmximfyca....@nuthaus.mib.org>, > > > Keith Thompson <ks...@mib.org> wrote: > > [...] > > >> Quicksort is O(n log n) in the average case, > > >> O(N^2) in the worst case. > > A concrete question: Are there any existing C library > > implementations > > of qsort() that are vulnerable to this kind of problem? > Based solely on personal experience, I believe most C qsorts actually > implement some version of quicksort, and are vulnerable. A few do > introsort, and introsort is fairly common for C++ sort. I've also > seen one qsort that implemented heapsort* (which would not have the > issue). I think the issue is mainly history - most of the C > implementations have been around longer than introsort, and fall into > the if-it-ain't-broke category. > > *arguably a better general purpose choice than quicksort, but that’s a > different topic It's been a few years since I've looked at a library implementation of qsort, but not much more than a few years. I've seen some remarkably bad ones, and never a remarkably good one. -- pete
[toc] | [prev] | [next] | [standalone]
| From | pacman@kosh.dhis.org (Alan Curry) |
|---|---|
| Date | 2011-05-17 20:28 +0000 |
| Message-ID | <iqulop$8mf$1@speranza.aioe.org> |
| In reply to | #586 |
In article <lnk4dpe273.fsf@nuthaus.mib.org>, Keith Thompson <kst-u@mib.org> wrote: >Barry Margolin <barmar@alum.mit.edu> writes: >> In article <lnmximfyca.fsf@nuthaus.mib.org>, >> Keith Thompson <kst-u@mib.org> wrote: >[...] >>> Quicksort is O(n log n) in the average case, O(N^2) in the worst >>> case. But that "average case" assumes random input. If Quicksort >>> is running in an environment where an attacker can feed it carefully >>> crafted input, its average case can become O(N^2), where the averate >>> is computed over the set of inputs it actually receives. This can >>> be used as a denial-of=service attack, which can, in some cases, >>> constitute a security hole. >> >> If an attacker wants to make your system spend huge amounts of time >> sorting, he can simply feed it arbitrarily large inputs. Regardless of >> the algorithm, more input means more CPU time used. >> >> So it's kind of silly to worry about an attacker when designing >> something like this, and more useful to design the algorithm around the >> expected normal input. > >(I don't remember who pointed this out, but yes, in an earlier >article I was sloppy in my use of big-O notation.) > >It's probably easier to guard against unreasonably large inputs. >(A slow network connection will do the job nicely.) It's harder That's great. You run an Internet service that handles a zillion transactions per day, it's someone figures out how to make an algorithm degenerate to the worst case, he brings your server farm to permanent 100% CPU usage with a series of malicious packets that use up only .0001% of your network bandwidth. What's your solution? Host the service on a 9600-baud modem! That'll stop the attack! And your other users too. But they were an unreasonably large group. Did anybody read the Algorithmic Complexity Attacks paper before rushing to post their ignorant opinions? It matters a lot whether denial of service can be accomplished by an attacker without superior network bandwidth. That's why people who make widely used server software have responded to issues of this nature with algorithm modifications, not with "DoS defense is hard, let's go shopping" -- Alan Curry
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-17 14:45 -0700 |
| Message-ID | <lnboz1dmsh.fsf@nuthaus.mib.org> |
| In reply to | #595 |
pacman@kosh.dhis.org (Alan Curry) writes:
> In article <lnk4dpe273.fsf@nuthaus.mib.org>,
> Keith Thompson <kst-u@mib.org> wrote:
[...]
>>It's probably easier to guard against unreasonably large inputs.
>>(A slow network connection will do the job nicely.) It's harder
>
> That's great. You run an Internet service that handles a zillion transactions
> per day, it's someone figures out how to make an algorithm degenerate to the
> worst case, he brings your server farm to permanent 100% CPU usage with a
> series of malicious packets that use up only .0001% of your network
> bandwidth. What's your solution? Host the service on a 9600-baud modem!
> That'll stop the attack! And your other users too. But they were an
> unreasonably large group.
>
> Did anybody read the Algorithmic Complexity Attacks paper before rushing to
> post their ignorant opinions?
Did you really think my passing remark about a slow network connection
was seriously intended as a solution to the problem?
It wasn't. It was a joke.
Sheesh.
[...]
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-17 14:51 -0700 |
| Message-ID | <ln7h9pdmie.fsf@nuthaus.mib.org> |
| In reply to | #586 |
Keith Thompson <kst-u@mib.org> writes:
[...]
> If I were designing a program that needs to sort arrays whose
> contents are not under my control, I'd avoid using an algorithm
> whose run-time behavior can vary tremendously depending on the
> nature of the input -- not just because of the possibility of
> malicious attacks, but because even random data could conceivably
> cause the same problem. Even if the problem is unlikely to occur,
> it's good to have one less thing to worry about.
>
> If this were difficult to do, I'd stop and consider whether it's
> worth the effort, but it shouldn't be. Though a naive Quicksort
> algorithm does suffer from this problem, my guess is that most,
> perhaps all, library sorting algorithms avoid it, either by tweaking
> Quicksort or by using a different algorithm.
On re-reading this, I realize that the sentence
If this were difficult to do, I'd stop and consider whether it's
worth the effort, but it shouldn't be.
was unclear. I meant that it shouldn't be difficult to do, not
that it shouldn't be worth the effort.
> A concrete question: Are there any existing C library implementations
> of qsort() that are vulnerable to this kind of problem?
I took a look at the glibc implementation of qsort(). It does
use Quicksort, but with some tweaks. It picks the pivot using a
median-of-three decision tree, it falls back to insertion sort for
small segments, it uses an explicit stack rather than recursion,
and it always handles the larger partition first. I don't know
whether this completely avoids the worst-case N**2 behavior or not,
but it should make it less likely to happen accidentally.
--
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]
Page 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
Back to top | Article view | comp.unix.programmer
csiph-web