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

Groups > comp.lang.c > #3254 > unrolled thread

Avoiding recursive stack overflow in C on Unix/Linux?

Back to article view | Back to comp.lang.c

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? Nobody <nobody@nowhere.com> - 2011-05-06 03:27 +0100
        Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-06 00:03 -0700
          Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 09:18 +0000
            Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-06 02:56 -0700
    Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-05 12:24 -0700
      Re: Avoiding recursive stack overflow in C on Unix/Linux? Lowell Gilbert <lgusenet@be-well.ilk.org> - 2011-05-05 15:40 -0400
        Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:18 -0700
      Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-05 21:17 +0100
        Re: Avoiding recursive stack overflow in C on Unix/Linux? Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-05-05 18:45 -0400
          Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:44 -0700
            Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 09:58 +0000
              Re: Avoiding recursive stack overflow in C on Unix/Linux? Richard Kettlewell <rjk@greenend.org.uk> - 2011-05-06 11:11 +0100
                Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 10:16 +0000
                  Re: Avoiding recursive stack overflow in C on Unix/Linux? Richard Kettlewell <rjk@greenend.org.uk> - 2011-05-06 11:28 +0100
        Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:34 -0700
          Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-06 15:09 -0700
          Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 13:03 +0100
            Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 09:01 -0400
              Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 14:32 +0100
                Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-07 16:27 +0100
                  Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 16:43 +0100
                  Re: Avoiding recursive stack overflow in C on Unix/Linux? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-08 06:19 +0000
                    Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-08 17:18 +0100
                      Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-08 09:58 -0700
                      Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-09 11:34 +0000
                  Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-11 03:48 -0700
                    Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-11 10:51 +0000
                      Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-11 08:11 -0700
                        Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-11 15:47 +0000
                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-12 15:05 -0700
              Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-07 16:23 +0000
                Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 18:12 -0400
              Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 10:30 -0700
                Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:01 +0100
                  Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 12:37 -0700
                Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 18:15 -0400
                Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-08 15:26 -0700
            Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 09:32 -0700
              Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-08 10:46 +1200
                Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 21:49 -0700
            Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 09:59 -0700
              Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 20:24 +0100
              Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-07 15:04 -0700
                Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 15:15 -0700
            Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 19:57 +0100
              Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 20:26 +0100
                Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 21:06 +0100
          Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-07 23:27 +0000
      Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-05 20:07 -0400
        Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-06 02:53 +0100
          Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 19:27 +0200
          Re: Avoiding recursive stack overflow in C on Unix/Linux? Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-18 19:54 -0700
        Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-06 10:07 +0100
        Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:58 -0700
          Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 07:08 -0400
            Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 08:18 -0700
              Re: Avoiding recursive stack overflow in C on Unix/Linux? Marco Parrone <marco@marcoparrone.com> - 2011-05-06 17:32 +0200
                Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 08:51 -0700
              Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 21:46 -0400
                Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 00:28 -0700
                  Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-07 09:01 -0400
                    Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 06:35 -0700
                      Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-07 22:52 -0400
                        Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 01:26 -0700
                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-08 09:37 +0100
                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-08 03:21 -0700
                            Re: Avoiding recursive stack overflow in C on Unix/Linux? Willem <willem@toad.stack.nl> - 2011-05-08 10:44 +0000
                              Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 07:23 -0700
                                Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-09 11:30 +0000
                                  Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-09 13:36 +0100
                                    Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-09 07:08 -0700
                                      Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 07:38 +1200
                                    Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 07:44 +1200
                                      Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-09 21:44 +0100
                                        Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 13:59 -0700
                                  Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 14:19 -0700
                                    Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 15:05 -0700
                                      Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 10:20 +1200
                                        Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 19:04 +0300
                                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-14 11:13 -0700
                                      Re: Avoiding recursive stack overflow in C on Unix/Linux? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-09 15:40 -0700
                                        Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-09 23:44 +0100
                                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 11:06 +1200
                                            Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-10 00:11 +0100
                                              Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 11:17 +1200
                                              Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-10 07:10 +0100
                                                Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 12:24 -0700
                                                  Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-05-10 13:43 -0700
                                                    Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:48 -0400
                                                    Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:54 -0400
                                                      Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-05-12 05:56 -0700
                                                  Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 00:44 +0100
                                                    Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 19:36 -0700
                                                      Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 23:21 -0400
                                                        Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 07:08 +0100
                                                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-11 11:48 +0000
                                                            Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 10:03 -0400
                                                              Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 10:12 -0400
                                                            Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 21:23 +0100
                                                            Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-12 09:45 -0700
                                                          Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:00 -0400
                                                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:35 -0700
                                                            Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-12 06:51 +0100
                                                              Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-12 14:36 -0700
                                                                Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-12 22:57 +0100
                                                        Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-11 11:47 +0000
                                                          Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:07 -0400
                                                      Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-10 21:16 -0700
                                                        Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-11 02:40 -0700
                                                          Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 09:39 -0400
                                                        Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:42 -0700
                                                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-15 00:23 +0300
                                                            Re: Avoiding recursive stack overflow in C on Unix/Linux? pacman@kosh.dhis.org (Alan Curry) - 2011-05-14 22:30 +0000
                                                              Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-16 04:19 +0300
                                                                Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-16 08:40 -0700
                                                                  Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-16 17:53 +0100
                                                                  Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-16 21:39 -0400
                                                                    Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 09:12 -0700
                                                                      Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-17 10:20 -0700
                                                                        Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-17 15:00 -0400
                                                                      Re: Avoiding recursive stack overflow in C on Unix/Linux? pacman@kosh.dhis.org (Alan Curry) - 2011-05-17 20:28 +0000
                                                                        Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 14:45 -0700
                                                                      Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 14:51 -0700
                                                                        Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-17 16:23 -0700
                                                                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-17 23:06 -0700
                                                                            Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-18 01:02 -0700
                                                                              Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-18 01:29 -0700
                                                                                Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-18 04:03 -0700
                                                                        Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Pfaff <blp@cs.stanford.edu> - 2011-05-17 16:47 -0700
                                                                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 17:21 -0700
                                                                        Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-23 21:57 +0300
                                                                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-23 21:57 +0100
                                                                          Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-23 17:45 -0700
                                                                            Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-24 11:43 +0100
                                                                              Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-24 10:58 -0700
                                                  Re: Avoiding recursive stack overflow in C on Unix/Linux? Sherm Pendley <sherm.pendley@gmail.com> - 2011-05-11 11:11 -0400
                                                    Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:48 -0700
                                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-09 16:22 -0700
                                            Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 21:25 -0700
                                              Re: Avoiding recursive stack overflow in C on Unix/Linux? Seebs <usenet-nospam@seebs.net> - 2011-05-10 17:28 +0000
                                        Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 17:11 -0700
                                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 12:20 +1200
                                            Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 03:53 -0400
                                              Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 20:18 +1200
                                                Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 04:42 -0400
                                                  Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-10 09:12 +0000
                                                    Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-10 03:21 -0700
                                                      Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-10 10:53 +0000
                                                      Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-10 08:12 -0700
                                                    Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 09:39 -0400
                                            Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 12:51 -0700
                                              Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-11 08:12 +1200
                                                Re: Avoiding recursive stack overflow in C on Unix/Linux? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-10 15:16 -0700
                                                Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 19:43 -0700
                                                  Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 07:41 -0400
                                                    Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:51 -0700
                                                Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-11 12:45 +0100
                                      Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-10 07:50 -0700
                                    Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-10 11:04 +0100
                          Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-08 09:27 -0400
                            Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 08:04 -0700
                              Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-08 22:50 -0400
                                Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 00:18 -0700
                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:49 +0100
                            Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-08 20:05 +0100
                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-08 13:44 -0700
                            Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 00:22 -0700
                        Re: Avoiding recursive stack overflow in C? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-15 17:05 +0100
                          Re: Avoiding recursive stack overflow in C? James Kuyper <jameskuyper@verizon.net> - 2011-05-15 14:07 -0400
                            Re: Avoiding recursive stack overflow in C? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-15 22:49 +0100
                              Re: Avoiding recursive stack overflow in C? James Kuyper <jameskuyper@verizon.net> - 2011-05-15 21:08 -0400
                              Re: Avoiding recursive stack overflow in C? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-16 11:10 +0100
                          Re: Avoiding recursive stack overflow in C? Ilya Zakharevich <nospam-abuse@ilyaz.org> - 2011-05-16 08:04 +0000
                Re: Avoiding recursive stack overflow in C on Unix/Linux? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-05-07 19:11 +0300
                  Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 07:17 +0200
                    Re: Avoiding recursive stack overflow in C on Unix/Linux? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-05-08 10:16 +0300
                      Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-09 09:03 +0200
      Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 08:59 +0000
        Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 03:01 -0700
          Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 07:13 -0400
            Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 09:02 -0700
        Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-06 15:41 -0700
          Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 02:53 -0700
          Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-07 16:17 +0000
            Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 10:08 -0700
              Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:20 +0100
                Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 14:26 -0700
              Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-07 14:31 -0700
                Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 22:49 -0700
            Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-07 17:22 +0000
              Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 10:24 -0700
                Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-07 17:32 +0000
                  Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 11:43 -0700
                    Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 10:57 +0000
                      Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 08:09 -0700
                        Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:41 +0100
                        Re: Avoiding recursive stack overflow in C on Unix/Linux? Shao Miller <sha0.miller@gmail.com> - 2011-05-07 21:35 -0500
                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-08 23:31 -0700
                            Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 00:26 -0700
                            Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-09 08:39 -0700
                              Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-09 09:03 -0700
                                Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 10:06 -0700
                                Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-09 17:52 -0400
                          Re: Avoiding recursive stack overflow in C on Unix/Linux? "Herbert Rosenau" <os2guy@pc-rosenau.de> - 2011-05-10 11:20 +0000
                    Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-08 17:59 +0200
                      Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-09 09:01 +0200
                Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:41 +0100
                  Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 12:48 -0700
                    Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 11:01 +0000
                    Re: Avoiding recursive stack overflow in C on Unix/Linux? gazelle@shell.xmission.com (Kenny McCormack) - 2011-05-08 13:10 +0000
                      Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:51 +0100
                        Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-08 22:21 +0000
                          Re: Avoiding recursive stack overflow in C on Unix/Linux? gazelle@shell.xmission.com (Kenny McCormack) - 2011-06-04 12:54 +0000
                            Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-06-04 12:59 -0700
                              Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-06-07 06:30 -0700
                                Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-06-10 21:56 -0700
                  Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 13:53 -0700
                    Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 15:16 -0700
                      Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-07 23:42 +0100
                        Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 19:37 -0700
                          Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 07:17 +0200
                            Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 09:24 +0200
                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-08 10:36 +0100
                            Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 13:29 +0300
                      Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-08 00:28 -0400
                        Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 23:06 -0700
                        Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-08 07:30 +0100
                          Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-08 15:51 +0000
                            Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 13:33 +0300
                              Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-14 11:08 -0400
                                Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-14 15:53 +0000
                          Re: Avoiding recursive stack overflow in C on Unix/Linux? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-10 22:14 +0100
                      Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 11:08 +0000
                    Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 08:15 +0100
      Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-11 03:43 -0700

