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 14 of 17 — ← Prev page 1 … 12 13 [14] 15 16 17 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-09-29 15:50 +0100 |
| Message-ID | <mue8cc$1qg$1@dont-email.me> |
| In reply to | #71419 |
On 29/09/15 09:34, David Brown wrote: > On 29/09/15 01:16, Morten W. Petersen wrote: <snip> >> Is this supposed to be funny or obnoxious? >> > > It is supposed to convey to you how "highly" other programmers here - > with vastly more experience than you - regard your idea of using macros > for your function prototypes. If I understand it correctly, the idea is to protect the code from an accidental modification of a header prototype without a corresponding modification in the function definition. The payoff is tiny - the compiler will tell you about such mismatches anyway - and the cost is considerable. Everybody knows what a function prototype looks like, and what it's for, but this macro stands in the way of that understanding. It looks ugly, it's confusing, and it's pointless. There is more than enough of such code out there already, and we don't need any more. > People have tried to convince you of how bad an idea it is, using many > different methods. Some have given you technical reasons, some have > simply said that since no one else writes code this way, it is at best > unclear and confusing. Others find the concept so bad in so many ways > that they don't know where to start in explaining it to you. From past experience, I am rapidly coming to the conclusion that, if we had some particular reason to wish for Morten to adopt a particular programming strategy, all we would have to do is recommend against it. > Of course it is possible to program C in your own private way that is > different from everyone else. There is at least once person here that > regularly posts with code that looks more like APL than familiar C code. > But if you ever have ambitions of sharing code or discussing code with > other people, you would be wise to follow common practice here. When someone posts a question about their C code here, the first thing I do is glance at the code. If it looks as if it has been made deliberately hard to read, normally I will simply skip to the next post. It saves me a fair amount of time. -- 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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-09-29 11:16 -0400 |
| Message-ID | <mue9sj$84o$1@dont-email.me> |
| In reply to | #71428 |
On 09/29/2015 10:50 AM, Richard Heathfield wrote: ... > From past experience, I am rapidly coming to the conclusion that, if we > had some particular reason to wish for Morten to adopt a particular > programming strategy, all we would have to do is recommend against it. That's an exaggeration, as usual. While advice that would help him produce fewer defects is ignored, when we point out an actual defect in code, he does seem to pay attention. He ignores our advice when it conflicts with what he's already decided to do, but he doesn't actively reverse our advice. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-09-29 16:22 +0100 |
| Message-ID | <muea7d$9ii$1@dont-email.me> |
| In reply to | #71429 |
On 29/09/15 16:16, James Kuyper wrote: > On 09/29/2015 10:50 AM, Richard Heathfield wrote: > ... >> From past experience, I am rapidly coming to the conclusion that, if we >> had some particular reason to wish for Morten to adopt a particular >> programming strategy, all we would have to do is recommend against it. > > That's an exaggeration, as usual. Me, exaggerate? I've told you a thousand times... Well, all right, yes, it's hyperbole - and of course we all know that we should avoid hyperbole like the plague. > While advice that would help him > produce fewer defects is ignored, when we point out an actual defect in > code, he does seem to pay attention. He ignores our advice when it > conflicts with what he's already decided to do, but he doesn't actively > reverse our advice. My exaggeration was mostly based on my recollection of his early discussions in this group, in which it did seem very much (to me, at least) as if he was genuinely asking for advice and then setting out to do the precise opposite to the advice he was given. -- 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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-09-29 13:15 -0400 |
| Message-ID | <muegrj$5c7$1@dont-email.me> |
| In reply to | #71430 |
On 09/29/2015 11:22 AM, Richard Heathfield wrote: > On 29/09/15 16:16, James Kuyper wrote: ... >> While advice that would help him >> produce fewer defects is ignored, when we point out an actual defect in >> code, he does seem to pay attention. He ignores our advice when it >> conflicts with what he's already decided to do, but he doesn't actively >> reverse our advice. > > My exaggeration was mostly based on my recollection of his early > discussions in this group, in which it did seem very much (to me, at > least) as if he was genuinely asking for advice and then setting out to > do the precise opposite to the advice he was given. That, I didn't notice - could you give an example? -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-09-29 18:56 +0100 |
| Message-ID | <muej87$f14$1@dont-email.me> |
| In reply to | #71441 |
On 29/09/15 18:15, James Kuyper wrote: > On 09/29/2015 11:22 AM, Richard Heathfield wrote: <snip> >> My exaggeration was mostly based on my recollection of his early >> discussions in this group, in which it did seem very much (to me, at >> least) as if he was genuinely asking for advice and then setting out to >> do the precise opposite to the advice he was given. > > That, I didn't notice - could you give an example? Not without digging into Google Groups, and I simply don't care enough to go to that much trouble over such a minor point. -- 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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-09-29 07:04 -0400 |
| Message-ID | <mudr4c$dg4$1@dont-email.me> |
| In reply to | #71404 |
On 09/28/2015 07:16 PM, Morten W. Petersen wrote: > On 28.09.2015 16:55, Richard Heathfield wrote: >> On 28/09/15 15:40, Eric Sosman wrote: >>> On 9/28/2015 10:36 AM, James Kuyper wrote: >> <snip> >>>> >>>> Consider, for instance if the header file contained: >>>> >>>> #define my_function_prototype int func(int a, intb) >>>> >>>> This strikes me as an awful idea, and a lot of other C experts seem to >>>> agree with me, but Morten seems to like it. >>> >>> 'scuse me for the tardy response, but I was busy vomiting. >>> >>> YUCKKKK! >>> >> >> My dear Eric, that won't do at all! Whilst I can understand your >> strength of feeling, I don't think there's any call to react in anything >> less than a professional manner, such as, for example: >> >> BLEEAAARRGGHHH! >> >> Knowing you to be a consummate professional, I am sure we can now move >> on and leave this behind us. > > Is this supposed to be funny or obnoxious? Eric and Richard both chose to find funny ways of expressing just how bad an idea it is that you've come up with. I suppose you must find that obnoxious, because they didn't bother explaining why it's such a bad idea. But that's because lots of different people (including Richard) have already tried to explain that to you. They didn't feel a need to add anything more to those explanations. Your responses have suggested that you don't accept our arguments why it's such a bad idea, despite the weakness of your counter-arguments. I feel reasonably confident that I can speak for us all in saying that we've found that a bit frustrating. So expressing that frustration by being a bit obnoxious is quite understandable. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-30 00:07 +0200 |
| Message-ID | <muf22t$o5q$1@speranza.aioe.org> |
| In reply to | #71422 |
On 29.09.2015 13:04, James Kuyper wrote: > On 09/28/2015 07:16 PM, Morten W. Petersen wrote: >> On 28.09.2015 16:55, Richard Heathfield wrote: [...] >>> Knowing you to be a consummate professional, I am sure we can now move >>> on and leave this behind us. >> >> Is this supposed to be funny or obnoxious? > > Eric and Richard both chose to find funny ways of expressing just how > bad an idea it is that you've come up with. I suppose you must find that > obnoxious, because they didn't bother explaining why it's such a bad > idea. But that's because lots of different people (including Richard) > have already tried to explain that to you. They didn't feel a need to > add anything more to those explanations. > > Your responses have suggested that you don't accept our arguments why > it's such a bad idea, despite the weakness of your counter-arguments. I > feel reasonably confident that I can speak for us all in saying that > we've found that a bit frustrating. So expressing that frustration by > being a bit obnoxious is quite understandable. To me it comes across as immature and annoying, maybe if I'd been around longer I would've found it funny as well. I get that having the function signature at the function level is easier to read. But given that the header file should be the API reference and most who come in contact with the code will be looking at that, it isn't unreasonable to do it with macros for ease of maintenance. Maybe I'll change my mind later as I've noted your opinions on it, but I don't see any great harm in doing it "my way" now. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-29 18:13 -0700 |
| Message-ID | <ln1tdg4slo.fsf@kst-u.example.com> |
| In reply to | #71450 |
"Morten W. Petersen" <morphex@gmail.com> writes:
[...]
> I get that having the function signature at the function level is
> easier to read. But given that the header file should be the API
> reference and most who come in contact with the code will be looking at
> that, it isn't unreasonable to do it with macros for ease of
> maintenance.
So in the header file, which you say most people will be looking at,
you'll replace each function declaration:
int some_function(char *s, int n);
double another_function(double x, double y);
by a macro definition and a function declaration that refers to it:
#define some_function_SIGNATURE int some_function(char *s, int n)
some_function_SIGNATURE;
#define another_function_SIGNATURE double another_function(double x, double y)
another_function_SIGNATURE;
This adds useless clutter exactly where it causes the most harm.
And on top of that, it makes maintaining the function definition more
difficult because the parameter types and names are no longer visible.
> Maybe I'll change my mind later as I've noted your opinions on it,
> but I don't see any great harm in doing it "my way" now.
As I've said all along, you're free to do whatever you like. I don't
see any *great* harm in your approach, just minor harm and no benefit.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2015-09-29 21:57 -0700 |
| Message-ID | <b89d318d-cfef-421b-9c19-2aa1430c41dd@googlegroups.com> |
| In reply to | #71458 |
On Tuesday, September 29, 2015 at 8:13:41 PM UTC-5, Keith Thompson wrote: > As I've said all along, you're free to do whatever you like. I don't > see any *great* harm in your approach, just minor harm and no benefit. I could see some potential benefit perhaps to doing something similar in cases where a lot of functions need to be assignable to a function pointer type which is only called in a few cases, and where it may be necessary to change the signature of the functions in ways which would affect the call sites but not materially affect the implementations (e.g. adding an extra parameter which existing implementations could simply ignore). If every function that will be assigned to the pointer type uses a macro for its parameter signature, then the signature associated with the function pointer could be changed without having to modify the source text for all the implementations.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-09-30 01:57 -0400 |
| Message-ID | <muftgb$ptf$1@dont-email.me> |
| In reply to | #71450 |
On 09/29/2015 06:07 PM, Morten W. Petersen wrote: > On 29.09.2015 13:04, James Kuyper wrote: ... >> Eric and Richard both chose to find funny ways of expressing just how >> bad an idea it is that you've come up with. I suppose you must find that >> obnoxious, because they didn't bother explaining why it's such a bad >> idea. But that's because lots of different people (including Richard) >> have already tried to explain that to you. They didn't feel a need to >> add anything more to those explanations. >> >> Your responses have suggested that you don't accept our arguments why >> it's such a bad idea, despite the weakness of your counter-arguments. I >> feel reasonably confident that I can speak for us all in saying that >> we've found that a bit frustrating. So expressing that frustration by >> being a bit obnoxious is quite understandable. > > To me it comes across as immature and annoying, maybe if I'd been > around longer I would've found it funny as well. Finding it immature and annoying, rather than funny, is a natural consequence of the fact that you don't seem to understand just how bad an idea it is. Since you think it's a good idea, it's annoying to have people tell you that it's a bad one. There's nothing funny about someone wanting to vomit in response to hearing about something you think is a good idea. Eric didn't bother explaining why your idea is a bad one, and simply expressed an aesthetic judgment - which probably seems more immature to someone like you who doesn't recognize the fact that the arguments that other people had already presented were valid. > I get that having the function signature at the function level is > easier to read. But given that the header file should be the API > reference and most who come in contact with the code will be looking at > that, it isn't unreasonable to do it with macros for ease of > maintenance. Yes, it is unreasonable. The function prototype in the header is the API reference, and is easier to understand if you don't muck it up using macros, as Keith showed in his reply. The macros don't ease maintenance - they make maintenance of the function definition significantly more complicated, by hiding the return type and argument list. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | jadill33@gmail.com |
|---|---|
| Date | 2015-09-30 06:01 -0700 |
| Message-ID | <65e004fb-cefe-44e5-90fd-16959cc47c77@googlegroups.com> |
| In reply to | #71450 |
On Tuesday, September 29, 2015 at 6:07:47 PM UTC-4, Morten W. Petersen wrote: > On 29.09.2015 13:04, James Kuyper wrote: > > On 09/28/2015 07:16 PM, Morten W. Petersen wrote: > >> On 28.09.2015 16:55, Richard Heathfield wrote: > [...] > >>> Knowing you to be a consummate professional, I am sure we can now move > >>> on and leave this behind us. > >> > >> Is this supposed to be funny or obnoxious? > > > > Eric and Richard both chose to find funny ways of expressing just how > > bad an idea it is that you've come up with. I suppose you must find that > > obnoxious, because they didn't bother explaining why it's such a bad > > idea. But that's because lots of different people (including Richard) > > have already tried to explain that to you. They didn't feel a need to > > add anything more to those explanations. > > > > Your responses have suggested that you don't accept our arguments why > > it's such a bad idea, despite the weakness of your counter-arguments. I > > feel reasonably confident that I can speak for us all in saying that > > we've found that a bit frustrating. So expressing that frustration by > > being a bit obnoxious is quite understandable. > > To me it comes across as immature and annoying, maybe if I'd been > around longer I would've found it funny as well. > > I get that having the function signature at the function level is > easier to read. But given that the header file should be the API > reference and most who come in contact with the code will be looking at > that, it isn't unreasonable to do it with macros for ease of > maintenance. > > Maybe I'll change my mind later as I've noted your opinions on it, > but I don't see any great harm in doing it "my way" now. Your maintenance preference will work against you if you start to look into using documentation generating tools like doxygen. Writing the code is the fun part; documentation is the chore and you're not doing yourself a favor by using a style that these tools were not designed for. Best regards, John D.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-30 16:11 +0200 |
| Message-ID | <mugqh8$g45$1@speranza.aioe.org> |
| In reply to | #71478 |
On 30.09.2015 15:01, jadill33@gmail.com wrote: > On Tuesday, September 29, 2015 at 6:07:47 PM UTC-4, Morten W. Petersen wrote: [...] >> I get that having the function signature at the function level is >> easier to read. But given that the header file should be the API >> reference and most who come in contact with the code will be looking at >> that, it isn't unreasonable to do it with macros for ease of >> maintenance. >> >> Maybe I'll change my mind later as I've noted your opinions on it, >> but I don't see any great harm in doing it "my way" now. > > Your maintenance preference will work against you if you start to > look into using documentation generating tools like doxygen. Writing > the code is the fun part; documentation is the chore and you're not > doing yourself a favor by using a style that these tools were not > designed for. Well, writing good documentation is another important part of the project. Coming from the Python world, I'm used to writing and reading code that is easy to comprehend. But there are examples there as well of to put it mildly, over-engineering. In my early days I guess I got lost in my own little elitist and tunnel- visioned programming world, but these days I know that a lot of people are practical and will simply say "f*** it" if something isn't easy to make use of. So good documentation is important, as are simple examples that demonstrate the use of the library. Of course there are those who prefer to generate documentation using given tools that are based on common coding practices but one can't please everyone. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-30 14:12 +0100 |
| Message-ID | <mugn0v$i73$1@dont-email.me> |
| In reply to | #71450 |
On 29/09/2015 23:07, Morten W. Petersen wrote:
> On 29.09.2015 13:04, James Kuyper wrote:
>> Your responses have suggested that you don't accept our arguments why
>> it's such a bad idea, despite the weakness of your counter-arguments. I
>> feel reasonably confident that I can speak for us all in saying that
>> we've found that a bit frustrating. So expressing that frustration by
>> being a bit obnoxious is quite understandable.
>
> To me it comes across as immature and annoying, maybe if I'd been
> around longer I would've found it funny as well.
>
> I get that having the function signature at the function level is
> easier to read. But given that the header file should be the API
> reference and most who come in contact with the code will be looking at
> that, it isn't unreasonable to do it with macros for ease of
> maintenance.
I actually thought it was quite a clever idea. Just unorthodox.
But there /are/ problems in using the header declarations as
user-documention. First, look at these examples:
typedef int myint;
int testfn(int a, int b);
int testfn(int a, int b);
int testfn(myint a, int b);
int testfn(int a, myint b);
(These multiple declarations of the same function all in the same C
module are legal in C). The compiler will check that the types all match
up. For this purpose, the 'myint' type is treated just like 'int'. This
is the first problem that can happen when multiple declarations have to
be maintained manually.
Now this is an actual definition (you're only allowed one at a time of
these in a module):
int testfn(int b, int a) {return 0;}
Notice the parameter names have been switched; the compiler will *not*
report mismatches in parameter names. So if you decide to change the
order in the definition, or just the names (and the interface)
completelt, and forget changing the header, that will not be picked up
provided the types still match.
That's the second problem, if relying on the header as an API and have
it maintained by hand.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-30 16:15 +0200 |
| Message-ID | <mugqou$giv$1@speranza.aioe.org> |
| In reply to | #71480 |
On 30.09.2015 15:12, Bartc wrote:
> On 29/09/2015 23:07, Morten W. Petersen wrote:
[...]
>> I get that having the function signature at the function level is
>> easier to read. But given that the header file should be the API
>> reference and most who come in contact with the code will be looking at
>> that, it isn't unreasonable to do it with macros for ease of
>> maintenance.
>
> I actually thought it was quite a clever idea. Just unorthodox.
>
> But there /are/ problems in using the header declarations as
> user-documention. First, look at these examples:
>
> typedef int myint;
>
> int testfn(int a, int b);
> int testfn(int a, int b);
> int testfn(myint a, int b);
> int testfn(int a, myint b);
>
> (These multiple declarations of the same function all in the same C
> module are legal in C). The compiler will check that the types all match
> up. For this purpose, the 'myint' type is treated just like 'int'. This
> is the first problem that can happen when multiple declarations have to
> be maintained manually.
>
> Now this is an actual definition (you're only allowed one at a time of
> these in a module):
>
> int testfn(int b, int a) {return 0;}
>
> Notice the parameter names have been switched; the compiler will *not*
> report mismatches in parameter names. So if you decide to change the
> order in the definition, or just the names (and the interface)
> completelt, and forget changing the header, that will not be picked up
> provided the types still match.
Hm, that's interesting and yes surely could be a source of bugs.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-09-30 08:40 -0700 |
| Message-ID | <raun0bhmkkt2njo931oot1rk8fb6l20v38@4ax.com> |
| In reply to | #71450 |
On Wed, 30 Sep 2015 00:07:41 +0200, "Morten W. Petersen"
<morphex@gmail.com> wrote:
>I get that having the function signature at the function level is
>easier to read. But given that the header file should be the API
>reference and most who come in contact with the code will be looking at
>that, it isn't unreasonable to do it with macros for ease of
>maintenance.
Your fetish for macros is a false economy. You disdain writing your
function declarations in a header, where everyone who might use your
library expects them to be and you don't like having to maintain the
header if a definition changes but you give up the capability of
letting the compiler cross-check your code which increases the
likelihood of introducing undetected errors into your code.
Then you write this kind of nonsense:
int main() {
unsigned int test_basics, test_whitespace, test_attribute,
test_miscellaneous, test_compare, test_search,
test_slice_and_length, rat,
test_parse_file;
rat = 1; /* Run All Tests */
test_basics = rat; test_whitespace = rat; test_attribute = rat;
test_miscellaneous = rat; test_compare = rat; test_search = rat;
test_slice_and_length = rat;
test_parse_file = rat;
...
When you should have written:
int main(void)
{
/* select the tests */
int test_basics = 1;
int test_whitespace = 1;
int test_attribute = 1;
int test_miscellaneous = 1;
int test_compare = 1;
int test_search = 1;
int test_slice_and_length = 1;
int test_parse_file = 1;
...
You need to get down to basic C and stop all this fiddling with macros
and learn to use the library functions and tools as they were designed
to be used. Then all the surprises and difficulty in understanding
will disappear.
You can start by creating your header, declaring your functions and
then check error returns from malloc and family:
struct xml_element* create_xml_element() {
struct xml_element* my_struct =
(struct xml_element*)malloc(sizeof(struct xml_element));
if (my_struct)
{
my_struct->type = 0; /* 0 means initialized, 3 means complete
*/
my_struct->next = NULL;
my_struct->parent = NULL;
my_struct->previous = NULL;
my_struct->name = NULL;
my_struct->attributes = NULL;
my_struct->child = NULL;
}
return my_struct;
}
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2015-09-30 22:28 +0200 |
| Message-ID | <p6ho0bd1mie6pivfl41ddl09npua4316qg@4ax.com> |
| In reply to | #71369 |
On Mon, 28 Sep 2015 10:36:47 -0400, James Kuyper
<jameskuyper@verizon.net> wrote:
>On 09/28/2015 09:52 AM, Eric Sosman wrote:
>> On 9/27/2015 6:33 PM, Morten W. Petersen wrote:
>...
>>> This header file, could I define the function prototypes there,
>>> and then simply make use of those prototypes later, doing something
>>> like
>>>
>>> __inline__ my_function_prototype { return a+b; }
>>>
>>> ?
>>
>> I'm not sure what you mean by "like." The line you've shown
>> is a mystery to me: It's not a function declaration, nor a function
>> definition, nor anything else I can readily comprehend.
and so for to see what that "my_function_prototype" return i have to
search where?
---------
i would like to answer too the one says that write down one function
is not the problem but it is the comment to that function...
it is wrong... a good function remain good even if has 0 comment
>Consider, for instance if the header file contained:
>
>#define my_function_prototype int func(int a, intb)
>
>This strikes me as an awful idea, and a lot of other C experts seem to
>agree with me, but Morten seems to like it.
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2015-09-30 22:31 +0200 |
| Message-ID | <miho0b9f71kloj23c8m1db9f3i38v3oilb@4ax.com> |
| In reply to | #71501 |
On Wed, 30 Sep 2015 22:28:01 +0200, Rosario19 wrote: >i would like to answer too the one says that write down one function >is not the problem but it is the comment to that function... > >it is wrong... a good function remain good even if has 0 comment the problem, the difficult, the hard part, it is always write one good function the comment is optional
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-09-30 16:53 -0400 |
| Message-ID | <muhi12$7el$1@dont-email.me> |
| In reply to | #71501 |
On 9/30/2015 4:28 PM, Rosario19 wrote:
> On Mon, 28 Sep 2015 10:36:47 -0400, James Kuyper
> <jameskuyper@verizon.net> wrote:
>
>> On 09/28/2015 09:52 AM, Eric Sosman wrote:
>>> On 9/27/2015 6:33 PM, Morten W. Petersen wrote:
>> ...
>>>> This header file, could I define the function prototypes there,
>>>> and then simply make use of those prototypes later, doing something
>>>> like
>>>>
>>>> __inline__ my_function_prototype { return a+b; }
>>>>
>>>> ?
>>>
>>> I'm not sure what you mean by "like." The line you've shown
>>> is a mystery to me: It's not a function declaration, nor a function
>>> definition, nor anything else I can readily comprehend.
>
> and so for to see what that "my_function_prototype" return i have to
> search where?
It was explained a few days ago that Morten W. Petersen
proposed to #define the entire function signature as a macro
in the header file:
// header.h
#define my_function_prototype int func(int a, int b)
my_function_prototype;
// source.c
#include "header.h"
my_function_prototype { return a + b; }
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.
> i would like to answer too the one says that write down one function
> is not the problem but it is the comment to that function...
>
> it is wrong... a good function remain good even if has 0 comment
Aside from Very Simple Functions, a function that is "good" with no
comment would likely be "better" if it had one. Even a VSF can often
be improved by a comment:
int func(const void *p, const void *q) {
const struct foo *u = p, *v = q;
return (u->key < v->key) - (u->key > v->key);
}
It's pretty clear that this function is intended to be used as a
comparator for qsort() or bsearch() or similar, but did the author
really intend to sort in reverse, or is that a bug? (For a "good"
and hence "bug-free" function it must have been the former, but
somebody reading the code is seldom given a priori knowledge of
"goodness" and hence must ask the question.) Attach either of
/** Compares two struct foo's in natural order. */
or
/** Compares two struct foo's in reverse order. */
... and you've made the code-reader's life easier, thereby improving
the function.
There are two audiences for program source code: Computers and
people. The latter are the more important.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2015-09-30 23:19 +0200 |
| Message-ID | <a6ko0bl5vog5rfslf4bbvkbdn9vektvc9k@4ax.com> |
| In reply to | #71504 |
On Wed, 30 Sep 2015 16:53:42 -0400, Eric Sosman wrote:
>On 9/30/2015 4:28 PM, Rosario19 wrote:
>> On Mon, 28 Sep 2015 10:36:47 -0400, James Kuyper
>> <jameskuyper@verizon.net> wrote:
>>
>>> On 09/28/2015 09:52 AM, Eric Sosman wrote:
>>>> On 9/27/2015 6:33 PM, Morten W. Petersen wrote:
>>> ...
>>>>> This header file, could I define the function prototypes there,
>>>>> and then simply make use of those prototypes later, doing something
>>>>> like
>>>>>
>>>>> __inline__ my_function_prototype { return a+b; }
>>>>>
>>>>> ?
>>>>
>>>> I'm not sure what you mean by "like." The line you've shown
>>>> is a mystery to me: It's not a function declaration, nor a function
>>>> definition, nor anything else I can readily comprehend.
>>
>> and so for to see what that "my_function_prototype" return i have to
>> search where?
>
> It was explained a few days ago that Morten W. Petersen
>proposed to #define the entire function signature as a macro
>in the header file:
>
> // header.h
> #define my_function_prototype int func(int a, int b)
> my_function_prototype;
>
> // source.c
> #include "header.h"
> my_function_prototype { return a + b; }
>
>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.
>
>> i would like to answer too the one says that write down one function
>> is not the problem but it is the comment to that function...
>>
>> it is wrong... a good function remain good even if has 0 comment
>
> Aside from Very Simple Functions, a function that is "good" with no
>comment would likely be "better" if it had one. Even a VSF can often
>be improved by a comment:
>
> int func(const void *p, const void *q) {
> const struct foo *u = p, *v = q;
> return (u->key < v->key) - (u->key > v->key);
> }
>It's pretty clear that this function is intended to be used as a
>comparator for qsort() or bsearch() or similar, but did the author
>really intend to sort in reverse, or is that a bug? (For a "good"
>and hence "bug-free" function it must have been the former, but
>somebody reading the code is seldom given a priori knowledge of
>"goodness" and hence must ask the question.) Attach either of
>
> /** Compares two struct foo's in natural order. */
>or
> /** Compares two struct foo's in reverse order. */
>
>... and you've made the code-reader's life easier, thereby improving
>the function.
>
> 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
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2015-09-30 23:32 +0200 |
| Message-ID | <bnko0bdhep8nguo924nd4mj78o1hvuvlfs@4ax.com> |
| In reply to | #71505 |
On Wed, 30 Sep 2015 23:19:36 +0200, Rosario19 wrote:
>On Wed, 30 Sep 2015 16:53:42 -0400, Eric Sosman wrote:
>>On 9/30/2015 4:28 PM, Rosario19 wrote:
>>> On Mon, 28 Sep 2015 10:36:47 -0400, James Kuyper
>>> <jameskuyper@verizon.net> wrote:
>>>
>>>> On 09/28/2015 09:52 AM, Eric Sosman wrote:
>>>>> On 9/27/2015 6:33 PM, Morten W. Petersen wrote:
>>>> ...
>>>>>> This header file, could I define the function prototypes there,
>>>>>> and then simply make use of those prototypes later, doing something
>>>>>> like
>>>>>>
>>>>>> __inline__ my_function_prototype { return a+b; }
>>>>>>
>>>>>> ?
>>>>>
>>>>> I'm not sure what you mean by "like." The line you've shown
>>>>> is a mystery to me: It's not a function declaration, nor a function
>>>>> definition, nor anything else I can readily comprehend.
>>>
>>> and so for to see what that "my_function_prototype" return i have to
>>> search where?
>>
>> It was explained a few days ago that Morten W. Petersen
>>proposed to #define the entire function signature as a macro
>>in the header file:
>>
>> // header.h
>> #define my_function_prototype int func(int a, int b)
>> my_function_prototype;
>>
>> // source.c
>> #include "header.h"
>> my_function_prototype { return a + b; }
>>
>>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.
>>
>>> i would like to answer too the one says that write down one function
>>> is not the problem but it is the comment to that function...
>>>
>>> it is wrong... a good function remain good even if has 0 comment
>>
>> Aside from Very Simple Functions, a function that is "good" with no
>>comment would likely be "better" if it had one. Even a VSF can often
>>be improved by a comment:
>>
>> int func(const void *p, const void *q) {
>> const struct foo *u = p, *v = q;
>> return (u->key < v->key) - (u->key > v->key);
>> }
>>It's pretty clear that this function is intended to be used as a
>>comparator for qsort() or bsearch() or similar, but did the author
>>really intend to sort in reverse, or is that a bug? (For a "good"
>>and hence "bug-free" function it must have been the former, but
>>somebody reading the code is seldom given a priori knowledge of
>>"goodness" and hence must ask the question.) Attach either of
>>
>> /** Compares two struct foo's in natural order. */
>>or
>> /** Compares two struct foo's in reverse order. */
>>
>>... and you've made the code-reader's life easier, thereby improving
>>the function.
that info should be in its name:
int cmpReverse(const void *p, const void *q)
{const struct foo *u = p, *v = q;
return (u->key < v->key) - (u->key > v->key);
}
this return 0 if u->key==v->key
1 if u->key<v->key
-1 if u->key>v->key
i don't know if its name is right
>> 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
[toc] | [prev] | [next] | [standalone]
Page 14 of 17 — ← Prev page 1 … 12 13 [14] 15 16 17 Next page →
Back to top | Article view | comp.lang.c
csiph-web