Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.programmer > #306 > unrolled thread

Avoiding recursive stack overflow in C on Unix/Linux?

Back to article view | Back to comp.unix.programmer

Contents

  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 7 of 14 — ← Prev page 1 … 5 6 [7] 8 9 … 14  Next page →

#483

In article <87zkmvhyqm.fsf@temporary-address.org.uk>,
 Dr Nick <3-nospam@temporary-address.org.uk> wrote:

> Måns Rullgård <mans@mansr.com> writes:
> 
> > Assuming you believe in unit tests at all, testing the unit containing
> > the search will cover it, and that has to be done regardless of
> > implementation.  I have yet to see anyone write separate unit tests for
> > every line of code.
> 
> I'm not a unit test freak, but if you write a binary search (something
> that's surprisingly difficult to get right in my limited experience) you
> absolutely have to test it on - at least - "item is in the list"
> (specifically testing first item, last item, exact middle item), "item
> is not in the list" (specifically testing off the top, off the bottom)
> and probably a couple of others.
> 
> Otherwise you will find that it works fine on your test data and fails
> in actual use.

Students are set exercises. The purpose of an exercise
is to get stronger. Sometimes binary search is offered.
The idea is to discover the loop invariant. Eventually
the student learns to write for the edge and corner cases 
_first_. Thus a purpose of the exercises is realized.
I am surprised at how many people here admit to not
knowing how to write a binary search.

> Obviously there has to be a line somewhere between code you write
> yourself (or the library would be every programme you ever need to
> write) and code you don't (or C would only have putchar and would leave
> to write puts and printf etc).  But unless you are desperate to avoid
> the call to the comparison function (do I read the thread as saying that
> C++ avoids this by inlining?) I think binary search lives on the library
> side of the line.

The idea is that in writing a binary search in place
one avoids having to write an interface to a library
routine. I embed bits of code in the search routine
itself, rather than interpreting the library routine
results and then doing what I need. 

I cannot see myself ever calling bsearch(3). I will
call qsort(3). Note the existence of qsort_r.
Sometimes I'll write an insertion sort with binary
search. Sometimes I'll write a heapsort. This stuff
is not hard.

-- 
Michael Press

[toc] | [prev] | [next] | [standalone]

#485

On May 10, 3:24 pm, Michael Press <rub...@pacbell.net> wrote:
> In article <87zkmvhyqm....@temporary-address.org.uk>,
>  Dr Nick <3-nos...@temporary-address.org.uk> wrote:
>
>
>
> > Måns Rullgård <m...@mansr.com> writes:
>
> > > Assuming you believe in unit tests at all, testing the unit containing
> > > the search will cover it, and that has to be done regardless of
> > > implementation.  I have yet to see anyone write separate unit tests for
> > > every line of code.
>
> > I'm not a unit test freak, but if you write a binary search (something
> > that's surprisingly difficult to get right in my limited experience) you
> > absolutely have to test it on - at least - "item is in the list"
> > (specifically testing first item, last item, exact middle item), "item
> > is not in the list" (specifically testing off the top, off the bottom)
> > and probably a couple of others.
>
> > Otherwise you will find that it works fine on your test data and fails
> > in actual use.
>
> Students are set exercises. The purpose of an exercise
> is to get stronger. Sometimes binary search is offered.
> The idea is to discover the loop invariant. Eventually
> the student learns to write for the edge and corner cases
> _first_. Thus a purpose of the exercises is realized.
> I am surprised at how many people here admit to not
> knowing how to write a binary search.
>
> > Obviously there has to be a line somewhere between code you write
> > yourself (or the library would be every programme you ever need to
> > write) and code you don't (or C would only have putchar and would leave
> > to write puts and printf etc).  But unless you are desperate to avoid
> > the call to the comparison function (do I read the thread as saying that
> > C++ avoids this by inlining?) I think binary search lives on the library
> > side of the line.
>
> The idea is that in writing a binary search in place
> one avoids having to write an interface to a library
> routine. I embed bits of code in the search routine
> itself, rather than interpreting the library routine
> results and then doing what I need.
>
> I cannot see myself ever calling bsearch(3). I will
> call qsort(3). Note the existence of qsort_r.
> Sometimes I'll write an insertion sort with binary
> search. Sometimes I'll write a heapsort. This stuff
> is not hard.

