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

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

Unexpected and difficult to understand SIGSEGV

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

Contents

  Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 04:02 +0200
    Re: Unexpected and difficult to understand SIGSEGV "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-24 19:51 -0700
      Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:09 +0200
    Re: Unexpected and difficult to understand SIGSEGV John Gordon <gordon@panix.com> - 2015-09-25 04:32 +0000
      Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:09 +0200
      Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-25 22:07 +0000
        Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-25 18:46 -0400
          Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-26 10:57 +1200
          Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-25 21:40 -0700
            Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-26 16:51 +1200
              Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-26 10:45 +0100
                Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-26 03:39 -0700
                  Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-26 12:20 +0100
                    Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-26 06:39 -0700
              Re: Unexpected and difficult to understand SIGSEGV fir <profesor.fir@gmail.com> - 2015-09-27 01:45 -0700
        Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-26 23:11 +0200
    Re: Unexpected and difficult to understand SIGSEGV jacobnavia <jacob@jacob.remcomp.fr> - 2015-09-25 10:28 +0200
      Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-25 10:33 +0000
        Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:05 +0200
          Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-25 16:44 +0000
      Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:08 +0200
    Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-25 10:55 +0100
      Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:00 +0200
        Re: Unexpected and difficult to understand SIGSEGV luser droog <luser.droog@gmail.com> - 2015-09-25 09:40 -0700
          Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-25 20:25 +0100
            Re: Unexpected and difficult to understand SIGSEGV <william@wilbur.25thandClement.com> - 2015-09-25 19:07 -0700
              Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-26 10:47 +0100
              Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-26 10:34 -0400
              Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-26 15:28 +0000
                Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 17:32 -0700
                  Re: Unexpected and difficult to understand SIGSEGV Noob <root@127.0.0.1> - 2015-09-27 09:59 +0200
                    Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-30 02:52 -0700
                      Re: Unexpected and difficult to understand SIGSEGV Noob <root@127.0.0.1> - 2015-09-30 20:13 +0200
                        Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 16:00 -0700
                  Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-28 08:17 +0000
                    Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-30 04:00 -0700
                      Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-01 09:34 +1300
                        Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-01 19:05 +0000
                          Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-02 08:25 +1300
                        Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 16:02 -0700
                          Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 12:57 +1300
                            Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-06 09:23 -0700
                              Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-07 11:18 +1300
                                Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-09 13:52 -0700
                  Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 09:51 +0200
                    Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-29 11:07 +0000
                      Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 15:09 +0200
                        Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-30 07:34 +0000
                          Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-30 10:33 +0200
                            Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-30 11:14 +0100
                              Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-30 12:26 +0200
                                Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-30 11:58 +0100
                            Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-01 19:16 +0000
                        Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 16:21 +0200
                          Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-01 19:27 +0000
                    Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 07:58 -0700
                      Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-01 21:52 +0200
                        Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 16:10 -0700
                Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-27 11:15 +0100
                  Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-28 08:47 +0000
    Re: Unexpected and difficult to understand SIGSEGV Andrew Cooper <amc96@cam.ac.uk> - 2015-09-26 00:02 +0100
      Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 00:02 +0200
    Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-26 23:32 -0700
      Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 22:10 +0200
        Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 17:01 -0400
          Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-27 22:15 +0100
            Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 23:36 +0200
          Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 23:33 +0200
            Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 10:40 +1300
              Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 23:58 +0200
                Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 11:08 +1300
                  Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 00:25 +0200
                    Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 12:50 +1300
                      Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:06 +0200
                        Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:15 +1300
                          Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:20 +0200
                            Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:24 +1300
                              Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:44 +0200
                                Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:50 +1300
                      Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-09-27 23:44 -0700
                        Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 20:17 +1300
                          Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-28 01:06 -0700
                            Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-28 16:59 +0200
                              Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-28 09:23 -0700
                                Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-29 07:47 +1300
                      Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-28 13:46 +0200
                        Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-29 07:52 +1300
                          Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 10:15 +0200
                  Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-02 09:55 +0000
                    Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-02 11:59 -0400
                      Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-10-03 11:51 -0700
                        Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-03 15:25 -0400
                    Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:50 -0700
                Re: Unexpected and difficult to understand SIGSEGV Richard Damon <Richard@Damon-Family.org> - 2015-09-27 18:32 -0400
                  Re: Unexpected and difficult to understand SIGSEGV asetofsymbols@gmail.com - 2015-09-27 17:37 -0700
                    Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-27 17:50 -0700
                      Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-28 18:18 +0000
                        Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-28 11:31 -0700
                          Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-29 07:37 +0000
                  Re: Unexpected and difficult to understand SIGSEGV asetofsymbols@gmail.com - 2015-09-27 17:38 -0700
                  Re: Unexpected and difficult to understand SIGSEGV asetofsymbols@gmail.com - 2015-09-27 17:39 -0700
                    Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:42 +1300
                      Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:46 +0200
                      Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-02 09:56 +0000
            Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 18:20 -0400
              Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-27 15:54 -0700
            Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-27 18:23 -0400
              Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 00:33 +0200
                Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 11:42 +1300
                  Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 01:04 +0200
                    Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 12:32 +1300
                      Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 01:37 +0200
                    Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-27 16:53 -0700
                Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-28 00:21 +0100
                  Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 01:30 +0200
                    Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-28 00:41 +0100
                      Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 01:52 +0200
                        Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 12:59 +1300
                      Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-28 17:07 +0200
                        Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-30 11:17 +0000
                          Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-09-30 06:08 -0700
                    Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-27 17:09 -0700
                      Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:17 +0200
                        Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-28 09:00 -0700
                          Re: Unexpected and difficult to understand SIGSEGV ais523 <ais523@nethack4.org> - 2015-10-01 14:05 +0000
                            Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-01 16:23 +0200
                            Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-01 10:26 -0400
                              Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-01 16:53 +0200
                                Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-01 11:26 -0400
                                  Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-01 21:57 +0200
                                    Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-01 13:30 -0700
                                      Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-01 13:57 -0700
                                      Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-01 17:19 -0400
                                        Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-01 15:38 -0700
                                          Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-01 17:14 -0700
                                            Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:19 -0700
                                              Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 15:01 -0700
                                                Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-04 18:26 -0400
                                                  Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 17:53 -0700
                                                Re: Unexpected and difficult to understand SIGSEGV Richard Damon <Richard@Damon-Family.org> - 2015-10-04 18:37 -0400
                                                  Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-04 19:13 -0400
                                                  Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 17:57 -0700
                                                    Re: Unexpected and difficult to understand SIGSEGV Richard Damon <Richard@Damon-Family.org> - 2015-10-04 21:57 -0400
                                                Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-05 01:53 -0700
                                                  Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-05 09:37 -0700
                                                    Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-09 14:10 -0700
                                                      Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-09 14:35 -0700
                                                        Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-10 11:43 +1300
                                                        Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-12 09:17 -0700
                                                          Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-12 12:32 -0700
                                                          Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-12 14:12 -0700
                                                            Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-12 14:52 -0700
                                                              Re: Unexpected and difficult to understand SIGSEGV glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-13 03:00 +0000
                                                                Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-12 23:34 -0700
                                                              Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-14 11:00 +0000
                                                                Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-14 08:34 -0700
                                                                  Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-14 11:34 -0700
                                                                    Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-14 11:57 -0700
                                                                    Re: Unexpected and difficult to understand SIGSEGV glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-15 00:03 +0000
                                                                      Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-15 10:57 -0700
                                                                  Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-20 16:06 +0000
                                                            Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-17 07:32 -0700
                                                              Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-17 07:51 -0700
                                                              Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-17 15:51 -0700
                                          Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-02 10:09 +0000
                                          Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-02 08:55 -0400
                                            Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-02 08:59 -0700
                                              Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 17:35 -0700
                                                Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 10:02 -0700
                                                  Re: Unexpected and difficult to understand SIGSEGV Robert Wessel <robertwessel2@yahoo.com> - 2015-10-03 16:11 -0500
                                                    Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-03 17:27 -0400
                                                      Re: Unexpected and difficult to understand SIGSEGV Robert Wessel <robertwessel2@yahoo.com> - 2015-10-03 16:58 -0500
                                                        Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 15:16 -0700
                                                        Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-03 18:21 -0400
                                                        Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-03 18:23 -0400
                                                          Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-03 18:52 -0400
                                                            Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 16:16 -0700
                                                              Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-03 19:13 -0700
                                                                Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 23:34 -0700
                                                                  Re: Unexpected and difficult to understand SIGSEGV glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-04 07:09 +0000
                                                                  Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 14:43 -0700
                                                          Re: Unexpected and difficult to understand SIGSEGV Robert Wessel <robertwessel2@yahoo.com> - 2015-10-04 03:19 -0500
                                                Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:48 -0700
                                                  Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 16:26 -0700
                                            Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 13:21 -0700
                                              Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-02 17:05 -0400
                                                Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-02 15:11 -0700
                                                  Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 20:55 -0700
                                                    Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 12:00 -0700
                                                      Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-03 16:52 -0700
                                            Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:40 -0700
                                    Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-01 22:02 -0400
                                      Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 10:09 +0100
                                        Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 08:19 -0700
                                      Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-02 03:17 -0700
                                      Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-02 13:02 +0200
                                  Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-10-01 18:33 -0700
                            Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-01 11:17 -0400
                            Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-01 17:06 +0100
                              Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-01 11:45 -0700
                              Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-02 10:21 +0000
                                Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 11:36 +0100
                                  Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-02 11:44 +0100
                                    Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 13:24 +0100
                                      Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-02 15:31 +0100
                                        Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 18:04 +0100
                                          Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-02 18:21 +0100
                                            Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 21:04 +0100
                                              Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-03 08:29 +0200
                                              Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-03 16:47 +0200
                                                Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-03 17:37 +0100
                                                  Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-03 17:54 +0100
                                                  Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-04 18:16 +0200
                                                    Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 18:13 +0100
                                                      Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-04 18:22 +0100
                                                        Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 20:17 +0100
                                                          Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-04 21:07 +0100
                                                            Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 22:10 +0100
                                                          Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 09:24 +1300
                                                            Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 22:15 +0100
                                                              Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 10:38 +1300
                                                                Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 23:02 +0100
                                                                  Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 11:10 +1300
                                                                    Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 23:51 +0100
                                                                      Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 11:56 +1300
                                                      Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 07:38 +1300
                                                      Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-04 23:51 +0200
                                                        Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 23:44 +0100
                                                          Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 11:52 +1300
                                                            Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-05 00:09 +0100
                                                              Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 13:00 +1300
                                                                Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-10-04 17:14 -0700
                                                              Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-10-05 09:40 -0700
                                                                Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-05 18:32 +0100
                                                                  Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-10-05 21:59 -0700
                                                          Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-05 01:13 -0700
                                                      Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-06 17:14 +0000
                                    Re: Unexpected and difficult to understand SIGSEGV Gareth Owen <gwowen@gmail.com> - 2015-10-02 14:56 +0100
                                      Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-02 16:31 +0100
                                        Re: Unexpected and difficult to understand SIGSEGV Gareth Owen <gwowen@gmail.com> - 2015-10-02 20:11 +0100
                                      Re: Unexpected and difficult to understand SIGSEGV jadill33@gmail.com - 2015-10-02 09:18 -0700
                                        Re: Unexpected and difficult to understand SIGSEGV Gareth Owen <gwowen@gmail.com> - 2015-10-02 20:14 +0100
                                Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 10:20 -0700
                                  Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-04 14:03 +0000
                            Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-01 09:28 -0700
                            Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-10-01 18:53 +0200
                              Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-10-02 06:26 +0200
                            Generating header files  (Was: Unexpected and difficult to understand SIGSEGV) Roberto Waltman <usenet@rwaltman.com> - 2015-10-01 13:40 -0400
                              Re: Generating header files (Was: Unexpected and difficult to understand SIGSEGV) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-01 23:58 +0200
                            Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:06 -0700
                Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 21:05 -0400
                  Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 10:26 +0200
                Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 21:15 -0400
                Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-28 09:52 -0400
                  Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-28 10:36 -0400
                    Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-28 10:40 -0400
                      Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-28 15:55 +0100
                        Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-29 01:16 +0200
                          Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-29 00:26 +0100
                          Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 10:34 +0200
                            Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-29 15:50 +0100
                              Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-29 11:16 -0400
                                Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-29 16:22 +0100
                                  Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-29 13:15 -0400
                                    Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-29 18:56 +0100
                          Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-29 07:04 -0400
                            Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 00:07 +0200
                              Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-29 18:13 -0700
                                Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-09-29 21:57 -0700
                              Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-30 01:57 -0400
                              Re: Unexpected and difficult to understand SIGSEGV jadill33@gmail.com - 2015-09-30 06:01 -0700
                                Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 16:11 +0200
                              Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-30 14:12 +0100
                                Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 16:15 +0200
                              Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-30 08:40 -0700
                    Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-09-30 22:28 +0200
                      Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-09-30 22:31 +0200
                      Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-30 16:53 -0400
                        Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-09-30 23:19 +0200
                          Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-09-30 23:32 +0200
                          Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-30 18:17 -0400
                        Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-01 03:19 +0200
                          Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-30 22:01 -0400
                            Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-02 00:46 +0200
        Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 17:44 -0700
          Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:51 +1300
            Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 18:04 -0700
              Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 03:39 +0200
                Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 22:03 -0400
                  Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 04:16 +0200
                    Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 15:19 +1300
                      Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 04:23 +0200
                        Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 14:11 +0200
                          Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 00:15 +0200
                            Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-29 18:14 -0700
                              Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-02 00:41 +0200
                    Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-27 19:58 -0700
                    Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 10:43 +0200
                      Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 00:16 +0200
                        Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-29 15:51 -0700
                          Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 16:37 +0200
                            Strings (was Re: Unexpected and difficult to understand SIGSEGV) supercat@casperkitty.com - 2015-09-30 09:12 -0700
                              Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-09-30 17:34 +0100
                                Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) supercat@casperkitty.com - 2015-09-30 11:29 -0700
                                  Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-09-30 20:00 +0100
                                    Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) supercat@casperkitty.com - 2015-09-30 12:49 -0700
                                      Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-09-30 22:26 +0100
                                        Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) supercat@casperkitty.com - 2015-09-30 16:27 -0700
                                          Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-10-01 09:56 +0100
                                    Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-01 03:08 +0200
                                Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-30 13:10 -0700
                                  Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Ian Collins <ian-news@hotmail.com> - 2015-10-01 09:23 +1300
                                    Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-30 19:02 -0700
                                      Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Richard Heathfield <rjh@cpax.org.uk> - 2015-10-01 03:12 +0100
                                        Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-10-01 11:15 +0100
                                          Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Richard Heathfield <rjh@cpax.org.uk> - 2015-10-01 11:36 +0100
                                            Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-01 05:49 -0700
                                              Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) David Brown <david.brown@hesbynett.no> - 2015-10-01 16:41 +0200
                                      Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Ian Collins <ian-news@hotmail.com> - 2015-10-01 15:16 +1300
                                    Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-30 19:10 -0700
                                      Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Ian Collins <ian-news@hotmail.com> - 2015-10-01 15:20 +1300
                                      Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Philip Lantz <prl@canterey.us> - 2015-10-01 01:26 -0700
                                        Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-01 02:16 -0700
                                          Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Martin Shobe <martin.shobe@yahoo.com> - 2015-10-01 08:34 -0500
                Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 19:06 -0700
                  Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 04:18 +0200
                    Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 21:32 -0700
    Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 07:54 -0700
      Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 17:16 +0200
        Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-27 11:21 -0400
          Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 08:59 -0700
            Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-02 00:16 +0200

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