Page 5 of 13 — ← Prev page 1 … 3 4 [5] 6 7 … 13  Next page →

#3640

On May 9, 10:44 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> Ian Collins <ian-n...@hotmail.com> writes:
> > On 05/10/11 12:36 AM, Rainer Weikusat wrote:
>
> >>        [*] The third one was that I had written an 'open source'
> >>        802.1x implementation in C++ which was turned into 0xdeadbeef
> >>        because it relied on a particular g++ feature (the ability to
> >>        define string contants in headers) which was later removed
> >>        because the people working on the compiler reportedly couldn't
> >>        agree on a way to implement it.
>
> > So you're one of those annoying buggers who writes "portable" code
> > that only compiles with gcc.
>
> By that time (2001), I simply wasn't aware that 'string constants'
> defined in C++ headers were 'something special' compared to numeric
> constants. In particlar, I didn't know that this required the compiler
> to allocate space for the string literal somewhere in the object code
> files it was supposed to generate. I simply took it for granted
> because the feature had always been there. Also, I wasn't exactly in
> the position to even contemplate to get access to a ANSI/ISO standards
> document, rather in the position where I was happy during the time of
> the month where I had the money to buy food without wandering all over
> the city in order to collect deposit bottles first. And the program
> even worked in Linux and NetBSD and compiled and ran (to the degree I
> could test it) on Solaris 8 (IIRC). That's not something I would spend
> any time on today: I use Linux, if you use something else, feel free
> to port it yourself :->.