In this day and age with more and more glue coders, knowing how to
write a binary search is not required anymore.  Beneficial yes, but
not required for many programmers.  However, having someone on the
team that can do algorithm work when needed is still vital.

And I agree that bsearch is not hard with some study, but you've then
doomed yourself to cut-and-paste search algorithms for every little
quirk of data type or search semantic.  There are methods to abstract
bsearch within an array container that make it quite useful, and the
value of providing a canned search algorithm to less skilled coders
cannot be understated.

(crosses fingers that my bsearch is "right")

\code snippet
/*!
 * \brief Searches a \c c_array for an object that matches the given
 *        value using a binary search algorithm.
 * \param array A \c c_array.
 * \param object The object to find.
 * \param cmp_fn The function to call for each object comparison.  It
 *               should return 0 when the objects match.
 * \param type The object type.
 * \return The address of the object in the array, or \c NULL if the
 *         object is not found in the array.
 *
 * The \c c_array_bsearch function requires the array to be sorted
 * prior using this to search objects in the array.  This sorting
 * can be done during insertion using \c c_array_insert_sorted, or
 * after all the objects have been inserted into the array using
 * \c c_array_sort.  If the \c c_array is not sorted, there is the
 * possibility for false negatives.
 *
 * The binary search algorithm is preferred for large arrays of
 * objects as the performance of the algorithm is O(log n) rather
 * than O(n) for the \c c_array_search and \c c_array_rsearch
 * functions.  Keep in mind that if duplicate objects are in the
 * array, the \c c_array_bsearch algorithm may point to any one of
 * them rather than the first or last instance of the object.
 */
#define c_array_bsearch( array, object, cmp_fn, type ) ( (type*)
(gc_array_bsearch( (array), (object), (cmp_fn), sizeof(type) )) )

void* gc_array_bsearch( struct c_array* array,
                        const void* object,
                        c_compare_function cmp_fn,
                        size_t type_sz )
{
  void* found = NULL;
  ssize_t l, h, m;
  void* m_p;
  int cmp;

  if ( array && cmp_fn )
  {
    C_ASSERT( array->element_size == type_sz );

    if ( array->size )
    {
      /*
       * l - low boundary of region to search
       * h - high boundary of region to search
       * m - median of region to search (if array is sorted)
       * m_p - pointer to the corresponding median object in the
array.
       */
      l = 0;
      h = array->size - 1;

      while ( l <= h )
      {
        /*
         * The following statement gets the midpoint of the range,
         * by obtaining the average using a slightly obtuse method.
         *
         * The normal method to get the midpoint of a range is to
         * sum the low and high boundary and divide by 2.
         *
         * (high + low) / 2
         *
         * The problem is that this limits the maximum value of the
         * mid-point to SSIZE_MAX / 2 without encountering overflow.
         *
         * low + ((high - low) / 2)  or
         *
         * 2/2 low + 1/2 high - 1/2 low  ==  (high + low) / 2
         *
         * This still evaluates to the expression '(high + low) / 2',
         * but avoids the overflow issue from 'high + low'.
         */
        m = l + ((h - l) / 2);
        m_p = gc_array_at( array, m );

        cmp = cmp_fn( m_p, object );
        if ( cmp < 0 ) {
          l = m + 1;
        }
        else if ( cmp > 0 ) {
          h = m - 1;
        }
        else
        {
          found = m_p;
          break;
        }
      }
    }
  }

  return found;
}

/*!
 * \brief Inserts a new object into the array using the comparison
 *        function.
 * \param array A \c c_array.
 * \param object The object.
 * \param cmp_fn The function to compare objects in the array.
 * \param type The object type.
 */
#define c_array_insert_bsorted( array, object, cmp_fn, type )
(gc_array_insert_bsorted( (array), (object), (cmp_fn), sizeof(type) ))

