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 4 of 17 — ← Prev page 1 2 3 [4] 5 6 … 17 Next page →
| From | Andrew Cooper <amc96@cam.ac.uk> |
|---|---|
| Date | 2015-09-26 00:02 +0100 |
| Message-ID | <mu4jqi$3tb$1@flame.srcf.net> |
| In reply to | #71186 |
On 25/09/2015 03:02, Morten W. Petersen wrote:
> Hi there.
>
> Once again I'm working on the Smash XML project, and I'm getting a
> SIGSEGV when calling a function.
>
> The line that ends up in a SIGSEGV is
>
> https://github.com/morphex/smash_xml/blob/6b558ae0347c04992d0f3c2306373a83d1c2765e/tests.c#L236
>
I gave up reading the code at line 29, where you have two different
potential SIGSEGV's, 'buffer' and 'file', which are potentially-NULL
pointers at the time at which you use them.
https://xkcd.com/371/
Observe:
andrew@saarn:/tmp/smash_xml.git$ git diff
diff --git a/Makefile b/Makefile
index 1c2b003..0114d2a 100644
--- a/Makefile
+++ b/Makefile
@@ -2,8 +2,8 @@ all:
gcc -std=c90 decode_xml.c tests.c -g -o decode_xml -I.
gcc -std=c90 message.c -g -o message -I.
debug:
- gcc -DDEBUG -ggdb3 -std=c90 decode_xml.c tests.c -o decode_xml -I.
- gcc -DDEBUG -ggdb3 -std=c90 message.c -o message -I.
+ gcc -Wall -Werror -Wextra -DDEBUG -ggdb3 -std=c90 decode_xml.c
tests.c -o decode_xml -I.
+ gcc -Wall -Werror -Wextra -DDEBUG -ggdb3 -std=c90 message.c -o
message -I.
clean:
rm -f *.exe
rm -f *.exe.stackdump
andrew@saarn:/tmp/smash_xml.git$ make debug |& wc -l
1194
You have an astoundingly large number of error which the compiler can
spot, and are committing the sin of writing C without using '-Wall
-Werror -Wextra'.
They are your friends. Don't write code without them.
~Andrew
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-27 00:02 +0200 |
| Message-ID | <mu74ks$2bs$1@speranza.aioe.org> |
| In reply to | #71207 |
On 26.09.2015 01:02, Andrew Cooper wrote: [...] > You have an astoundingly large number of error which the compiler can > spot, and are committing the sin of writing C without using '-Wall > -Werror -Wextra'. > > They are your friends. Don't write code without them. OK, added these now and will see how fixing all errors will fix the issue. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-09-26 23:32 -0700 |
| Message-ID | <cqte0b9t78jipsq13vrofrfd5gfk49lpsv@4ax.com> |
| In reply to | #71186 |
On Fri, 25 Sep 2015 04:02:03 +0200, "Morten W. Petersen"
<morphex@gmail.com> wrote:
>Hi there.
>
>Once again I'm working on the Smash XML project, and I'm getting a
>SIGSEGV when calling a function.
>
>The line that ends up in a SIGSEGV is
>
>https://github.com/morphex/smash_xml/blob/6b558ae0347c04992d0f3c2306373a83d1c2765e/tests.c#L236
>
>And gdb says this after "make debug; gdb ./decode_xml":
>
>(gdb) run
>[...]
>test_parse_file
>
>Program received signal SIGSEGV, Segmentation fault.
>__chkstk_ms () at /usr/src/debug/gcc-4.9.3-1/libgcc/config/i386/cygwin.S:172
>172 orl $0x0, (%ecx) /* probe there */
>(gdb) print $ecx
>$1 = 600600
>(gdb)
>
>So somewhere between the function call and this line
>
>https://github.com/morphex/smash_xml/blob/6b558ae0347c04992d0f3c2306373a83d1c2765e/decode_xml.c#L1020
>
>in the called function, something goes wrong and I can't
>quite figure out what it is.
>
>Any ideas?
>
>Regards,
>
>Morten
You call a lot of functions defined in decode_xml.c from within your
test programs. Where is the header file containing the prototypes for
those functions, decode_xml.h? Why are you not including it in your
test programs?
Many of your functions in decode_xml.c are not returning values on all
control paths. Functions get_length and get_length_unicode are
examples of this.
There are also several instances where you're returning a signed int
when you should be returning unsigned int. You're inconsistent in your
API.
May I also suggest adding:
//
// Debug print output
//
#include <stdarg.h>
#include <stdio.h>
void dprintf (char *msg, ...)
{
va_list argptr;
char text[128];
va_start (argptr, msg);
vsnprintf (text, sizeof(text), msg, argptr);
va_end (argptr);
#ifdef DEBUG
printf ("%s", text);
#endif
}
This will allow you to write:
dprintf("test_whitespace\n");
instead of all that #ifdef DEBUG nonsense that distracts from your
principle task of writing your functions correctly. You can find and
remove the dprintf calls later if you desire.
Your "parse_file" function conceals a hidden stub, resulting in a
large block of unreachable code. The stub is hidden because of lack of
vertical whitespace. The stub returns 0, but you don't check the
return value and fortunately, you don't appear to dereference the
returned pointer (yet). I suggest cleaning this up.
/* Receives a file object, returns a pointer to a parsed XML document
*/
struct xml_element* parse_file(FILE *file)
{
printf("In parse_file..\n");
fflush(NULL);
return 0;
unicode_char *buffer = NULL;
long file_descriptor = fileno(file);
...
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-27 22:10 +0200 |
| Message-ID | <mu9if9$aq1$1@speranza.aioe.org> |
| In reply to | #71257 |
On 27.09.2015 08:32, Geoff wrote:
[...]
> You call a lot of functions defined in decode_xml.c from within your
> test programs. Where is the header file containing the prototypes for
> those functions, decode_xml.h? Why are you not including it in your
> test programs?
Well, headers contain prototypes so a library can be linked to, right?
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.
The Makefile includes both source files necessary to make things work
when compiling the decode_xml executable.
> Many of your functions in decode_xml.c are not returning values on all
> control paths. Functions get_length and get_length_unicode are
> examples of this.
Yep.
> There are also several instances where you're returning a signed int
> when you should be returning unsigned int. You're inconsistent in your
> API.
>
>
> May I also suggest adding:
>
> //
> // Debug print output
> //
>
> #include <stdarg.h>
> #include <stdio.h>
>
> void dprintf (char *msg, ...)
> {
> va_list argptr;
> char text[128];
>
> va_start (argptr, msg);
> vsnprintf (text, sizeof(text), msg, argptr);
> va_end (argptr);
> #ifdef DEBUG
> printf ("%s", text);
> #endif
> }
>
> This will allow you to write:
>
> dprintf("test_whitespace\n");
>
> instead of all that #ifdef DEBUG nonsense that distracts from your
> principle task of writing your functions correctly. You can find and
> remove the dprintf calls later if you desire.
OK.
> Your "parse_file" function conceals a hidden stub, resulting in a
> large block of unreachable code. The stub is hidden because of lack of
> vertical whitespace. The stub returns 0, but you don't check the
> return value and fortunately, you don't appear to dereference the
> returned pointer (yet). I suggest cleaning this up.
>
> /* Receives a file object, returns a pointer to a parsed XML document
> */
> struct xml_element* parse_file(FILE *file)
> {
> printf("In parse_file..\n");
> fflush(NULL);
> return 0;
>
> unicode_char *buffer = NULL;
> long file_descriptor = fileno(file);
> ...
Yes, a bit sloppy maybe, but the point was to isolate the SIGSEGV
that was raised when that function was called.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-09-27 17:01 -0400 |
| Message-ID | <5608591F.8020005@verizon.net> |
| In reply to | #71289 |
On 09/27/2015 04:10 PM, Morten W. Petersen wrote: > On 27.09.2015 08:32, Geoff wrote: > [...] >> You call a lot of functions defined in decode_xml.c from within your >> test programs. Where is the header file containing the prototypes for >> those functions, decode_xml.h? Why are you not including it in your >> test programs? > > Well, headers contain prototypes so a library can be linked to, right? They're not essential for that purpose - all that's required is a compatible declaration of each identifier with external linkage in every translation unit where it's used. The use of headers for this purpose is not to enable linkage, but to avoid errors caused by using incompatible declarations in different translation units. By having only one declaration in the header, and #including it wherever the identifier is used, you guarantee that the declarations are not merely compatible, but in fact, identical. You should also #include the header in the translation unit where the object or function is defined, so that a diagnostic message becomes mandatory if the definition is incompatible with the declaration. > 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.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-09-27 22:15 +0100 |
| Message-ID | <mu9m4v$kal$1@dont-email.me> |
| In reply to | #71293 |
On 27/09/15 22:01, James Kuyper wrote: <snip> > Laziness > should be impelling you to use headers, not to avoid them. Laziness is a powerful driving force in programming. It is laziness that makes me: * make the code as readable as possible; * use a consistent layout style; * ensure that all objects have known values at all times; * decompose functionality sufficiently, without getting silly about it; * keep the control flow clear and simple; * favour portable constructs over non-portable; * avoid premature optimisations. These are not the only aspects of my programming that are a direct consequence of my laziness, but I'm too lazy to think of the others right now. Suffice to say that Larry Wall was absolutely right to consider laziness to be one of the three programming virtues (along with hubris and impatience, IIRC). As some of you may recall, LW also described the /other/ three programming virtues: diligence, humility, and patience. They're on my to-do list. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-27 23:36 +0200 |
| Message-ID | <mu9ng4$nk3$1@speranza.aioe.org> |
| In reply to | #71294 |
On 27.09.2015 23:15, Richard Heathfield wrote: > On 27/09/15 22:01, James Kuyper wrote: > > <snip> > >> Laziness >> should be impelling you to use headers, not to avoid them. > > Laziness is a powerful driving force in programming. It is laziness that > makes me: [...] > Suffice to say that Larry Wall was absolutely right to consider laziness > to be one of the three programming virtues (along with hubris and > impatience, IIRC). I think lazy is smart, hubris could be optimism and energy. Impatience, I'm not so sure about. Rather patience with intolerance for BS. -Morten
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-27 23:33 +0200 |
| Message-ID | <mu9n9v$mmp$1@speranza.aioe.org> |
| In reply to | #71293 |
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. 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? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-09-28 10:40 +1300 |
| Message-ID | <d6r62eFqr3pU13@mid.individual.net> |
| In reply to | #71296 |
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. > > 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 :) -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-27 23:58 +0200 |
| Message-ID | <mu9oop$qed$1@speranza.aioe.org> |
| In reply to | #71298 |
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
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-09-28 11:08 +1300 |
| Message-ID | <d6r7mpFqr3pU14@mid.individual.net> |
| In reply to | #71301 |
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. :) 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... -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-28 00:25 +0200 |
| Message-ID | <mu9qd7$tru$1@speranza.aioe.org> |
| In reply to | #71302 |
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? If not I'll just stick with what I've got. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-09-28 12:50 +1300 |
| Message-ID | <d6rdmgFqr3pU17@mid.individual.net> |
| In reply to | #71305 |
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. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-28 02:06 +0200 |
| Message-ID | <mua0ah$9np$1@speranza.aioe.org> |
| In reply to | #71317 |
On 28.09.2015 01:50, Ian Collins wrote: > Morten W. Petersen 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. But that C code still has to work in a C90 compile mode.. in other words, the entire project with tests should compile cleanly on a compiler that supports C90. I guess what I'm looking for is maybe a one source code file test framework that can be included in the project. > Because I use both C and C++ (and because they are more flexible), I use > C++ unit test frameworks for my code. OK. Well this project will require a straight C compiler as a minimum to compile with tests. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-09-28 13:15 +1300 |
| Message-ID | <d6rf5tFqr3pU19@mid.individual.net> |
| In reply to | #71321 |
Morten W. Petersen wrote: > On 28.09.2015 01:50, Ian Collins wrote: >> Morten W. Petersen 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. > > But that C code still has to work in a C90 compile mode.. in > other words, the entire project with tests should compile > cleanly on a compiler that supports C90. Why? It will undoubtedly be run in an environment that supports (and modulo Windows, will have been built with) a modern compiler, so why should the unit tests have to be in old C? Code under test and the test code should be completely decoupled. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-28 02:20 +0200 |
| Message-ID | <mua139$av5$1@speranza.aioe.org> |
| In reply to | #71323 |
On 28.09.2015 02:15, Ian Collins wrote: > Morten W. Petersen wrote: >> On 28.09.2015 01:50, Ian Collins wrote: >>> Morten W. Petersen 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. >> >> But that C code still has to work in a C90 compile mode.. in >> other words, the entire project with tests should compile >> cleanly on a compiler that supports C90. > > Why? It will undoubtedly be run in an environment that supports (and > modulo Windows, will have been built with) a modern compiler, so why > should the unit tests have to be in old C? This has been discussed at length earlier on comp.lang.c, why that is the right choice for this project. > Code under test and the test code should be completely decoupled. For functional testing yes, seems impractical for unit-testing. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-09-28 13:24 +1300 |
| Message-ID | <d6rfl3Fqr3pU20@mid.individual.net> |
| In reply to | #71325 |
Morten W. Petersen wrote: > On 28.09.2015 02:15, Ian Collins wrote: >> Morten W. Petersen wrote: >>> On 28.09.2015 01:50, Ian Collins wrote: >>>> Morten W. Petersen 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. >>> >>> But that C code still has to work in a C90 compile mode.. in >>> other words, the entire project with tests should compile >>> cleanly on a compiler that supports C90. >> >> Why? It will undoubtedly be run in an environment that supports (and >> modulo Windows, will have been built with) a modern compiler, so why >> should the unit tests have to be in old C? > > This has been discussed at length earlier on comp.lang.c, > why that is the right choice for this project. The library code can be in old C, the tests can be in whatever you like. >> Code under test and the test code should be completely decoupled. > > For functional testing yes, seems impractical for unit-testing. Not so. As I said, I use unit tests written in C++ for unit testing all my C and C++ code. The only requirement is the tests and an the code under test link. Potential users of your library may well be using modern C or even C++, the unit tests are no different. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-28 02:44 +0200 |
| Message-ID | <mua2hj$dgg$1@speranza.aioe.org> |
| In reply to | #71326 |
On 28.09.2015 02:24, Ian Collins wrote: > Morten W. Petersen wrote: >> On 28.09.2015 02:15, Ian Collins wrote: >>> Morten W. Petersen wrote: >>>> On 28.09.2015 01:50, Ian Collins wrote: >>>>> Morten W. Petersen 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. >>>> >>>> But that C code still has to work in a C90 compile mode.. in >>>> other words, the entire project with tests should compile >>>> cleanly on a compiler that supports C90. >>> >>> Why? It will undoubtedly be run in an environment that supports (and >>> modulo Windows, will have been built with) a modern compiler, so why >>> should the unit tests have to be in old C? >> >> This has been discussed at length earlier on comp.lang.c, >> why that is the right choice for this project. > > The library code can be in old C, the tests can be in whatever you like. And by this you mean? >>> Code under test and the test code should be completely decoupled. >> >> For functional testing yes, seems impractical for unit-testing. > > Not so. As I said, I use unit tests written in C++ for unit testing all > my C and C++ code. The only requirement is the tests and an the code > under test link. Potential users of your library may well be using > modern C or even C++, the unit tests are no different. OK. I've tried different forms of testing, and found functional tests that interfaced with a web service over HTTP to be useful. That way, the tests ran completely separated from whatever the environment the code being tested was in. It could even be on separate servers. It was useful as I encountered different settings where code gave different results because of dependencies, overrides and so on. The tests stayed the same and expected the same results regardless of what happened on the "other side". -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-09-28 13:50 +1300 |
| Message-ID | <d6rh6eFqr3pU22@mid.individual.net> |
| In reply to | #71331 |
Morten W. Petersen wrote: > On 28.09.2015 02:24, Ian Collins wrote: >> Morten W. Petersen wrote: >>> On 28.09.2015 02:15, Ian Collins wrote: >>>> Morten W. Petersen wrote: >>>>> On 28.09.2015 01:50, Ian Collins wrote: >>>>>> Morten W. Petersen 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. >>>>> >>>>> But that C code still has to work in a C90 compile mode.. in >>>>> other words, the entire project with tests should compile >>>>> cleanly on a compiler that supports C90. >>>> >>>> Why? It will undoubtedly be run in an environment that supports (and >>>> modulo Windows, will have been built with) a modern compiler, so why >>>> should the unit tests have to be in old C? >>> >>> This has been discussed at length earlier on comp.lang.c, >>> why that is the right choice for this project. >> >> The library code can be in old C, the tests can be in whatever you like. > > And by this you mean? Unit tests call functions in your code with known data and validate the result. They should also mock any external functions to allow you to test your function with given data and error conditions. Neither of these activities require the test code to be written in the same C dialect or even in C. They just have to link with your code. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-09-27 23:44 -0700 |
| Message-ID | <MPG.307281aa41da482356@news.eternal-september.org> |
| In reply to | #71317 |
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?
[toc] | [prev] | [next] | [standalone]
Page 4 of 17 — ← Prev page 1 2 3 [4] 5 6 … 17 Next page →
Back to top | Article view | comp.lang.c
csiph-web