#71329

"Lazy says it is better to create the header, as then you need to spend 
less effort verifying that things are in sync. It may be fractionally 
more work to create the header, but that effort is paid back quickly."

Lazy would create not 2 .c files but just one

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

#71330

asetofsymbols@gmail.com wrote:
> "Lazy says it is better to create the header, as then you need to spend
> less effort verifying that things are in sync. It may be fractionally
> more work to create the header, but that effort is paid back quickly."
>
> Lazy would create not 2 .c files but just one

Lazy would be to quote correctly and only post once!

-- 
Ian Collins

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

#71333

On 28.09.2015 02:42, Ian Collins wrote:
> asetofsymbols@gmail.com wrote:
>> "Lazy says it is better to create the header, as then you need to spend
>> less effort verifying that things are in sync. It may be fractionally
>> more work to create the header, but that effort is paid back quickly."
>>
>> Lazy would create not 2 .c files but just one
>
> Lazy would be to quote correctly and only post once!

LOL.

Lazy doesn't necessarily mean disorganized or messy.

-Morten

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

#71589

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

> asetofsymbols@gmail.com wrote:
> > "Lazy says it is better to create the header, as then you need to spend
> > less effort verifying that things are in sync. It may be fractionally
> > more work to create the header, but that effort is paid back quickly."
> >
> > Lazy would create not 2 .c files but just one
> 
> Lazy would be to quote correctly and only post once!