void gc_array_insert_bsorted( struct c_array* array,
                              void* object,
                              c_compare_function cmp_fn,
                              size_t type_sz )
{
  size_t index = 0;
  ssize_t l, h, m;
  void* m_p;
  int cmp;

  if ( array )
  {
    C_ASSERT( array->element_size == type_sz );

    if ( cmp_fn )
    {
      if ( array->size )
      {
        /*
         * l - low boundary of region to search
         * h - high boundary of region to search
         * m - median of region to search (if array is sorted)
         * m_p - pointer to the corresponding median pointer in the
array.
         */
        l = 0;
        m = 0;
        h = array->size - 1;
        cmp = 0;

        while ( l <= h )
        {
          m = l + ((h - l) / 2);
          m_p = gc_array_at( array, m );

          cmp = cmp_fn( m_p, object );
          if ( cmp < 0 ) {
            l = m + 1;
          }
          else if ( cmp > 0 ) {
            h = m - 1;
          }
          else {
            break;
          }
        }

        /*
         * At the end of the loop, the value of cmp will determine
which
         * side of the object referenced by 'm_p' to insert the
object.
         * If the object at 'm_p' is equal or greater than the object
         * to be inserted, the insert should place the object before
the
         * location 'm'.  If it is less, the object should be placed
         * after location 'm'.
         */
        index = m;
        if ( cmp < 0 ) {
          ++index;
        }
      }
    }

    gc_array_insert( array, index, object, array->element_size );
  }
}
\endcode

By creating appropriate comparison functions, one can sort and search
based on different fields of a structure quite easily.  In my opinion,
writing a valid comparison function is much easier than man-coding
each search as you need them, especially if your struct has several
members to sort and search on.  You admit to using qsort, but don't
see the benefit of bsearch?  Doesn't seem logical to me.

The real question is whether one should in general trust the standard
C library bsearch implementation over yet another custom coded binary
search that some other programmer designed?  If you're creating a
binary search with sprinkles, like one that modifies the container
while searching, that is something different.

Best regards,
John D.

[toc] | [prev] | [next] | [standalone]

#526

ImpalerCore wrote:

>   ssize_t l

>        * l - low boundary of region to search

>       l = 0;

I don't like 'l' as a name for a variable.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#527

ImpalerCore wrote:

>       /*
>        * l - low boundary of region to search
>        * h - high boundary of region to search
>        * m - median of region to search (if array is sorted)
>        * m_p - pointer to the corresponding median object in the
> array.
>        */
>       l = 0;
>       h = array->size - 1;

>           l = m + 1;

>           h = m - 1;

I don't use any of those 1's (ones), 
when I write binary search.

I let the initial value of h 
be equal to the index of the element 
which is one past the end of the array.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#551

On May 11, 8:54 am, pete <pfil...@mindspring.com> wrote:
> ImpalerCore wrote:
> >       /*
> >        * l - low boundary of region to search
> >        * h - high boundary of region to search
> >        * m - median of region to search (if array is sorted)
> >        * m_p - pointer to the corresponding median object in the
> > array.
> >        */
> >       l = 0;
> >       h = array->size - 1;
> >           l = m + 1;
> >           h = m - 1;
>
> I don't use any of those 1's (ones),
> when I write binary search.
>
> I let the initial value of h
> be equal to the index of the element
> which is one past the end of the array.

Both good points.  Thank you.  I tend to forget how close 1 and l
appear.

[toc] | [prev] | [next] | [standalone]

#490

Michael Press <rubrum@pacbell.net> writes:

> In article <87zkmvhyqm.fsf@temporary-address.org.uk>,
>  Dr Nick <3-nospam@temporary-address.org.uk> wrote:
>
>> Måns Rullgård <mans@mansr.com> writes:
>> 
>> > Assuming you believe in unit tests at all, testing the unit containing
>> > the search will cover it, and that has to be done regardless of
>> > implementation.  I have yet to see anyone write separate unit tests for
>> > every line of code.
>> 
>> I'm not a unit test freak, but if you write a binary search (something
>> that's surprisingly difficult to get right in my limited experience) you
>> absolutely have to test it on - at least - "item is in the list"
>> (specifically testing first item, last item, exact middle item), "item
>> is not in the list" (specifically testing off the top, off the bottom)
>> and probably a couple of others.
>> 
>> Otherwise you will find that it works fine on your test data and fails
>> in actual use.
>
> Students are set exercises. The purpose of an exercise
> is to get stronger. Sometimes binary search is offered.
> The idea is to discover the loop invariant. Eventually
> the student learns to write for the edge and corner cases 
> _first_. Thus a purpose of the exercises is realized.
> I am surprised at how many people here admit to not
> knowing how to write a binary search.

