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 15 of 17 — ← Prev page 1 … 13 14 [15] 16 17 Next page →
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-09-30 18:17 -0400 |
| Message-ID | <muhmtb$vdc$1@dont-email.me> |
| In reply to | #71505 |
On 9/30/2015 5:19 PM, Rosario19 wrote:
> On Wed, 30 Sep 2015 16:53:42 -0400, Eric Sosman wrote:
>> On 9/30/2015 4:28 PM, Rosario19 wrote:
>>> [...]
>>> it is wrong... a good function remain good even if has 0 comment
>> [...]
>> There are two audiences for program source code: Computers and
>> people. The latter are the more important.
>
> yes i agree etc
>
> but for me it is enought code of the function + one or more example in
> how one can use that function, and a significative name for that
> function... and that function has the correct output from its input
Most of this paragraph is beyond my ability to understand, but the
final phrase makes sense. One of the most important purposes of the
comment is to describe what "correct" is, because there is no construct
in the C language that defines or even addresses "correctness." (No,
not even the `assert' macro.) Can you tell whether the following
function is correct?
#include <math.h>
double peirceRatio(size_t n, size_t k, size_t m)
{
#define A 0.7071067811865475244
#define B 0.4839414490382866996
double lnqn;
double x, xmax, oldx;
double r1, r2, r1d, r2d;
if (n <= m || n-m <= k) {
return 0.0;
}
lnqn = k*log(k) + (n-k)*log(n-k) - n*log(n);
xmax = sqrt( (double) (n-m) / (double) k ) - 1e-10;
x = 1.0;
do {
x = x <= xmax ? x : xmax;
r1 = exp((x*x - 1.0) * 0.5) * erfc(x * A);
r2 = exp((lnqn - 0.5*(n-k)*log((n-m-k*x*x)/(n-m-k))) / k);
r1d = r1 * x - B;
r2d = r2 * x * (n-k)/(n-m-k*x*x);
oldx = x;
x -= (r1 - r2) / (r1d - r2d);
} while (fabs(x - oldx) > n * 2e-16);
return x;
#undef A
#undef B
}
This isn't something just thrown together; it's an actual piece of code
that I wrote ("adapted," really, from somebody else's pseudocode), with
the comments removed. Is it correct?
To help you make up your mind I'll give you a bit of information a
new-on-the-scene code reader might lack: I have tested this code by
using it to reproduce a printed table of 467 values of the quantity it
is intended to compute, and it agrees with the printed table in 466 of
the 467 cases. Does this information help you determine correctness?
It's easy enough to see what the code does, but is "what it does"
the same as "what it's supposed to do?" Are the various magic numbers
well chosen? The loop looks like a Newton iteration, but is it correct?
Is the termination condition suitable?
The stripped-out comments describe the function that the code tries
to compute, explains the three parameters, gives a URL for the original
pseudocode, discusses the anomalous 467th data point, gives URL's for
the printed table and for a printed table of a closely related function,
and speculates on the likely cause of the discrepancy (hypothesis: The
value 1.480 in one table was misread as 1.430 when preparing the other),
and even explains two of the magic numbers. I argue that the commentary
would be immensely valuable to anyone trying to decide whether my code
was any damn' good, and that anyone lacking the commentary would be
largely at a loss.
... and that's why comments can improve even a "good" function.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-10-01 03:19 +0200 |
| Message-ID | <mui1lj$ard$1@speranza.aioe.org> |
| In reply to | #71504 |
On 30.09.2015 22:53, Eric Sosman wrote: [...] > This is so awful an idea that I hadn't even considered it when I > wrote that the final line was "a mystery to me." Some things, > though physically possible, are about as far beyond the pale as > raping your Rottweiler. When people write stuff like this it shows that they really aren't being objective and have to resort to weird sexual references to make a point. -Morten
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-09-30 22:01 -0400 |
| Message-ID | <mui414$vtf$1@dont-email.me> |
| In reply to | #71514 |
On 09/30/2015 09:19 PM, Morten W. Petersen wrote: > On 30.09.2015 22:53, Eric Sosman wrote: > [...] >> This is so awful an idea that I hadn't even considered it when I >> wrote that the final line was "a mystery to me." Some things, >> though physically possible, are about as far beyond the pale as >> raping your Rottweiler. > > When people write stuff like this it shows that they really aren't > being objective and have to resort to weird sexual references to > make a point. No, it means that he's straining to come up with a metaphor to show how bad an idea this is. Explaining what's bad about it doesn't seem to have worked. I doubt that putting things in these terms will work, either, but it can't hurt to try. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-10-02 00:46 +0200 |
| Message-ID | <mukd3p$sup$2@speranza.aioe.org> |
| In reply to | #71516 |
On 01.10.2015 04:01, James Kuyper wrote: > On 09/30/2015 09:19 PM, Morten W. Petersen wrote: >> On 30.09.2015 22:53, Eric Sosman wrote: >> [...] >>> This is so awful an idea that I hadn't even considered it when I >>> wrote that the final line was "a mystery to me." Some things, >>> though physically possible, are about as far beyond the pale as >>> raping your Rottweiler. >> >> When people write stuff like this it shows that they really aren't >> being objective and have to resort to weird sexual references to >> make a point. > > No, it means that he's straining to come up with a metaphor to show how > bad an idea this is. Explaining what's bad about it doesn't seem to have > worked. I doubt that putting things in these terms will work, either, > but it can't hurt to try. No, those terms makes me think less of his arguments. Haven't made my mind up about him yet but I guess I'll see. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-09-27 17:44 -0700 |
| Message-ID | <kl0h0b1die20fmo3plaagmcvh9uov7j5og@4ax.com> |
| In reply to | #71289 |
On Sun, 27 Sep 2015 22:10:31 +0200, "Morten W. Petersen" <morphex@gmail.com> wrote: >Well, headers contain prototypes so a library can be linked to, right? As others have commented, no, headers are not solely for that purpose and they are good for much more. Writing prototypes helps the compiler help you maintain organization and discipline which helps you write better and more correct code. Whether you consider decode_xml to be a "library" or not, it's a separate translation unit from tests.c. You need to provide the compiler with the knowledge it needs to cross-check your usage of the functions in the two translation units. For example, you call get_length here: https://github.com/morphex/smash_xml/blob/6b558ae0347c04992d0f3c2306373a83d1c2765e/tests.c#L211 Where your prototype of get_length would be (in accord with the definition): __inline__ source_buffer_index get_length(CONST char* string); https://github.com/morphex/smash_xml/blob/6b558ae0347c04992d0f3c2306373a83d1c2765e/decode_xml.c#L533 but the buffer you pass to get_length is declared as unicode_char * which, if you had written a prototype header for your functions, would be detected as an error. Your failure to establish a consistent methodology and workflow is resulting in more effort to maintain and debug your code, fosters an undisciplined approach to the maintenance of the code, creates undetected errors in your code and results in surprising, to you, SIG_SEGV faults that lead you down the wrong path. Your present methods are inconsistent with your stated goal of creating a fast and secure XML parser. P.S. I consider your excessive use of __inline__ to be unnecessary and gratuitous.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-09-28 13:51 +1300 |
| Message-ID | <d6rh9fFqr3pU23@mid.individual.net> |
| In reply to | #71332 |
Geoff wrote: > > P.S. I consider your excessive use of __inline__ to be unnecessary and > gratuitous. As well as superfluous! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-09-27 18:04 -0700 |
| Message-ID | <if4h0btchk728fvsuo3gmf8ctrr3f64545@4ax.com> |
| In reply to | #71336 |
On Mon, 28 Sep 2015 13:51:58 +1300, Ian Collins <ian-news@hotmail.com> wrote: >Geoff wrote: >> >> P.S. I consider your excessive use of __inline__ to be unnecessary and >> gratuitous. > >As well as superfluous! And unjustifiably unwarranted. :)
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-28 03:39 +0200 |
| Message-ID | <mua5o4$iqj$1@speranza.aioe.org> |
| In reply to | #71337 |
On 28.09.2015 03:04, Geoff wrote: > On Mon, 28 Sep 2015 13:51:58 +1300, Ian Collins <ian-news@hotmail.com> > wrote: > >> Geoff wrote: >>> >>> P.S. I consider your excessive use of __inline__ to be unnecessary and >>> gratuitous. >> >> As well as superfluous! > > And unjustifiably unwarranted. :) It might be that using that keyword is obsolete and unwarranted, but given that the playable binary code will be of modest size and that a bourne of the endeavour is to do the task with haste, being clear-cut about it is a favourable belly up. -Morten
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-09-27 22:03 -0400 |
| Message-ID | <mua71m$5i8$1@dont-email.me> |
| In reply to | #71341 |
On 09/27/2015 09:39 PM, Morten W. Petersen wrote: > On 28.09.2015 03:04, Geoff wrote: >> On Mon, 28 Sep 2015 13:51:58 +1300, Ian Collins <ian-news@hotmail.com> >> wrote: >> >>> Geoff wrote: >>>> >>>> P.S. I consider your excessive use of __inline__ to be unnecessary and >>>> gratuitous. >>> >>> As well as superfluous! >> >> And unjustifiably unwarranted. :) > > It might be that using that keyword is obsolete ... Use of a compiler extension that uses __inline__ rather than the C standard feature using "inline" is obsolete - but that's not the key problem. > ... and unwarranted, > but given that the playable binary code will be of modest size and > that a bourne of the endeavour is to do the task with haste, being > clear-cut about it is a favourable belly up. He's saying that you're using __inline__ in places where there's little if any reason to expect it give you a significant benefit. Keep in mind that an implementation is always free to inline code if it thinks that's a good idea, regardless of whether you use the "inline" keyword. The reverse is true: an implementation is free to to ignore explicitly specified "inline". Many modern compilers do both, because there's significant evidence that ignoring user-specified "inline" produces better code. That's because users seldom correctly guess the locations where it would do the most good - or at least, they guess correctly significantly less often than the compiler does. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-28 04:16 +0200 |
| Message-ID | <mua7t5$mcc$1@speranza.aioe.org> |
| In reply to | #71342 |
On 28.09.2015 04:03, James Kuyper wrote: > On 09/27/2015 09:39 PM, Morten W. Petersen wrote: [...] >> ... and unwarranted, >> but given that the playable binary code will be of modest size and >> that a bourne of the endeavour is to do the task with haste, being >> clear-cut about it is a favourable belly up. > > He's saying that you're using __inline__ in places where there's little > if any reason to expect it give you a significant benefit. > Keep in mind that an implementation is always free to inline code if it > thinks that's a good idea, regardless of whether you use the "inline" > keyword. The reverse is true: an implementation is free to to ignore > explicitly specified "inline". Many modern compilers do both, because > there's significant evidence that ignoring user-specified "inline" > produces better code. That's because users seldom correctly guess the > locations where it would do the most good - or at least, they guess > correctly significantly less often than the compiler does. I guess the best way to select functions for inlining would be to profile the code as it was dealing with real data. Are there tools that do that? What are the cut-off points for selecting which functions to inline and which to not inline? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-09-28 15:19 +1300 |
| Message-ID | <d6rmd1Fqr3pU24@mid.individual.net> |
| In reply to | #71344 |
Morten W. Petersen wrote: > On 28.09.2015 04:03, James Kuyper wrote: >> On 09/27/2015 09:39 PM, Morten W. Petersen wrote: > [...] >>> ... and unwarranted, >>> but given that the playable binary code will be of modest size and >>> that a bourne of the endeavour is to do the task with haste, being >>> clear-cut about it is a favourable belly up. >> >> He's saying that you're using __inline__ in places where there's little >> if any reason to expect it give you a significant benefit. >> Keep in mind that an implementation is always free to inline code if it >> thinks that's a good idea, regardless of whether you use the "inline" >> keyword. The reverse is true: an implementation is free to to ignore >> explicitly specified "inline". Many modern compilers do both, because >> there's significant evidence that ignoring user-specified "inline" >> produces better code. That's because users seldom correctly guess the >> locations where it would do the most good - or at least, they guess >> correctly significantly less often than the compiler does. > > I guess the best way to select functions for inlining would be to > profile the code as it was dealing with real data. Are there tools > that do that? > > What are the cut-off points for selecting which functions to inline > and which to not inline? Leave the choice to the compiler, unless you are sure you know better, which you won't. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-28 04:23 +0200 |
| Message-ID | <mua89t$mlj$1@speranza.aioe.org> |
| In reply to | #71346 |
On 28.09.2015 04:19, Ian Collins wrote: > Morten W. Petersen wrote: >> On 28.09.2015 04:03, James Kuyper wrote: >>> On 09/27/2015 09:39 PM, Morten W. Petersen wrote: >> [...] >>>> ... and unwarranted, >>>> but given that the playable binary code will be of modest size and >>>> that a bourne of the endeavour is to do the task with haste, being >>>> clear-cut about it is a favourable belly up. >>> >>> He's saying that you're using __inline__ in places where there's little >>> if any reason to expect it give you a significant benefit. >>> Keep in mind that an implementation is always free to inline code if it >>> thinks that's a good idea, regardless of whether you use the "inline" >>> keyword. The reverse is true: an implementation is free to to ignore >>> explicitly specified "inline". Many modern compilers do both, because >>> there's significant evidence that ignoring user-specified "inline" >>> produces better code. That's because users seldom correctly guess the >>> locations where it would do the most good - or at least, they guess >>> correctly significantly less often than the compiler does. >> >> I guess the best way to select functions for inlining would be to >> profile the code as it was dealing with real data. Are there tools >> that do that? >> >> What are the cut-off points for selecting which functions to inline >> and which to not inline? > > Leave the choice to the compiler, unless you are sure you know better, > which you won't. Well I'm going to do some Assembly at some point to optimize the code further, and that's lower level than in some way profiling the code with real data and selecting blocks of code for inlining. Does the compiler in general base its choices for inlining on the architecture, or something else? -Morten
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-29 14:11 +0200 |
| Message-ID | <mudv20$sb5$1@dont-email.me> |
| In reply to | #71347 |
On 28/09/15 04:23, Morten W. Petersen wrote: > On 28.09.2015 04:19, Ian Collins wrote: >> Morten W. Petersen wrote: <snip> >>> What are the cut-off points for selecting which functions to inline >>> and which to not inline? >> >> Leave the choice to the compiler, unless you are sure you know better, >> which you won't. > > Well I'm going to do some Assembly at some point to optimize the code > further, and that's lower level than in some way profiling the code > with real data and selecting blocks of code for inlining. Have you done the profiling and measurements to show that the code is a bottleneck? Have you looked at how you can improve the algorithms rather than the code? Have you looked at how you can work with the source code, and work with your compiler, towards generating faster object code for the key parts of the code? I am pretty sure the answer here is "no" to all of these, making any thoughts of assembly completely pointless (unless you are doing it for fun or education, in which case you shouldn't let me stop you!). The compiler knows more about generating fast code than most assembler programmers. It has a better overview of the code than most programmers. It understands register allocation, scheduling, branch prediction, superscaler pipelines, and caching better than most programmers. Learn to work with the compiler, and then you can make code that is more maintainable, more portable, and almost certainly faster than faffing around with assembly before you can even write it properly in C. Learn C properly, including listening to the advice you get in this group. Drop the C90 nonsense unless you really need to support ancient or limited compilers. If you are interested in making code that is as fast as possible, limit yourself to one or two compilers and use the features there to get faster code - using gcc extensions and attributes will let you write code that is almost certainly faster than you could get in hand-written assembly, while being portable across a wide range of architectures and sub-architectures (such as different x86 variants). > > Does the compiler in general base its choices for inlining on the > architecture, or something else? > It makes the choices regarding inlining based on a number of heuristics, a number of options and flags, and (if available) profiling information. Key points include: If a function is only used once (usually a static function), it will normally be inlined automatically. If a function is small enough that inlining (taking into account things like constant propagation and other optimisations) is shorter than the overhead for a function call, then it will be inlined. For optimisation levels other than -Os (optimise for size), the compiler will make a decision based on how often it thinks the function is being called, and how much bigger it makes the code. For modern cpus, the balance between code size and speed is not an easy one, and the compiler knows more about the interplay between scheduling, caches, branches, and so on, than most programmers. Remember, inlining does not necessarily make code bigger - and it does not necessarily make code faster. And it does not have to be an all-or-nothing affair - the compiler can do partial inlining too.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-30 00:15 +0200 |
| Message-ID | <muf2hi$pae$1@speranza.aioe.org> |
| In reply to | #71426 |
On 29.09.2015 14:11, David Brown wrote: > On 28/09/15 04:23, Morten W. Petersen wrote: [...] >> Well I'm going to do some Assembly at some point to optimize the code >> further, and that's lower level than in some way profiling the code >> with real data and selecting blocks of code for inlining. > > Have you done the profiling and measurements to show that the code is a > bottleneck? Have you looked at how you can improve the algorithms > rather than the code? Have you looked at how you can work with the > source code, and work with your compiler, towards generating faster > object code for the key parts of the code? > > I am pretty sure the answer here is "no" to all of these, making any > thoughts of assembly completely pointless (unless you are doing it for > fun or education, in which case you shouldn't let me stop you!). > > The compiler knows more about generating fast code than most assembler > programmers. It has a better overview of the code than most > programmers. It understands register allocation, scheduling, branch > prediction, superscaler pipelines, and caching better than most > programmers. Learn to work with the compiler, and then you can make > code that is more maintainable, more portable, and almost certainly > faster than faffing around with assembly before you can even write it > properly in C. > > Learn C properly, including listening to the advice you get in this > group. Drop the C90 nonsense unless you really need to support ancient > or limited compilers. If you are interested in making code that is as > fast as possible, limit yourself to one or two compilers and use the > features there to get faster code - using gcc extensions and attributes > will let you write code that is almost certainly faster than you could > get in hand-written assembly, while being portable across a wide range > of architectures and sub-architectures (such as different x86 variants). Yes, most compilers are good at optimizing the code, and it isn't important for the project itself that I or someone else gets down to the Assembly level. I have an interest in exploring Assembly, but it isn't important for the project as a whole. One thing is introducing bugs, another is making mistakes that affect the security when doing Assembly-level programming. To see the entire development cycle, first is getting things to work correctly and making the code well-designed (and implied in that, easy to read and understand). And secure. The comes speed optimizations, on the C-level, compiler settings, profiling and so on. When all higher-level or reasonable approaches are exhausted, then Assembly-level programming can begin. >> Does the compiler in general base its choices for inlining on the >> architecture, or something else? >> > > It makes the choices regarding inlining based on a number of heuristics, > a number of options and flags, and (if available) profiling information. > Key points include: > > If a function is only used once (usually a static function), it will > normally be inlined automatically. > > If a function is small enough that inlining (taking into account things > like constant propagation and other optimisations) is shorter than the > overhead for a function call, then it will be inlined. > > For optimisation levels other than -Os (optimise for size), the compiler > will make a decision based on how often it thinks the function is being > called, and how much bigger it makes the code. For modern cpus, the > balance between code size and speed is not an easy one, and the compiler > knows more about the interplay between scheduling, caches, branches, and > so on, than most programmers. > > Remember, inlining does not necessarily make code bigger - and it does > not necessarily make code faster. And it does not have to be an > all-or-nothing affair - the compiler can do partial inlining too. OK. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-29 18:14 -0700 |
| Message-ID | <lnwpv83dyu.fsf@kst-u.example.com> |
| In reply to | #71452 |
"Morten W. Petersen" <morphex@gmail.com> writes:
[...]
> To see the entire development cycle, first is getting things to
> work correctly and making the code well-designed (and implied
> in that, easy to read and understand). And secure.
>
> The comes speed optimizations, on the C-level, compiler settings,
> profiling and so on.
>
> When all higher-level or reasonable approaches are exhausted, then
> Assembly-level programming can begin.
[...]
And that last step is rarely necessary.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-10-02 00:41 +0200 |
| Message-ID | <mukcpq$sup$1@speranza.aioe.org> |
| In reply to | #71459 |
On 30.09.2015 03:14, Keith Thompson wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: > [...] >> To see the entire development cycle, first is getting things to >> work correctly and making the code well-designed (and implied >> in that, easy to read and understand). And secure. >> >> The comes speed optimizations, on the C-level, compiler settings, >> profiling and so on. >> >> When all higher-level or reasonable approaches are exhausted, then >> Assembly-level programming can begin. > [...] > > And that last step is rarely necessary. Well, it's a while until I get there, the project trumps trying out "real Assembly", but it will be nice once I get there to get into the gritty details. Finding out which processor to optimize for first is something else, but X86 64 looks like the most practical, reality-oriented place to start. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-09-27 19:58 -0700 |
| Message-ID | <aaacdffb-c520-4e02-bd50-cdae07fd1df6@googlegroups.com> |
| In reply to | #71344 |
On Monday, September 28, 2015 at 3:16:19 AM UTC+1, Morten W. Petersen wrote: > On 28.09.2015 04:03, James Kuyper wrote: > > What are the cut-off points for selecting which functions to inline > and which to not inline? > You inline short functions which are called in the inner loop. A halfway decent compiler just ignores the directive. But it tells another programmer that this is the performance-critical section, and not to add anything processor-intensive to the code if he can possibly help it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-29 10:43 +0200 |
| Message-ID | <mudird$g3o$1@dont-email.me> |
| In reply to | #71344 |
On 28/09/15 04:16, Morten W. Petersen wrote:
> On 28.09.2015 04:03, James Kuyper wrote:
>> On 09/27/2015 09:39 PM, Morten W. Petersen wrote:
> [...]
>>> ... and unwarranted,
>>> but given that the playable binary code will be of modest size and
>>> that a bourne of the endeavour is to do the task with haste, being
>>> clear-cut about it is a favourable belly up.
>>
>> He's saying that you're using __inline__ in places where there's little
>> if any reason to expect it give you a significant benefit.
>> Keep in mind that an implementation is always free to inline code if it
>> thinks that's a good idea, regardless of whether you use the "inline"
>> keyword. The reverse is true: an implementation is free to to ignore
>> explicitly specified "inline". Many modern compilers do both, because
>> there's significant evidence that ignoring user-specified "inline"
>> produces better code. That's because users seldom correctly guess the
>> locations where it would do the most good - or at least, they guess
>> correctly significantly less often than the compiler does.
>
> I guess the best way to select functions for inlining would be to
> profile the code as it was dealing with real data. Are there tools
> that do that?
Yes, there are tools to do that. But they are not normally necessary.
The compiler will usually do a good job of deciding which functions
should be inlined, and which should not.
I use "inline" in two ways. One is to make it clear that I expect the
function in question to be inlined - usually this is for functions that
would be inlined anyway by the compiler, but I think that marking it as
"inline" would make it clearer. I almost invariably have such functions
marked "static":
static inline int sum(int a, int b) {
return a + b;
}
Such functions might be in a header or in an implementation file.
The other use is when I want to force the compiler to inline the
function, even if its heuristics might be against that, because I know
more about the code usage than the compiler does. In such cases,
"inline" is accompanied with gcc attributes such as "always_inline" or
perhaps "flatten". And it is also declared "static".
>
> What are the cut-off points for selecting which functions to inline
> and which to not inline?
>
For most purposes, you don't need to use inline at all - write your code
clearly, learn to use your compiler and its optimisation flags, and let
the tools figure it out for you.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-30 00:16 +0200 |
| Message-ID | <muf2jt$pae$2@speranza.aioe.org> |
| In reply to | #71420 |
On 29.09.2015 10:43, David Brown wrote: > On 28/09/15 04:16, Morten W. Petersen wrote: [...] >> I guess the best way to select functions for inlining would be to >> profile the code as it was dealing with real data. Are there tools >> that do that? > > Yes, there are tools to do that. But they are not normally necessary. > The compiler will usually do a good job of deciding which functions > should be inlined, and which should not. OK. Can you name any Open Source tools available for that job? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-09-29 15:51 -0700 |
| Message-ID | <6441856e-4082-4757-b564-1b0246061409@googlegroups.com> |
| In reply to | #71453 |
On Tuesday, September 29, 2015 at 11:16:38 PM UTC+1, Morten W. Petersen wrote: > On 29.09.2015 10:43, David Brown wrote: > > On 28/09/15 04:16, Morten W. Petersen wrote: > [...] > >> I guess the best way to select functions for inlining would be to > >> profile the code as it was dealing with real data. Are there tools > >> that do that? > > > > Yes, there are tools to do that. But they are not normally necessary. > > The compiler will usually do a good job of deciding which functions > > should be inlined, and which should not. > > OK. Can you name any Open Source tools available for that job? > gprof. It runs on Linux. It will tell you how many times each function was called, how long the program sent in the function itself, and how long the function spent in the function and all its subroutines. So it tells you where the bottlenecks are. However just inlining seldom helps much, because the compiler does that anyway. What you can often do is avoid calcuating things twice. For example, if your logic is "replace employee name with duplicate string, set namelen field to number of characters in name" you would normally write that as employee.name = strdup(name); employee.namelen = strlen(name). However strdup is going to get the length of the name internally, you don't actually need the second call.
[toc] | [prev] | [next] | [standalone]
Page 15 of 17 — ← Prev page 1 … 13 14 [15] 16 17 Next page →
Back to top | Article view | comp.lang.c
csiph-web