Sub-optimally lazy is to use Goggle Broken Gropes wherever you are, and
never mind the webforumy ugliness.
Optimally lazy is to install a decent newsreader _once_ and set up
everything exactly as you like it. Use the right one and you can even
install it on a USB stick and take it everywhere.

Richard

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

#71303

On 09/27/2015 05:33 PM, Morten W. Petersen wrote:
> On 27.09.2015 23:01, James Kuyper wrote:
>> On 09/27/2015 04:10 PM, Morten W. Petersen wrote:
> [...]
>>> I think I was just lazy when I got started with this, and though that
>>> a prototype file wasn't necessary at that point, and that the design
>>> wasn't finished so it would be double-duty work to change a function
>>> name/signature several places.
>>
>> That comment doesn't make a lot of sense. NOT using a single header is
>> what requires you make updates in multiple places. Using a header allows
>> you to make changes in only two places: the header itself, and the
>> translation unit where the object or function is identified. Laziness
>> should be impelling you to use headers, not to avoid them.
> 
> Well, take the Smash XML project.. in the Makefile it says
> 
> gcc -std=c90 decode_xml.c tests.c -g -o decode_xml -I.
> 
> And functions defined in decode_xml.c are called in tests.c,
> and the resulting executable decode_xml does the right thing.

Because you're making the mistake of insisting on using C90, you've
enabled the "implicit int" rule that caused so much trouble that it was
removed in C99. As a result, if you use a function in test.c without
first declaring it, the compiler acts as though a implicit declaration
was provided that takes the specified number of arguments, and returns
an int value. If the parameters of your functions have types compatible
with the promoted types of the corresponding arguments, and the return
value is in fact 'int' - or if the return value isn't used, then the
behavior of your code is well defined. Even if the return value isn't
'int', if it's the same size as 'int', on many platforms your code will
still appear to work - which is bad for you, because you've missed an
opportunity to detect a code defect.