I didn't say I didn't know how to write a binary search.  I said "it's
surprisingly difficult".  I've written binary searches in machine code,
C and higher-level languages.  We're not talking about students here:
we're talking about programmers for whatever reason wanting (needing?)
the quickest and easiest route to high-performance and maintainable
code.

Just because my great-great-great-grandfather had to cut peat for his
fire doesn't mean I can't use gas you know.

>> Obviously there has to be a line somewhere between code you write
>> yourself (or the library would be every programme you ever need to
>> write) and code you don't (or C would only have putchar and would leave
>> to write puts and printf etc).  But unless you are desperate to avoid
>> the call to the comparison function (do I read the thread as saying that
>> C++ avoids this by inlining?) I think binary search lives on the library
>> side of the line.
>
> The idea is that in writing a binary search in place
> one avoids having to write an interface to a library
> routine. I embed bits of code in the search routine
> itself, rather than interpreting the library routine
> results and then doing what I need. 
>
> I cannot see myself ever calling bsearch(3). I will
> call qsort(3). Note the existence of qsort_r.
> Sometimes I'll write an insertion sort with binary
> search. Sometimes I'll write a heapsort. This stuff
> is not hard.

So you actually agree, you just draw the line between qsort and
bsearch.  That's fine - everybody draws it somewhere.  It's just nice to
see you actually agree.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

[toc] | [prev] | [next] | [standalone]

#492

In article <87aaeui0ic.fsf@temporary-address.org.uk>,
 Dr Nick <3-nospam@temporary-address.org.uk> wrote:

> Michael Press <rubrum@pacbell.net> writes:
> 
> > In article <87zkmvhyqm.fsf@temporary-address.org.uk>,
> >  Dr Nick <3-nospam@temporary-address.org.uk> wrote:
> >
> >> Måns Rullgård <mans@mansr.com> writes:
> >> 
> >> > Assuming you believe in unit tests at all, testing the unit containing
> >> > the search will cover it, and that has to be done regardless of
> >> > implementation.  I have yet to see anyone write separate unit tests for
> >> > every line of code.
> >> 
> >> I'm not a unit test freak, but if you write a binary search (something
> >> that's surprisingly difficult to get right in my limited experience) you
> >> absolutely have to test it on - at least - "item is in the list"
> >> (specifically testing first item, last item, exact middle item), "item
> >> is not in the list" (specifically testing off the top, off the bottom)
> >> and probably a couple of others.
> >> 
> >> Otherwise you will find that it works fine on your test data and fails
> >> in actual use.
> >
> > Students are set exercises. The purpose of an exercise
> > is to get stronger. Sometimes binary search is offered.
> > The idea is to discover the loop invariant. Eventually
> > the student learns to write for the edge and corner cases 
> > _first_. Thus a purpose of the exercises is realized.
> > I am surprised at how many people here admit to not
> > knowing how to write a binary search.
> 
> I didn't say I didn't know how to write a binary search.  I said "it's
> surprisingly difficult".  

Relative to what? All it takes is knowing the loop
invariant. If a guy does not know it he has to work at
it until he does. Until then it is impossible for him
to write a binary search. When he knows it, then it
writes itself.

> I've written binary searches in machine code,
> C and higher-level languages.  We're not talking about students here:
> we're talking about programmers for whatever reason wanting (needing?)
> the quickest and easiest route to high-performance and maintainable
> code.
> 
> Just because my great-great-great-grandfather had to cut peat for his
> fire doesn't mean I can't use gas you know.

