Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #71186 > unrolled thread
| Started by | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| First post | 2015-09-25 04:02 +0200 |
| Last post | 2015-10-02 00:16 +0200 |
| Articles | 20 on this page of 332 — 34 participants |
Back to article view | Back to comp.lang.c
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 5 of 17 — ← Prev page 1 … 3 4 [5] 6 7 … 17 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-09-28 20:17 +1300 |
| Message-ID | <d6s7t0Fqr3pU25@mid.individual.net> |
| In reply to | #71355 |
Philip Lantz wrote: > Ian Collins wrote: > >>> Hmm, yes. Well are there any testing frameworks that work across >>> all C compilers that support C90? >> >> The test framework is simply a user of the code, so it doesn't have to >> "support" old C. > > The implication of that statement is that when you build the library for > another platform (where there may be only a C90 compiler*), it isn't > necessary to build and run the tests on that platform. Is that really > what you believe? If not, how do you propose running tests written in a > language that isn't available for the target platform? > > * I assume that the desire to be portable to platforms where there is > only a C90 compiler is the reason for the library to be written in C90. > If not, then the tests don't need to be written in C90, but then neither > does the library, right? Can you name a hosted platform where an XML parser is relevant that does not have a gcc port? I specifically stated "hosted platform" because when developing for embedded targets, it isn't usual practice to run unit tests on the target. As I say else-thread, I write all of my unit tests in C++, whether the code is big system C++ or small embedded C. I do this to get better unit test frameworks and to support my mocking system. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-09-28 01:06 -0700 |
| Message-ID | <9c639916-1529-4413-b8ee-8d3d12e10fde@googlegroups.com> |
| In reply to | #71356 |
On Monday, September 28, 2015 at 8:18:13 AM UTC+1, Ian Collins wrote: > > Can you name a hosted platform where an XML parser is relevant that does > not have a gcc port? I specifically stated "hosted platform" because > when developing for embedded targets, it isn't usual practice to run > unit tests on the target. > You can't necessarily run the code under gcc. Whilst it's quite likely that if a unit test succeeds on one platform and fails on another that will be due to endianness of integer width issues, it could possibly be an issue specific to the compiler. I found such a bug in the Baby X resource compiler. In the shrink routine, there was bug whereby sometimes it was reading memory from the line below the image. Since the routine then averages out pixel values, this wasn't noticeable, and it only happened when the ratio between shrunk and original hit a certain value. So the tests on version 1 on MSVC 2013 passed. In version 1.1, the test failed, because I compiled under MSVC 2015, which has better segfault protection.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-28 16:59 +0200 |
| Message-ID | <mubkg7$ves$1@dont-email.me> |
| In reply to | #71358 |
On 28/09/15 10:06, Malcolm McLean wrote: > On Monday, September 28, 2015 at 8:18:13 AM UTC+1, Ian Collins wrote: >> >> Can you name a hosted platform where an XML parser is relevant that does >> not have a gcc port? I specifically stated "hosted platform" because >> when developing for embedded targets, it isn't usual practice to run >> unit tests on the target. >> > You can't necessarily run the code under gcc. > Whilst it's quite likely that if a unit test succeeds on one > platform and fails on another that will be due to endianness > of integer width issues, it could possibly be an issue specific > to the compiler. Unit testing does not replace /all/ testing - it is just aimed at making more automated and repeatable testing, to find issues earlier, and to minimise the risks of regression. I believe it is common to do your unit testing on whatever platform is most convenient for testing - but of course it does not replace testing of code that is platform specific. The particular issues you mention - endianness and integer widths - should be pretty much non-issues for proper development. When you use the standard fixed-width integer types, there should be no surprises regarding integer sizes no matter what the widths are on the target. And endian issues are easily controlled. Of course there can be bugs with particular compilers, and you can't see them without testing on the final compiler - as said above, unit tests don't cover everything. > I found such a bug in the Baby X resource compiler. In the shrink > routine, there was bug whereby sometimes it was reading memory > from the line below the image. Since the routine then averages > out pixel values, this wasn't noticeable, and it only happened > when the ratio between shrunk and original hit a certain value. > So the tests on version 1 on MSVC 2013 passed. In version 1.1, > the test failed, because I compiled under MSVC 2015, which has > better segfault protection. > That sounds like a good old-fashioned bug in your code - pointer bug, overrun, etc. Either write code correctly, or use tools to help you track find such bugs. Unit testing can be one such tool.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-09-28 09:23 -0700 |
| Message-ID | <904a3c57-ced4-44a1-b588-2f4efa2b28bd@googlegroups.com> |
| In reply to | #71372 |
On Monday, September 28, 2015 at 3:59:20 PM UTC+1, David Brown wrote: > On 28/09/15 10:06, Malcolm McLean wrote: > > > > I found such a bug in the Baby X resource compiler. In the shrink > > routine, there was bug whereby sometimes it was reading memory > > from the line below the image. Since the routine then averages > > out pixel values, this wasn't noticeable, and it only happened > > when the ratio between shrunk and original hit a certain value. > > So the tests on version 1 on MSVC 2013 passed. In version 1.1, > > the test failed, because I compiled under MSVC 2015, which has > > better segfault protection. > > > > That sounds like a good old-fashioned bug in your code - pointer bug, > overrun, etc. Either write code correctly, or use tools to help you > track find such bugs. Unit testing can be one such tool. > It should have been valground. But the Linux machine was in its box and the Apple Mac and Windows machines were hogging the desktop.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-09-29 07:47 +1300 |
| Message-ID | <d6tgamF7jicU2@mid.individual.net> |
| In reply to | #71377 |
Malcolm McLean wrote: > On Monday, September 28, 2015 at 3:59:20 PM UTC+1, David Brown wrote: >> On 28/09/15 10:06, Malcolm McLean wrote: >>> >>> I found such a bug in the Baby X resource compiler. In the shrink >>> routine, there was bug whereby sometimes it was reading memory >>> from the line below the image. Since the routine then averages >>> out pixel values, this wasn't noticeable, and it only happened >>> when the ratio between shrunk and original hit a certain value. >>> So the tests on version 1 on MSVC 2013 passed. In version 1.1, >>> the test failed, because I compiled under MSVC 2015, which has >>> better segfault protection. >>> >> >> That sounds like a good old-fashioned bug in your code - pointer bug, >> overrun, etc. Either write code correctly, or use tools to help you >> track find such bugs. Unit testing can be one such tool. >> > It should have been valground. > But the Linux machine was in its box and the Apple Mac and Windows machines > were hogging the desktop. For cross-platform development, virtual machines are your friend. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-28 13:46 +0200 |
| Message-ID | <mub964$g77$1@dont-email.me> |
| In reply to | #71317 |
On 28/09/15 01:50, Ian Collins wrote: > Morten W. Petersen wrote: >> On 28.09.2015 00:08, Ian Collins wrote: >>> Morten W. Petersen wrote: >>>> On 27.09.2015 23:40, Ian Collins wrote: >> [...] >>>>> What happens when something else wants to use the public functions >>>>> from >>>>> decode_xml.c? As soon as you are going to have more than once source >>>>> file, introduce a public header. That way you can optimise >>>>> laziness :) >>>> >>>> Yes, of course. When things stabilize and it's time to make it >>>> available for others it should be as accessible as possible. :) >>> >>> That's suboptimal in terms of laziness. Create the header before you >>> call the functions in your tests. >>> >>> You could improve your laziness factor by using a unit test framework >>> rather than rolling your own. I go a step further by using unit test >>> frameworks my IDE understands how to generate code for and build... >> >> Hmm, yes. Well are there any testing frameworks that work across >> all C compilers that support C90? > > The test framework is simply a user of the code, so it doesn't have to > "support" old C. > > Because I use both C and C++ (and because they are more flexible), I use > C++ unit test frameworks for my code. > Can I ask you which framework(s) you use (or recommend)?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-09-29 07:52 +1300 |
| Message-ID | <d6tgjjFqr3pU26@mid.individual.net> |
| In reply to | #71367 |
David Brown wrote: > On 28/09/15 01:50, Ian Collins wrote: >> Morten W. Petersen wrote: >>> On 28.09.2015 00:08, Ian Collins wrote: >>>> Morten W. Petersen wrote: >>>>> On 27.09.2015 23:40, Ian Collins wrote: >>> [...] >>>>>> What happens when something else wants to use the public functions >>>>>> from >>>>>> decode_xml.c? As soon as you are going to have more than once source >>>>>> file, introduce a public header. That way you can optimise >>>>>> laziness :) >>>>> >>>>> Yes, of course. When things stabilize and it's time to make it >>>>> available for others it should be as accessible as possible. :) >>>> >>>> That's suboptimal in terms of laziness. Create the header before you >>>> call the functions in your tests. >>>> >>>> You could improve your laziness factor by using a unit test framework >>>> rather than rolling your own. I go a step further by using unit test >>>> frameworks my IDE understands how to generate code for and build... >>> >>> Hmm, yes. Well are there any testing frameworks that work across >>> all C compilers that support C90? >> >> The test framework is simply a user of the code, so it doesn't have to >> "support" old C. >> >> Because I use both C and C++ (and because they are more flexible), I use >> C++ unit test frameworks for my code. >> > > Can I ask you which framework(s) you use (or recommend)? CppUnit because I've been using it for a long time and it integrates with NetBeans and CxxTest with Visual Studio. The latter has the advantage of automated test executable generation. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-29 10:15 +0200 |
| Message-ID | <mudh7k$aid$1@dont-email.me> |
| In reply to | #71386 |
On 28/09/15 20:52, Ian Collins wrote: > David Brown wrote: >> On 28/09/15 01:50, Ian Collins wrote: >>> Morten W. Petersen wrote: >>>> On 28.09.2015 00:08, Ian Collins wrote: >>>>> Morten W. Petersen wrote: >>>>>> On 27.09.2015 23:40, Ian Collins wrote: >>>> [...] >>>>>>> What happens when something else wants to use the public functions >>>>>>> from >>>>>>> decode_xml.c? As soon as you are going to have more than once >>>>>>> source >>>>>>> file, introduce a public header. That way you can optimise >>>>>>> laziness :) >>>>>> >>>>>> Yes, of course. When things stabilize and it's time to make it >>>>>> available for others it should be as accessible as possible. :) >>>>> >>>>> That's suboptimal in terms of laziness. Create the header before you >>>>> call the functions in your tests. >>>>> >>>>> You could improve your laziness factor by using a unit test framework >>>>> rather than rolling your own. I go a step further by using unit test >>>>> frameworks my IDE understands how to generate code for and build... >>>> >>>> Hmm, yes. Well are there any testing frameworks that work across >>>> all C compilers that support C90? >>> >>> The test framework is simply a user of the code, so it doesn't have to >>> "support" old C. >>> >>> Because I use both C and C++ (and because they are more flexible), I use >>> C++ unit test frameworks for my code. >>> >> >> Can I ask you which framework(s) you use (or recommend)? > > CppUnit because I've been using it for a long time and it integrates > with NetBeans and CxxTest with Visual Studio. The latter has the > advantage of automated test executable generation. > Thanks. I use Eclipse as my main IDE (I've heard lots of nice things about NetBeans, but Eclipse is the standard for most microcontroller development tools I use). It looks like Boost.Test, Qt Test and Google Testing Framework are directly supported in Eclipse - but it should certainly be possible to use CppUnit with it. There was also a CxxTest plugin, but it seems to be outdated. Another option that looks like it has a good Eclipse plugin is Cute. I guess I've got a bit of reading, research, and trial-and-error to do here, to see what would suit my own uses best. But it helps to have a few suggestions to get started.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-02 09:55 +0000 |
| Message-ID | <560e53a9.3242031@news.xs4all.nl> |
| In reply to | #71302 |
Ian Collins <ian-news@hotmail.com> wrote: > Morten W. Petersen wrote: > > On 27.09.2015 23:40, Ian Collins wrote: > >> What happens when something else wants to use the public functions from > >> decode_xml.c? As soon as you are going to have more than once source > >> file, introduce a public header. That way you can optimise laziness :) > > > > Yes, of course. When things stabilize and it's time to make it > > available for others it should be as accessible as possible. :) > > That's suboptimal in terms of laziness. Create the header before you > call the functions in your tests. It's not even that much work. Every function should have a prototype anyway. Either it goes at the top of its own .c file, or it goes in the corresponding .h file (and never both!). In both cases, you have exactly one prototype for each function; whether the function needs to be called from other .c files or by functions defined earlier in the same .c file, the prototype is necessary anyway. The only way around it is if you define detail before overview, which IMAO is the backwards way. Richard
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-02 11:59 -0400 |
| Message-ID | <560EA9D4.3090102@verizon.net> |
| In reply to | #71588 |
On 10/02/2015 05:55 AM, Richard Bos wrote: > Ian Collins <ian-news@hotmail.com> wrote: > >> Morten W. Petersen wrote: >>> On 27.09.2015 23:40, Ian Collins wrote: > >>>> What happens when something else wants to use the public functions from >>>> decode_xml.c? As soon as you are going to have more than once source >>>> file, introduce a public header. That way you can optimise laziness :) >>> >>> Yes, of course. When things stabilize and it's time to make it >>> available for others it should be as accessible as possible. :) >> >> That's suboptimal in terms of laziness. Create the header before you >> call the functions in your tests. > > It's not even that much work. Every function should have a prototype > anyway. Either it goes at the top of its own .c file, or it goes in the > corresponding .h file (and never both!). For functions with external linkage, I always use two prototypes: one in the header file, and the one that forms the first part of the function definition. For functions with internal linkage, I use only the latter - I would make an exception for mutually recursive functions with internal linkage, but I've never had that case come up. Since you specify that the "top of the file" prototype should NOT be used if there's one in the header file, I assume that your "top of the file" prototype is not part of the function definition. If that's the case, could you justify your insistence on having such a prototype? It seems to me to be completely unnecessary so long as you define functions with internal linkage before they are first called, something that's normally entirely feasible except in the unusual case that two or more functions with internal linkage are mutually recursive.
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-10-03 11:51 -0700 |
| Message-ID | <MPG.3079c3a79ecc184d6b@news.eternal-september.org> |
| In reply to | #71616 |
James Kuyper wrote: > > Richard Bos wrote: > > It's not even that much work. Every function should have a prototype > > anyway. Either it goes at the top of its own .c file, or it goes in the > > corresponding .h file (and never both!). > > For functions with external linkage, I always use two prototypes: one in > the header file, and the one that forms the first part of the function > definition. For functions with internal linkage, I use only the latter - > I would make an exception for mutually recursive functions with internal > linkage, but I've never had that case come up. > > Since you specify that the "top of the file" prototype should NOT be > used if there's one in the header file, I assume that your "top of the > file" prototype is not part of the function definition. If that's the > case, could you justify your insistence on having such a prototype? It > seems to me to be completely unnecessary so long as you define functions > with internal linkage before they are first called, something that's > normally entirely feasible except in the unusual case that two or more > functions with internal linkage are mutually recursive. He gave his justification in the part that you snipped: "The only way around it is if you define detail before overview, which IMAO is the backwards way." Even though you don't agree with it, why would you snip it and then complain that he didn't give it?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-03 15:25 -0400 |
| Message-ID | <mupa05$dlc$1@dont-email.me> |
| In reply to | #71703 |
On 10/03/2015 02:51 PM, Philip Lantz wrote: > James Kuyper wrote: >> >> Richard Bos wrote: >>> It's not even that much work. Every function should have a prototype >>> anyway. Either it goes at the top of its own .c file, or it goes in the >>> corresponding .h file (and never both!). >> >> For functions with external linkage, I always use two prototypes: one in >> the header file, and the one that forms the first part of the function >> definition. For functions with internal linkage, I use only the latter - >> I would make an exception for mutually recursive functions with internal >> linkage, but I've never had that case come up. >> >> Since you specify that the "top of the file" prototype should NOT be >> used if there's one in the hat your "top of the >> file" prototype is not part of the function definition. If that's the >> case, could you justify your insistence on having such a prototype? It >> seems to me to be completely unnecessary so long as you define functions >> with internal linkage before they are first called, something that's >> normally entirely feasible except in the unusual case that two or more >> functions with internal linkage are mutually recursive. > > He gave his justification in the part that you snheader file, I assume tipped: "The only way > around it is if you define detail before overview, which IMAO is the > backwards way." Even though you don't agree with it, why would you snip > it and then complain that he didn't give it? Simple - I didn't notice it. And please don't ask how I managed to miss it. It's partly because he used different terminology than I would have, but that's not enough to justify missing entirely. :-( I do disagree with his objection. What he sees as "detail before overview", I see as "definition before use", and it feels quite natural to me. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-04 14:50 -0700 |
| Message-ID | <kfnvbam717o.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71588 |
raltbos@xs4all.nl (Richard Bos) writes: > Every function should have a prototype > anyway. Either it goes at the top of its own .c file, or it goes in the > corresponding .h file (and never both!). In both cases, you have exactly > one prototype for each function; whether the function needs to be called > from other .c files or by functions defined earlier in the same .c file, > the prototype is necessary anyway. The only way around it is if you > define detail before overview, which IMAO is the backwards way. FWIW I have the same opinion.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-09-27 18:32 -0400 |
| Message-ID | <u8_Nx.82540$eB4.40308@fx11.iad> |
| In reply to | #71301 |
On 9/27/15 5:58 PM, Morten W. Petersen wrote: > On 27.09.2015 23:40, Ian Collins wrote: >> Morten W. Petersen wrote: > [...] >>> 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. >>> >>> 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? >> >> What happens when something else wants to use the public functions from >> decode_xml.c? As soon as you are going to have more than once source >> file, introduce a public header. That way you can optimise laziness :) > > Yes, of course. When things stabilize and it's time to make it > available for others it should be as accessible as possible. :) > > -Morten > One way to to look at it is that your tests.c needs to see the definitions of the functions in decode_xml.c in order to call them. You can either create a header that is included in both files to make sure that it is kept in sync, or you can add the decelerations in text.c, and hope you have the discipline to make sure they are kept in sync. 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.
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-09-27 17:37 -0700 |
| Message-ID | <85fd2841-008b-4c1a-b666-9f52a44ca5aa@googlegroups.com> |
| In reply to | #71307 |
"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]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-09-27 17:50 -0700 |
| Message-ID | <83e23aa3-85ad-4340-947f-af1effbc0cd6@googlegroups.com> |
| In reply to | #71327 |
On Monday, September 28, 2015 at 1:37:24 AM UTC+1, asetof...@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 > Nanosvg is implemented as headers only. That's the emerging convention in C++. But nanosvg is actually C. You define NANOSVG_IMPLEMENTATION to get the function bodies.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-09-28 18:18 +0000 |
| Message-ID | <slrnn0j140.eij.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71335 |
On Mon, 2015-09-28, Malcolm McLean wrote: > On Monday, September 28, 2015 at 1:37:24 AM UTC+1, asetof...@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 >> > Nanosvg is implemented as headers only. That's the emerging convention > in C++. No; it just happens to be the right way to structure certain very generic libraries (e.g. most of Boost) because everything happens to be templates in them. A typical C++ application will perhaps be a bit more header-heavy than typical C99 code, but the difference won't be drastic. > But nanosvg is actually C. You define NANOSVG_IMPLEMENTATION to get > the function bodies. I don't know nanosvg, but it seems a bit unusual. What's the purpose of doing it that way? /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-09-28 11:31 -0700 |
| Message-ID | <d748b59e-ffc5-477b-948d-1d897f48ca92@googlegroups.com> |
| In reply to | #71382 |
On Monday, September 28, 2015 at 7:18:57 PM UTC+1, Jorgen Grahn wrote: > On Mon, 2015-09-28, Malcolm McLean wrote: > > > But nanosvg is actually C. You define NANOSVG_IMPLEMENTATION to get > > the function bodies. > > I don't know nanosvg, but it seems a bit unusual. What's the purpose > of doing it that way? > I don't know. I didn't write it. I did try to contribute a little optimisation (nothing much, just replacing a linear search with a binary search) but I was defeated by the github system. You've got to set up ssh public keys to push a change to the repository - it's reasonable enough, otherwise nasty people might try swamping attacks. But I couldn't work it out.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-09-29 07:37 +0000 |
| Message-ID | <slrnn0kful.eij.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71383 |
On Mon, 2015-09-28, Malcolm McLean wrote: > On Monday, September 28, 2015 at 7:18:57 PM UTC+1, Jorgen Grahn wrote: >> On Mon, 2015-09-28, Malcolm McLean wrote: >> >> > But nanosvg is actually C. You define NANOSVG_IMPLEMENTATION to get >> > the function bodies. >> >> I don't know nanosvg, but it seems a bit unusual. What's the purpose >> of doing it that way? >> > I don't know. I didn't write it. > I did try to contribute a little optimisation (nothing much, just > replacing a linear search with a binary search) but I was defeated by > the github system. You've got to set up ssh public keys to push > a change to the repository - it's reasonable enough, otherwise nasty > people might try swamping attacks. But I couldn't work it out. I don't know how github works with multiple authors, but with Git you can always do something like git format-patch -1 and mail it to the main author. She then uses 'git am' to apply the patch locally, with the correct author and commit message. That's probably the best way of handling patches from infrequent contributors, unless there's some github-specific way which I haven't looked into. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-09-27 17:38 -0700 |
| Message-ID | <3a89637b-7085-49f7-908e-c5e66a87a1bc@googlegroups.com> |
| In reply to | #71307 |
"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]
Page 5 of 17 — ← Prev page 1 … 3 4 [5] 6 7 … 17 Next page →
Back to top | Article view | comp.lang.c
csiph-web