That's would be a stupid thing to rely upon. You should have prototype
declarations in scope in test.c where you use the functions - the
prototypes will enable very useful warning messages if the functions are
used in ways incompatible with the prototype, and will cause arguments
to be converted to the declared type of each parameter, not merely
promoted. Some people prefer to not bother with such protection, just as
some people prefer not to wear motorcycle helmets while traveling with
no other head protection at 100km/hr - I think equally highly of thought
processes of people in both groups.

> Are you saying I should add a header file for functions defined
> in decode_xml.c at this point, to save myself from extra work?

If you already created the necessary function prototypes in test.c, it's
a very minor amount of additional work to move those declarations into a
header file, and add #include statements for that header file into both
decode_xml.c (to make sure the header is compatible with the the
declarations) and in test.c.

If you didn't put in those prototypes, then you've created a lot of
potential pain for yourself, by turning off the diagnostic messages
enabled by the use of function prototypes

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

#71310

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> Because you're making the mistake of insisting on using C90, you've
> enabled the "implicit int" rule that caused so much trouble that it was
> removed in C99. As a result, if you use a function in test.c without
> first declaring it, the compiler acts as though a implicit declaration
> was provided that takes the specified number of arguments, and returns
> an int value. If the parameters of your functions have types compatible
> with the promoted types of the corresponding arguments, and the return
> value is in fact 'int' - or if the return value isn't used, then the
> behavior of your code is well defined. Even if the return value isn't
> 'int', if it's the same size as 'int', on many platforms your code will
> still appear to work - which is bad for you, because you've missed an
> opportunity to detect a code defect.
[...]