That is not what I am saying, and I do not see
why you say I am. I am saying that a locally
written code can be adapted to and integrated
with the task at hand. You better know about
cutting peat if you want to brew whisky. 

> >> Obviously there has to be a line somewhere between code you write
> >> yourself (or the library would be every programme you ever need to
> >> write) and code you don't (or C would only have putchar and would leave
> >> to write puts and printf etc).  But unless you are desperate to avoid
> >> the call to the comparison function (do I read the thread as saying that
> >> C++ avoids this by inlining?) I think binary search lives on the library
> >> side of the line.
> >
> > The idea is that in writing a binary search in place
> > one avoids having to write an interface to a library
> > routine. I embed bits of code in the search routine
> > itself, rather than interpreting the library routine
> > results and then doing what I need. 
> >
> > I cannot see myself ever calling bsearch(3). I will
> > call qsort(3). Note the existence of qsort_r.
> > Sometimes I'll write an insertion sort with binary
> > search. Sometimes I'll write a heapsort. This stuff
> > is not hard.
> 
> So you actually agree, you just draw the line between qsort and
> bsearch.  That's fine - everybody draws it somewhere.  It's just nice to
> see you actually agree.

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.

-- 
Michael Press

[toc] | [prev] | [next] | [standalone]

#496

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/

-- 
pete

[toc] | [prev] | [next] | [standalone]

#498

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's a flaw in qsort that I make sure I don't put in my qsort-like
functions: it needs to take another void pointer and pass it to the
comparison function.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

[toc] | [prev] | [next] | [standalone]

#523

Dr Nick <3-nospam@temporary-address.org.uk> writes:

>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's a flaw in qsort that I make sure I don't put in my qsort-like
>functions: it needs to take another void pointer and pass it to the
>comparison function.

I've never needed that argument; what use do you have for that argument?

Casper
-- 

[toc] | [prev] | [next] | [standalone]

#529

On 05/11/2011 07:48 AM, Casper H.S. Dik wrote:
> Dr Nick <3-nospam@temporary-address.org.uk> writes:
...
>> There's a flaw in qsort that I make sure I don't put in my qsort-like
>> functions: it needs to take another void pointer and pass it to the
>> comparison function.
> 
> I've never needed that argument; what use do you have for that argument?

The simplest example I can come up with is:

int compare_element_n(void*first, void*second, void*args)
{
    size_t n = *(size_t*)args;
    int *left = first;
    int *right = second;
    return left[n] < right[n] ? -1 : right[n] < left[n] ? 1 : 0;
}

Example of use:
    int array[1024][3];	/* Array of 3-d positions. */
    int n;

    /* Sort by x coordinate: */
    n = 0;
    new_qsort(array, 1024, sizeof array[0], compare_element_n, &n);

    /* Sort by z coordinate: */
    n = 2;
    new_qsort(array, 1024, sizeof array[0], compare_element_n, &n);

-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#530

On 05/11/2011 10:03 AM, James Kuyper wrote:
...
> int compare_element_n(void*first, void*second, void*args)
> {
>     size_t n = *(size_t*)args;
>     int *left = first;
>     int *right = second;
>     return left[n] < right[n] ? -1 : right[n] < left[n] ? 1 : 0;
> }
> 
> Example of use:
>     int array[1024][3];	/* Array of 3-d positions. */
>     int n;

That should, of course, have been "size_t n;". I changed types partway
through writing this message, and didn't correct all of them to match.

>     /* Sort by x coordinate: */
>     n = 0;
>     new_qsort(array, 1024, sizeof array[0], compare_element_n, &n);


-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#540

Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> writes:

> Dr Nick <3-nospam@temporary-address.org.uk> writes:
>
>>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's a flaw in qsort that I make sure I don't put in my qsort-like
>>functions: it needs to take another void pointer and pass it to the
>>comparison function.
>
> I've never needed that argument; what use do you have for that argument?

To avoid having to write lots of comparison functions: suppose you are
sorting an array of structures with three fields and want to be able to
have any of them as primary, secondary and tertiary sort field and to
sort ascending or descending on each.