I'm slightly drnk, and under the influence of some prime, dutch weed
(K2 for connaisseurs), so it's probably not the right time to make
comments on a public forum, but this, i feel, needs to be said...

I think i love you...

<sigh>

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

#3641

On May 9, 1:30 pm, boltar2...@boltar.world wrote:
> On Sun, 8 May 2011 07:23:46 -0700 (PDT)
> "Kleuskes & Moos" <kleu...@xs4all.nl> wrote:
>
> >> In a place where you can catch the error and terminate cleanly.
>
> >> One of the major problems with C is that you cannot reliably handle
> >> stack overflows, unless you roll your own stack.
>
> >Exactly. And since implementing a stack mechanism with all the
> >goodities and niceties a demanding programmer wants, is in the range
> >of Computer Science 101, it's rather superfluous as a language
> >element.
>
> Best not to mention that to the STL fanboys on comp.lang.c++ ;)

STL is a library, not a language element. A superbly useful library at
that. That's exactly where stuff like lists, queues, stack and what
have SHOULD be implemented. After all, it's no use inventing the wheel
all over again every time you need one.

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

#3644

In article 
<cdc2bce7-4168-4bad-92b7-fdaa78e556e9@b19g2000yqg.googlegroups.com>,
 "Kleuskes & Moos" <kleuske@xs4all.nl> wrote:

> On May 9, 1:30 pm, boltar2...@boltar.world wrote:
> > On Sun, 8 May 2011 07:23:46 -0700 (PDT)
> > "Kleuskes & Moos" <kleu...@xs4all.nl> wrote:
> >
> > >> In a place where you can catch the error and terminate cleanly.
> >
> > >> One of the major problems with C is that you cannot reliably handle
> > >> stack overflows, unless you roll your own stack.
> >
> > >Exactly. And since implementing a stack mechanism with all the
> > >goodities and niceties a demanding programmer wants, is in the range
> > >of Computer Science 101, it's rather superfluous as a language
> > >element.
> >
> > Best not to mention that to the STL fanboys on comp.lang.c++ ;)
> 
> STL is a library, not a language element. A superbly useful library at
> that. That's exactly where stuff like lists, queues, stack and what
> have SHOULD be implemented. After all, it's no use inventing the wheel
> all over again every time you need one.

There are good reasons to write it oneself. When I want
a binary search I simply write it on the fly; and embed
whatever I want to do with the search result right there.

It takes as long or longer to write the interfaces to a
library binary search as it does to write one that does
exactly what I want.

-- 
Michael Press

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

#3646

On 05/10/11 10:05 AM, Michael Press wrote:
> Moos"<kleuske@xs4all.nl>  wrote:
>>
>> STL is a library, not a language element. A superbly useful library at
>> that. That's exactly where stuff like lists, queues, stack and what
>> have SHOULD be implemented. After all, it's no use inventing the wheel
>> all over again every time you need one.
>
> There are good reasons to write it oneself. When I want
> a binary search I simply write it on the fly; and embed
> whatever I want to do with the search result right there.

I wish I had the time to rewrite (including the required test cases) 
standard algorithms each time I needed one.

> It takes as long or longer to write the interfaces to a
> library binary search as it does to write one that does
> exactly what I want.

What could be simpler than

std::binary_search( start, end, value );

-- 
Ian Collins

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

#3958

Ian Collins <ian-news@hotmail.com> writes:

> On 05/10/11 10:05 AM, Michael Press wrote:
> > Moos"<kleuske@xs4all.nl>  wrote:
> >>
> >> STL is a library, not a language element. A superbly useful library at
> >> that. That's exactly where stuff like lists, queues, stack and what
> >> have SHOULD be implemented. After all, it's no use inventing the wheel
> >> all over again every time you need one.
> >
> > There are good reasons to write it oneself. When I want
> > a binary search I simply write it on the fly; and embed
> > whatever I want to do with the search result right there.
> 
> I wish I had the time to rewrite (including the required test cases)
> standard algorithms each time I needed one.
> 
> > It takes as long or longer to write the interfaces to a
> > library binary search as it does to write one that does
> > exactly what I want.
> 
> What could be simpler than
> 
> std::binary_search( start, end, value );

I thought using iterators was in fashion a decade ago, but getting rather
stale now.

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]

#3964

On May 14, 7:04 pm, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
wrote:
>
> I thought using iterators was in fashion a decade ago, but getting rather
> stale now.
>
I stopped using C++ about then.
But the controlled sequence or iterator system does work, it's just
very hard to train programmers to use it correctly.

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

#3647

On May 9, 3:05 pm, Michael Press <rub...@pacbell.net> wrote:
> There are good reasons to write it oneself. When I want
> a binary search I simply write it on the fly; and embed
> whatever I want to do with the search result right there.
>
> It takes as long or longer to write the interfaces to a
> library binary search as it does to write one that does
> exactly what I want.

I politely disagree, and I must express my extreme disbelief at this
statement that you can write a good correct binary search algorithm
faster than you can use C++ std::map, or C++ std::lower_bound, et al.

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

#3648

Joshua Maurice <joshuamaurice@gmail.com> writes:

> On May 9, 3:05 pm, Michael Press <rub...@pacbell.net> wrote:
>> There are good reasons to write it oneself. When I want
>> a binary search I simply write it on the fly; and embed
>> whatever I want to do with the search result right there.
>>
>> It takes as long or longer to write the interfaces to a
>> library binary search as it does to write one that does
>> exactly what I want.
>
> I politely disagree, and I must express my extreme disbelief at this
> statement that you can write a good correct binary search algorithm
> faster than you can use C++ std::map, or C++ std::lower_bound, et al.

A binary search is roughly 10 lines of code.  Writing one really doesn't
take long.

-- 
Måns Rullgård
mans@mansr.com

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

#3650

On 05/10/11 10:44 AM, Måns Rullgård wrote:
> Joshua Maurice<joshuamaurice@gmail.com>  writes:
>
>> On May 9, 3:05 pm, Michael Press<rub...@pacbell.net>  wrote:
>>> There are good reasons to write it oneself. When I want
>>> a binary search I simply write it on the fly; and embed
>>> whatever I want to do with the search result right there.
>>>
>>> It takes as long or longer to write the interfaces to a
>>> library binary search as it does to write one that does
>>> exactly what I want.
>>
>> I politely disagree, and I must express my extreme disbelief at this
>> statement that you can write a good correct binary search algorithm
>> faster than you can use C++ std::map, or C++ std::lower_bound, et al.
>
> A binary search is roughly 10 lines of code.  Writing one really doesn't
> take long.

Just ten times longer than calling one!

Then there's the however many lines of unit test cases.

-- 
Ian Collins

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

#3651

Ian Collins <ian-news@hotmail.com> writes:

> On 05/10/11 10:44 AM, Måns Rullgård wrote:
>> Joshua Maurice<joshuamaurice@gmail.com>  writes:
>>
>>> On May 9, 3:05 pm, Michael Press<rub...@pacbell.net>  wrote:
>>>> There are good reasons to write it oneself. When I want
>>>> a binary search I simply write it on the fly; and embed
>>>> whatever I want to do with the search result right there.
>>>>
>>>> It takes as long or longer to write the interfaces to a
>>>> library binary search as it does to write one that does
>>>> exactly what I want.
>>>
>>> I politely disagree, and I must express my extreme disbelief at this
>>> statement that you can write a good correct binary search algorithm
>>> faster than you can use C++ std::map, or C++ std::lower_bound, et al.
>>
>> A binary search is roughly 10 lines of code.  Writing one really doesn't
>> take long.
>
> Just ten times longer than calling one!

You're conveniently glossing over the number of lines required to adapt
to some particular library interface.  Also, using a library function
usually involves callbacks for comparing elements, which adds runtime
overhead.

> Then there's the however many lines of unit test cases.

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.

-- 
Måns Rullgård
mans@mansr.com

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

#3652

On 05/10/11 11:11 AM, Måns Rullgård wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>
>> On 05/10/11 10:44 AM, Måns Rullgård wrote:
>>> Joshua Maurice<joshuamaurice@gmail.com>   writes:
>>>
>>>> On May 9, 3:05 pm, Michael Press<rub...@pacbell.net>   wrote:
>>>>> There are good reasons to write it oneself. When I want
>>>>> a binary search I simply write it on the fly; and embed
>>>>> whatever I want to do with the search result right there.
>>>>>
>>>>> It takes as long or longer to write the interfaces to a
>>>>> library binary search as it does to write one that does
>>>>> exactly what I want.
>>>>
>>>> I politely disagree, and I must express my extreme disbelief at this
>>>> statement that you can write a good correct binary search algorithm
>>>> faster than you can use C++ std::map, or C++ std::lower_bound, et al.
>>>
>>> A binary search is roughly 10 lines of code.  Writing one really doesn't
>>> take long.
>>
>> Just ten times longer than calling one!
>
> You're conveniently glossing over the number of lines required to adapt
> to some particular library interface.  Also, using a library function
> usually involves callbacks for comparing elements, which adds runtime
> overhead.

As I posted else-thread, the C++ binary_search interface is as simple as 
it gets and the code happily expands in-line.  So there isn't any 
adapting or overhead.

>> Then there's the however many lines of unit test cases.
>
> 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.

Well I only write code to pass tests, so I guess I'm one.

-- 
Ian Collins

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

#3661

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.

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.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

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

#3690

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]

#3694

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]

#3746

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]

#3747

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]

#3801

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]

#3704

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]

#3709

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]

#3712

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]

Page 5 of 13 — ← Prev page 1 … 3 4 [5] 6 7 … 13  Next page →

Back to top | Article view | comp.lang.c

csiph-web