If the return type isn't int, you'll have undefined behavior even if the
result isn't used.

For example:

    double func(void) { return 0.0) }

    /*
    * In another source file where no declaration of func() is visible:
    */
    func();

In C90, the call is not a constraint violation, but the behavior is
undefined, because the type of the function is not compatible with the
type of the prefix expression.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#71304

On 9/27/2015 5:33 PM, Morten W. Petersen wrote:
> On 27.09.2015 23:01, James Kuyper wrote:
>>
>> [...]Using a header allows
>> you to make changes in only two places: the header itself, and the
>> translation unit where the object or function is identified. Laziness
>> should be impelling you to use headers, not to avoid them.
>
> Well, take the Smash XML project.. in the Makefile it says
>
> gcc -std=c90 decode_xml.c tests.c -g -o decode_xml -I.

     Fine -- but this alone won't ensure that the definitions in
decode_xml.c are compatible with the declarations in tests.c.
The fact that two C sources are compiled by the same invocation
of the compiler does *not* make them a single "translation unit"
within which the (possibly conflicting) lines are visible to the
compiler simultaneously.  Notionally, the two C sources are compiled
independently and then their compiled outputs are combined into a
single executable.

> And functions defined in decode_xml.c are called in tests.c,
> and the resulting executable decode_xml does the right thing.

     "It happened to do the right thing" is a far cry from "It's
right" or "It's damage-resistant."

> Are you saying I should add a header file for functions defined
> in decode_xml.c at this point, to save myself from extra work?

     I believe that's what he's saying.  It's what I'd say, too.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#71308

On 28.09.2015 00:23, Eric Sosman wrote:
> On 9/27/2015 5:33 PM, Morten W. Petersen wrote:
>> On 27.09.2015 23:01, James Kuyper wrote:
>>>
>>> [...]Using a header allows
>>> you to make changes in only two places: the header itself, and the
>>> translation unit where the object or function is identified. Laziness
>>> should be impelling you to use headers, not to avoid them.
[...]
>> And functions defined in decode_xml.c are called in tests.c,
>> and the resulting executable decode_xml does the right thing.
>
>      "It happened to do the right thing" is a far cry from "It's
> right" or "It's damage-resistant."
>
>> Are you saying I should add a header file for functions defined
>> in decode_xml.c at this point, to save myself from extra work?
>
>      I believe that's what he's saying.  It's what I'd say, too.

OK.  Since there are error checking benefits that otherwise don't
come into play, I agree, function prototypes should be used.

I was thinking along the lines of keeping things simple so that
I wouldn't have to update the same thing in different places which
could create something to trip in if one forgot the other place(s).

This header file, could I define the function prototypes there,
and then simply make use of those prototypes later, doing something
like

__inline__ my_function_prototype { return a+b; }

?

I was thinking the header file could basically be the API description
and the only place the function signature was located..

-Morten

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

#71309