Either you write 8 comparison functions, and some nifty code to select
them (which would be quicker, true) or you need to pass some extra data
into your comparison function.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

[toc] | [prev] | [next] | [standalone]

#541

Dr Nick , dans le message <8739klgf5k.fsf@temporary-address.org.uk>, a
 écrit :
> To avoid having to write lots of comparison functions: suppose you are
> sorting an array of structures with three fields and want to be able to
> have any of them as primary, secondary and tertiary sort field and to
> sort ascending or descending on each.
> 
> Either you write 8 comparison functions, and some nifty code to select
> them (which would be quicker, true) or you need to pass some extra data
> into your comparison function.

From a performance point of view, getting your compiler to generate the code
for all eight functions will be much better, and this can be done easily
with macros.

A better example, IMHO, is this: a is a pointer to an array of struct foo, b
is an array of integers used as indices into a; a can be reallocated, so b
can not an array of pointers; you want to sort b according to the value of
the pointed structure; and you want it to be thread-safe.

[toc] | [prev] | [next] | [standalone]

#552

On May 11, 2:48 pm, Casper H.S. Dik <Casper....@OrSPaMcle.COM> wrote:
> Dr Nick <3-nos...@temporary-address.org.uk> writes:
>
> >There's a flaw in qsort that I make sure I don't put in my qsort-like
> >functions: it needs to take another void pointer and pass it to the
> >comparison function.
>
> I've never needed that argument; what use do you have for that argument?
>
We've got a list of points in 3d space, representing space invaders,
and a player, who's also a point in 3d space. We need to sort the
baddies by their distance from the player as part of the AI.
There's no way of writing the comparision function without either
using a global or setting up a temporary array, both of which are
nuisances.

[toc] | [prev] | [next] | [standalone]

#524

Dr Nick 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's a flaw in qsort that I make sure I don't put in my qsort-like
> functions: it needs to take another void pointer and pass it to the
> comparison function.

I don't understand what you mean.
qsort can pass any object type pointer 
to the comparison function.

In all of the sort functions that I've written
which are of the same function type as qsort,
a pointer to unsigned char, 
is the type that gets passed to the comparison function.

When I want to write a fast sort function,
I use what I refer to as "the e_type interface".

The user defines three macros,

something like:

#define E_TYPE          long unsigned e_type
#define MOV(A, B)       ((void)(*(A) = *(B)))
#define GT(A, B)        (*(A) > *(B))

or maybe even something like:

#define E_TYPE          char e_type[sizeof "seven"]
#include <string.h>
#define MOV(A, B)       ((void)memcpy((A), (B), sizeof *(A)))
#define GT(A, B)        (strlen(*(A)) > strlen(*(B)))

and then the form of the sort function will be something like this:

#include <stddef.h>

typedef E_TYPE;

void 
spsort(e_type *array, size_t nmemb)
{
    size_t h, t;
    e_type *i, *j, *k, *after, temp;
    
    if (nmemb > 1) {
        after = array + nmemb;
        nmemb /= 4;
        h = nmemb + 1;
        for (t = 1; nmemb != 0; nmemb /= 4) {
            t *= 2;
        }
        do {
            i = h + array;
            do {
                k = i - h;
                if (GT(k, i)) {
                    j = i;
                    MOV(&temp, j);
                    do {
                        MOV(j, k);
                        j  = k;
                        if (h + array > k) {
                            break;
                        }
                        k -= h;
                    } while (GT(k, &temp));
                    MOV(j, &temp);
                }
            } while (++i != after);
            t /= 2;
            h = t * t - t * 3 / 2 + 1;
        } while (t != 0);
    }
}

I have faster functions than that Shell sort one,
but most of them might be a little long to post.

http://www.mindspring.com/~pfilandr/C/e_driver/

-- 
pete

[toc] | [prev] | [next] | [standalone]

#544

In article <87sjslhiqa.fsf@temporary-address.org.uk>,
 Dr Nick <3-nospam@temporary-address.org.uk> 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's a flaw in qsort that I make sure I don't put in my qsort-like
> functions: it needs to take another void pointer and pass it to the
> comparison function.

You are talking about qsort_r(3)?