Morten W. Petersen wrote:
> On 28.09.2015 00:23, Eric Sosman wrote:
>> On 9/27/2015 5:33 PM, Morten W. Petersen wrote:
>>> On 27.09.2015 23:01, James Kuyper wrote:
>>>>
>>>> [...]Using a header allows
>>>> you to make changes in only two places: the header itself, and the
>>>> translation unit where the object or function is identified. Laziness
>>>> should be impelling you to use headers, not to avoid them.
> [...]
>>> And functions defined in decode_xml.c are called in tests.c,
>>> and the resulting executable decode_xml does the right thing.
>>
>>       "It happened to do the right thing" is a far cry from "It's
>> right" or "It's damage-resistant."
>>
>>> Are you saying I should add a header file for functions defined
>>> in decode_xml.c at this point, to save myself from extra work?
>>
>>       I believe that's what he's saying.  It's what I'd say, too.
>
> OK.  Since there are error checking benefits that otherwise don't
> come into play, I agree, function prototypes should be used.
>
> I was thinking along the lines of keeping things simple so that
> I wouldn't have to update the same thing in different places which
> could create something to trip in if one forgot the other place(s).

That's a job for your IDE!

> This header file, could I define the function prototypes there,
> and then simply make use of those prototypes later, doing something
> like
>
> __inline__ my_function_prototype { return a+b; }
>
> ?

Why muck about?  Just add normal function prototypes.

> I was thinking the header file could basically be the API description
> and the only place the function signature was located..

The public header often is the API description.  If you want a more 
verbose description, use Doxygen.  The user should be able to learn all 
they need to know from it.

-- 
Ian Collins

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

#71311

On 28.09.2015 00:42, Ian Collins wrote:
> Morten W. Petersen wrote:
[...]
>> OK.  Since there are error checking benefits that otherwise don't
>> come into play, I agree, function prototypes should be used.
>>
>> I was thinking along the lines of keeping things simple so that
>> I wouldn't have to update the same thing in different places which
>> could create something to trip in if one forgot the other place(s).
>
> That's a job for your IDE!

OK.  I don't want to add something else to the mix now, so I'm keeping
things simple with an editor and "hands-on" editing.

>> This header file, could I define the function prototypes there,
>> and then simply make use of those prototypes later, doing something
>> like
>>
>> __inline__ my_function_prototype { return a+b; }
>>
>> ?
>
> Why muck about?  Just add normal function prototypes.

Well I was looking for a simple-to-maintain way to do it.

I could #define the prototype first, then use that for
the prototype definition and the function definition, no?

-Morten

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

#71314

Morten W. Petersen wrote:
> On 28.09.2015 00:42, Ian Collins wrote:
>> Morten W. Petersen wrote:
> [...]
>>> OK.  Since there are error checking benefits that otherwise don't
>>> come into play, I agree, function prototypes should be used.
>>>
>>> I was thinking along the lines of keeping things simple so that
>>> I wouldn't have to update the same thing in different places which
>>> could create something to trip in if one forgot the other place(s).
>>
>> That's a job for your IDE!
>
> OK.  I don't want to add something else to the mix now, so I'm keeping
> things simple with an editor and "hands-on" editing.

There comes a time when a superficially "simple" process starts to 
become complex.

>>> This header file, could I define the function prototypes there,
>>> and then simply make use of those prototypes later, doing something
>>> like
>>>
>>> __inline__ my_function_prototype { return a+b; }
>>>
>>> ?
>>
>> Why muck about?  Just add normal function prototypes.
>
> Well I was looking for a simple-to-maintain way to do it.
>
> I could #define the prototype first, then use that for
> the prototype definition and the function definition, no?

Macros invariable complicate things.  The idiomatic way is the simple 
and easy to maintain way!

-- 
Ian Collins

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

#71315

On 28.09.2015 01:32, Ian Collins wrote:
> Morten W. Petersen wrote:
>> On 28.09.2015 00:42, Ian Collins wrote:
>>> Morten W. Petersen wrote:
>> [...]
>>>> OK.  Since there are error checking benefits that otherwise don't
>>>> come into play, I agree, function prototypes should be used.
>>>>
>>>> I was thinking along the lines of keeping things simple so that
>>>> I wouldn't have to update the same thing in different places which
>>>> could create something to trip in if one forgot the other place(s).
>>>
>>> That's a job for your IDE!
>>
>> OK.  I don't want to add something else to the mix now, so I'm keeping
>> things simple with an editor and "hands-on" editing.
>
> There comes a time when a superficially "simple" process starts to
> become complex.

Well, I have Cygwin+Emacs on Windows, Emacs on Linux, nano or something
similar on the Raspberry Pi (where editor size and speed matters) and
so on.

Yes if there are tools there that fit I'll use them, don't see it as
necessary now though.

-Morten

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

#71319

"Morten W. Petersen" <morphex@gmail.com> writes:
[...]
> I could #define the prototype first, then use that for
> the prototype definition and the function definition, no?

You could, but I wouldn't recommend it.

Just write the declaration (prototype) in the .h file, and the
definition in the corresponding .c file.  For example, say you have a
function named "func".