-- 
Michael Press

[toc] | [prev] | [next] | [standalone]

#549

Michael Press <rubrum@pacbell.net> writes:

> In article <87sjslhiqa.fsf@temporary-address.org.uk>,
>  Dr Nick <3-nospam@temporary-address.org.uk> 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's a flaw in qsort that I make sure I don't put in my qsort-like
>> functions: it needs to take another void pointer and pass it to the
>> comparison function.
>
> You are talking about qsort_r(3)?

Maybe:

~$ man qsort
[man page displays, it does not mention qsort_r]
~$ man 3 qsort_r
No manual entry for qsort_r in section 3
~$ man qsort_r
No manual entry for qsort_r

But it's still a flaw in the original design of the standard library -
any such function should take and pass on a pointer like this.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

[toc] | [prev] | [next] | [standalone]

#553

In article <87tyd0fovf.fsf@temporary-address.org.uk>,
 Dr Nick <3-nospam@temporary-address.org.uk> wrote:

> Michael Press <rubrum@pacbell.net> writes:
> 
> > In article <87sjslhiqa.fsf@temporary-address.org.uk>,
> >  Dr Nick <3-nospam@temporary-address.org.uk> 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's a flaw in qsort that I make sure I don't put in my qsort-like
> >> functions: it needs to take another void pointer and pass it to the
> >> comparison function.
> >
> > You are talking about qsort_r(3)?
> 
> Maybe:
> 
> ~$ man qsort
> [man page displays, it does not mention qsort_r]
> ~$ man 3 qsort_r
> No manual entry for qsort_r in section 3
> ~$ man qsort_r
> No manual entry for qsort_r
> 
> But it's still a flaw in the original design of the standard library -
> any such function should take and pass on a pointer like this.


     void
     qsort_r(void *base, size_t nel, size_t width, void *thunk,
         int (*compar)(void *, const void *, const void *));

     The qsort_r() function behaves identically to qsort(), except that it takes an addi-
     tional argument, thunk, which is passed unchanged as the first argument to function
     pointed to compar.  This allows the comparison function to access additional data
     without using global variables, and thus qsort_r() is suitable for use in functions
     which must be reentrant.

-- 
Michael Press

[toc] | [prev] | [next] | [standalone]

#554

Michael Press <rubrum@pacbell.net> writes:

> In article <87tyd0fovf.fsf@temporary-address.org.uk>,
>  Dr Nick <3-nospam@temporary-address.org.uk> wrote:
>
>> Michael Press <rubrum@pacbell.net> writes:
>> 
>> > In article <87sjslhiqa.fsf@temporary-address.org.uk>,
>> >  Dr Nick <3-nospam@temporary-address.org.uk> 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's a flaw in qsort that I make sure I don't put in my qsort-like
>> >> functions: it needs to take another void pointer and pass it to the
>> >> comparison function.
>> >
>> > You are talking about qsort_r(3)?
>> 
>> Maybe:
>> 
>> ~$ man qsort
>> [man page displays, it does not mention qsort_r]
>> ~$ man 3 qsort_r
>> No manual entry for qsort_r in section 3
>> ~$ man qsort_r
>> No manual entry for qsort_r
>> 
>> But it's still a flaw in the original design of the standard library -
>> any such function should take and pass on a pointer like this.
>
>
>      void
>      qsort_r(void *base, size_t nel, size_t width, void *thunk,
>          int (*compar)(void *, const void *, const void *));
>
>      The qsort_r() function behaves identically to qsort(), except that it takes an addi-
>      tional argument, thunk, which is passed unchanged as the first argument to function
>      pointed to compar.  This allows the comparison function to access additional data
>      without using global variables, and thus qsort_r() is suitable for use in functions
>      which must be reentrant.

That's the badger.  But re-entrancy is (as examples in this thread have
shown) far from the only reason for needing it.   In fact, no-one even
suggested it as an example.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

[toc] | [prev] | [next] | [standalone]

Page 7 of 14 — ← Prev page 1 … 5 6 [7] 8 9 … 14  Next page →

Back to top | Article view | comp.unix.programmer

csiph-web