In foo.h:

    #ifndef FOO_H
    #define FOO_H

    void func(void);

    #endif /* FOO_H */

In foo.c:

    #include "foo.h"

    void func(void) {
        /* do some stuff */
    }

Yes, this means writing "void func(void)" twice, and yes, a macro would
mean writing it just once -- but it's not worth it.  Using a macro will
make your code more difficult to read.  Just copy-and-paste the
declaration and be done with it.  (The compiler will complain if the
declaration and definition of the function don't match.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#71312

On 27/09/2015 23:33, Morten W. Petersen wrote:

> I was thinking along the lines of keeping things simple so that
> I wouldn't have to update the same thing in different places which
> could create something to trip in if one forgot the other place(s).
>
> This header file, could I define the function prototypes there,
> and then simply make use of those prototypes later, doing something
> like
>
> __inline__ my_function_prototype { return a+b; }

What's 'my_function_prototype', is it a macro corresponding the the 
prototype? That would be an unwieldy way of doing things.


> ?
>
> I was thinking the header file could basically be the API description
> and the only place the function signature was located..

In general, C does require you to declare functions twice: once in a 
prototype, and again when they are defined. This applies even when 
functions aren't exported, and allows you to define functions in any 
order. (Otherwise you must define a function before its first use.)

Those declarations where the functions are exported (which don't have 
'static' in front to keep them local), could be collected together in a 
header, and that header can be be included in another module.

It would look like this:

int func(double, double);   // prototype, can be in header
....
int func(double x, double y) { ...   // definition

They do need to be kept in sync, but I think a compiler can be made to 
complain if they don't match.

(I did use a tool once which scanned function definitions and generated 
the requisite prototypes: one set for local definitions, another set for 
exported ones. These took the form of include files.)

-- 
Bartc

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

#71313

On 28.09.2015 01:21, Bartc wrote:
> On 27/09/2015 23:33, Morten W. Petersen wrote:
>
>> I was thinking along the lines of keeping things simple so that
>> I wouldn't have to update the same thing in different places which
>> could create something to trip in if one forgot the other place(s).
>>
>> This header file, could I define the function prototypes there,
>> and then simply make use of those prototypes later, doing something
>> like
>>
>> __inline__ my_function_prototype { return a+b; }
>
> What's 'my_function_prototype', is it a macro corresponding the the
> prototype? That would be an unwieldy way of doing things.

A bit awkward perhaps, but this works:

#include <stdio.h>

#define my_func_SIGNATURE int my_func(int a, int b)

my_func_SIGNATURE;

__inline__ my_func_SIGNATURE {
   return a+b;
}

int main() {
   int a = 1;
   int b = 2;
   printf("Result of a+b: %i\n", my_func(a,b));
}

-Morten

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

#71316

On 28/09/2015 00:30, Morten W. Petersen wrote:
> On 28.09.2015 01:21, Bartc wrote:
>> On 27/09/2015 23:33, Morten W. Petersen wrote:
>>
>>> I was thinking along the lines of keeping things simple so that
>>> I wouldn't have to update the same thing in different places which
>>> could create something to trip in if one forgot the other place(s).
>>>
>>> This header file, could I define the function prototypes there,
>>> and then simply make use of those prototypes later, doing something
>>> like
>>>
>>> __inline__ my_function_prototype { return a+b; }
>>
>> What's 'my_function_prototype', is it a macro corresponding the the
>> prototype? That would be an unwieldy way of doing things.
>
> A bit awkward perhaps, but this works:
>
> #include <stdio.h>
>
> #define my_func_SIGNATURE int my_func(int a, int b)
>
> my_func_SIGNATURE;
>
> __inline__ my_func_SIGNATURE {
>    return a+b;
> }

OK, you so have to declare the function name three times instead of two!

A couple of problems: you will be declaring the parameter names in the 
header; some might consider that 'private' information.

Also the parameter names will be separate from the definition, making it 
a little more awkward to glance at the parameter list to see what they 
are while trying to understand the code, or you need to edit the function.

(And don't forget that if an exported function prototype uses your own 
typedefs, they need to go in the header too.)

-- 
Bartc

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

#71318

On 28.09.2015 01:41, Bartc wrote:
> On 28/09/2015 00:30, Morten W. Petersen wrote:
>> On 28.09.2015 01:21, Bartc wrote:
[...]
>>> What's 'my_function_prototype', is it a macro corresponding the the
>>> prototype? That would be an unwieldy way of doing things.
>>
>> A bit awkward perhaps, but this works:
>>
>> #include <stdio.h>
>>
>> #define my_func_SIGNATURE int my_func(int a, int b)
>>
>> my_func_SIGNATURE;
>>
>> __inline__ my_func_SIGNATURE {
>>    return a+b;
>> }
>
> OK, you so have to declare the function name three times instead of two!

Well, maintainability trumps first-time creation time.

> A couple of problems: you will be declaring the parameter names in the
> header; some might consider that 'private' information.

What some might think?  Really? :)

> Also the parameter names will be separate from the definition, making it
> a little more awkward to glance at the parameter list to see what they
> are while trying to understand the code, or you need to edit the function.

Well the API is in the header file, and that's where users (probably
95%+ of all who come into contact with the source code) will look to
make use of the library.

-Morten

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

#71320

Morten W. Petersen wrote:
> On 28.09.2015 01:41, Bartc wrote:
>> On 28/09/2015 00:30, Morten W. Petersen wrote:
>>> On 28.09.2015 01:21, Bartc wrote:
> [...]
>>>> What's 'my_function_prototype', is it a macro corresponding the the
>>>> prototype? That would be an unwieldy way of doing things.
>>>
>>> A bit awkward perhaps, but this works:
>>>
>>> #include <stdio.h>
>>>
>>> #define my_func_SIGNATURE int my_func(int a, int b)
>>>
>>> my_func_SIGNATURE;
>>>
>>> __inline__ my_func_SIGNATURE {
>>>     return a+b;
>>> }
>>
>> OK, you so have to declare the function name three times instead of two!
>
> Well, maintainability trumps first-time creation time.
>
>> A couple of problems: you will be declaring the parameter names in the
>> header; some might consider that 'private' information.
>
> What some might think?  Really? :)

Yes, really!

>> Also the parameter names will be separate from the definition, making it
>> a little more awkward to glance at the parameter list to see what they
>> are while trying to understand the code, or you need to edit the function.
>
> Well the API is in the header file, and that's where users (probably
> 95%+ of all who come into contact with the source code) will look to
> make use of the library.

Your macros will probably confuse human readers and break automatic 
documentation tools.

-- 
Ian Collins

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

#71373

On 28/09/15 01:41, Bartc wrote:
> On 28/09/2015 00:30, Morten W. Petersen wrote:
>> On 28.09.2015 01:21, Bartc wrote:
>>> On 27/09/2015 23:33, Morten W. Petersen wrote:
>>>
>>>> I was thinking along the lines of keeping things simple so that
>>>> I wouldn't have to update the same thing in different places which
>>>> could create something to trip in if one forgot the other place(s).
>>>>
>>>> This header file, could I define the function prototypes there,
>>>> and then simply make use of those prototypes later, doing something
>>>> like
>>>>
>>>> __inline__ my_function_prototype { return a+b; }
>>>
>>> What's 'my_function_prototype', is it a macro corresponding the the
>>> prototype? That would be an unwieldy way of doing things.
>>
>> A bit awkward perhaps, but this works:
>>
>> #include <stdio.h>
>>
>> #define my_func_SIGNATURE int my_func(int a, int b)
>>
>> my_func_SIGNATURE;
>>
>> __inline__ my_func_SIGNATURE {
>>    return a+b;
>> }
>
> OK, you so have to declare the function name three times instead of two!
>
> A couple of problems: you will be declaring the parameter names in the
> header; some might consider that 'private' information.

I would say that parameter names are part of the inherent documentation 
of the function - if you don't picked good names for the parameters, and 
included them in the prototype in the header (and kept them matching in 
the implementation), you give yourself more work in commenting, and lead 
to confusion.

Tell me, which is clearer for the publicly visible prototype in the header:

double areaOfTriangle(double base, double height);

or

double areaOfTriangle(double, double);

?

(Of course, you are right in your low opinion of using a macro for the 
function signature instead of writing it in the header and the 
implementation.)

>
> Also the parameter names will be separate from the definition, making it
> a little more awkward to glance at the parameter list to see what they
> are while trying to understand the code, or you need to edit the function.
>
> (And don't forget that if an exported function prototype uses your own
> typedefs, they need to go in the header too.)
>

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

#71476

On Mon, 2015-09-28, David Brown wrote:
> On 28/09/15 01:41, Bartc wrote:
...

>> A couple of problems: you will be declaring the parameter names in the
>> header; some might consider that 'private' information.
>
> I would say that parameter names are part of the inherent documentation 
> of the function - if you don't picked good names for the parameters, and 
> included them in the prototype in the header (and kept them matching in 
> the implementation), you give yourself more work in commenting, and lead 
> to confusion.

Just for the record: I agree, strongly.

Parameter names aren't checked by the compiler so they /can/ go out of
sync, but they still are too valuable as documentation to be omitted.

I rarely or never see people omitting them.

[snip example]

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

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

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

csiph-web