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 13 of 17 — ← Prev page 1 … 11 12 [13] 14 15 … 17 Next page →
| From | jadill33@gmail.com |
|---|---|
| Date | 2015-10-02 09:18 -0700 |
| Message-ID | <202f6f2f-e1de-4207-a779-acc13faa71d7@googlegroups.com> |
| In reply to | #71609 |
On Friday, October 2, 2015 at 9:56:28 AM UTC-4, gwowen wrote: > Richard Heathfield <r...@cpax.org.uk> writes: > > > > > yy[^W]Wp[ESC]A;[ESC] > > That's a weird way to spell > C-SPCC-eM-wC-xb[RET]C-y; > > > All the more reason to use a good editor. > > Quite. Use a keyboard macro (or whatever the vi equiv is), and you can > reduce it to a single key-press, or do multiple prototypes at once. > A language aware editor with the equivalent of M-x forward-sexp is > particularly useful in this regard. vi macros q<letter>yy[^W]Wp[ESC]A;[ESC]q if <letter> is 'a' (or 'b', 'c', etc.) qayy[^W]Wp[ESC]A;[ESC]q then '@a' to repeat, or 100@a to repeat 100 times. '@@' repeats that last invoked macro. There is usually some movement or /search/ commands to set up the next block edit. It's invaluable for large boilerplate code refactoring. And one can add :wn in the middle of your macro sequence to edit a list of open files to apply the same change. I'm sure the other editor which shall not be named has the same capability. Best regards, John D.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2015-10-02 20:14 +0100 |
| Message-ID | <87612pm6av.fsf@gmail.com> |
| In reply to | #71619 |
jadill33@gmail.com writes: > It's invaluable for large boilerplate code refactoring. And one can > add :wn in the middle of your macro sequence to edit a list of open > files to apply the same change. I'm sure the other editor which shall > not be named has the same capability. Well, if it didn't you could always put it in beep^H^H^H^H VI mode using M-x vi-mode (It does, of course)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-02 10:20 -0700 |
| Message-ID | <lnpp0x192l.fsf@kst-u.example.com> |
| In reply to | #71592 |
raltbos@xs4all.nl (Richard Bos) writes:
[...]
> I never manually write a prototype. I write a full function declaration
> as part of the definition, and then copy-and-paste it into either the
> list at the top of the file, or the header file. That way, at least I
> know I've misspelt it the same way both times.
A terminology quibble: A full function definition *includes* a
declaration of that function (normally that declaration will be a
prototype). A "prototype" is defined as a function declaration that
specifies the types of the parameters.
--
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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-04 14:03 +0000 |
| Message-ID | <5611317d.1462546@news.xs4all.nl> |
| In reply to | #71627 |
Keith Thompson <kst-u@mib.org> wrote: > raltbos@xs4all.nl (Richard Bos) writes: > [...] > > I never manually write a prototype. I write a full function declaration > > as part of the definition, and then copy-and-paste it into either the > > list at the top of the file, or the header file. That way, at least I > > know I've misspelt it the same way both times. > > A terminology quibble: A full function definition *includes* a > declaration of that function (normally that declaration will be a > prototype). A "prototype" is defined as a function declaration that > specifies the types of the parameters. You are, of course, right. I never manually write a _separate_ prototype; I write the one in the function definition, and copy the separate one. Richard
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-01 09:28 -0700 |
| Message-ID | <lnbnci365d.fsf@kst-u.example.com> |
| In reply to | #71536 |
ais523 <ais523@nethack4.org> writes:
[...]
> Having to write each prototype twice (once in the declaration and once
> in the definition) is something that annoys me too, but I agree with the
> prevailing comp.lang.c opinion that using a macro for it (and thus
> making the names of the argument unclear from the definition) is unwise.
>
> However, I've had some thoughts about removing the duplication the other
> way instead. The idea would be to look at a source file, and
> automatically extract prototypes from all the function definitions
> (tools that do this already exist, although IIRC they're mostly dying
> out because they were mostly used to convert between prototype-based
> and K&R C, and K&R C is mostly dead). Then the tool would write a header
> file containing all the declarations.
[...]
It's an interesting idea, and it probably already exists in some
form, but I'm not convinced that it would be worthwhile (at least
for me).
When I create a pair of .h/.c files (or, in my recent work,
.h/.cpp, but the same principles apply), I typically start
with the .h file, then copy it to the .cpp file, then expand the
declarations to definitions. If I need to update something (which
is inevitable), I typically edit both files, make the changes
in one, and copy-and-paste into the other. (I use vim, but any
decent editor should make it to switch quickly between two files,
copying from one and pasting into the other.)
Having to copy-and-paste, and maintain the same lines of code in two
different files, is mildly annoying, but for me that's outweighed
by the advantage of having the *information* clearly visible in
both places.
If I were using development tools that actually required me to
manually type the declaration twice, I'd be interested in an
automated tool, but a little copy-and-pasting is easy.
--
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 | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2015-10-01 18:53 +0200 |
| Message-ID | <jooq0b5gtkmgfg907obc3qlgn0gtp9enmb@4ax.com> |
| In reply to | #71536 |
On Thu, 1 Oct 2015 14:05:45 +0000 (UTC), ais523 wrote: >Keith Thompson wrote: >> "Morten W. Petersen" <morphex@gmail.com> writes: >>> On 28.09.2015 02:09, Keith Thompson wrote: >>>> Your "my_func_SIGNATURE" just makes your code more difficult to read. >>>> Every time I see it, I have to track down its definition to understand >>>> what it means. >>> >>> Well it does make it clear what's going on with a capital SIGNATURE, >>> tracking it down doesn't seem like a big deal. >>> >>> It's a trade-off for maintainability and I'll be using it when >>> prototypes are added. >> >> You can, of course, do whatever you like. >> >> But a number of people with more C experience than you have are >> telling you that your suggested approach causes more problems than >> it solves. >> >> It's a clever idea, and it's perfectly reasonable to *think* that >> it's a good one. It lets you write certain information only once, >> whereas the conventional approach requires you to duplicate the >> same information in two separate source files (the .h and the >> corresponding .c). >> >> But what we're trying to tell you, based on a great deal of >> experience, is that writing the declaration twice *works*. >> The initial work of writing it is trivial; just copy-and-paste. >> If the declaration and definition get out of sync, the compiler >> will flag the error for you. >> >> You'll commonly have several declarations in a .h file, with matching >> definitions in the corresponding .c file. With your approach, >> that means you'll have multiple macros, one for each function. >> And the parameter names and types *won't be visible* when you're >> editing the function definition. That may be the biggest problem >> with your approach. >> >> And your macro name "my_func_SIGNATURE" isn't much shorter than >> the actual declaration "int my_func(int a, int b)". >> >> Finally, if you look at existing C code, you'll find few if any >> examples that use this approach. There are reasons for that. > >Having to write each prototype twice (once in the declaration and once >in the definition) is something that annoys me too, but I agree with the >prevailing comp.lang.c opinion that using a macro for it (and thus >making the names of the argument unclear from the definition) is unwise. > >However, I've had some thoughts about removing the duplication the other >way instead. The idea would be to look at a source file, and >automatically extract prototypes from all the function definitions >(tools that do this already exist, although IIRC they're mostly dying >out because they were mostly used to convert between prototype-based >and K&R C, and K&R C is mostly dead). Then the tool would write a header >file containing all the declarations. > >The end result would be that the files you use as input would use the >normal style for C source files (definitions in the file itself with >prototypes, no extern declarations in the file itself, but with the >extern definitions included via a header file), but that instead of the >header files being entirely written by hand, the portions of the header >files that specified declarations would be automatically generated. > >Does anyone know of a build system that works like this? Would such a >thing be useful? Are there any big reasons to avoid this sort of system? >(I'm vaguely minded to work on something like this myself.) my way i find confortable is put all in a .dll and choose name for function and costant not so little in lenght... so one can have one dll for asm one for C and C++ one for java etc [is possible call one language I function from a language II program for example asm function in a asm .dll from a C or C++ program, using one function that assign one pointer to function to each function has the .asm dll at start of the executable] when one new function has to born i put that in a separate file and include the maxi header that has all function class etc declaration where there are all function in language i have... debug it and when it is ok add it to the .dll for the right language etc
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2015-10-02 06:26 +0200 |
| Message-ID | <okvr0bpgdl0krmnjg4r0jt8nfike3l5dro@4ax.com> |
| In reply to | #71551 |
On Thu, 01 Oct 2015 18:53:20 +0200, Rosario19 wrote:
>[is possible call one language I function from a language II program
>for example
>asm function in a asm .dll from a C or C++ program, using one function
>that assign one pointer to function to each function has the .asm dll
>at start of the executable]
if i remember well here
the C/C++ executable is compiled as:
bcc32 executable.cpp Cppdll.lib
in the C/C++ executable there is one
int main(void)
{
// loadDll() one Cpp dll function
// load asm dll, assign C++ pointers to function
// to many function in asm dll
// so include the .h where there are all these function
// pointer export these pointers from .dll
// so i can call here these function truh Cppdll.lib
// allocate memory and some varibles for that dll
if(loadDll()==0) R 0;
// variable global for debug memory from malloc
// if this variable is 1
// each call to free() and malloc() function check
// *all* memory bound to all vector of char
// returned from malloc
// for search some out of bound write
// if this variable is 0 than free() serach error
// in the bound of the vectror char has to free only
debugP=1;
//one varible show statistic in the end of the program
statistic=1;
//than the call of some function for precision of cout
//and for big float number
...
r=main24() // the usual main() for call
freeDll(); // free all resources and check
R r;
}
but in this way from the Cpp dll i can load for example
one pascal Dll etc and use their function in the
C++ executable
[toc] | [prev] | [next] | [standalone]
| From | Roberto Waltman <usenet@rwaltman.com> |
|---|---|
| Date | 2015-10-01 13:40 -0400 |
| Subject | Generating header files (Was: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <9qrq0bd0o78069ni2pvpifmsrpskrieam3@4ax.com> |
| In reply to | #71536 |
ais523 wrote: >... >The end result would be that the files you use as input would use the >normal style for C source files (definitions in the file itself with >prototypes, no extern declarations in the file itself, but with the >extern definitions included via a header file), but that instead of the >header files being entirely written by hand, the portions of the header >files that specified declarations would be automatically generated. > >Does anyone know of a build system that works like this? Would such a >thing be useful? Are there any big reasons to avoid this sort of system? >(I'm vaguely minded to work on something like this myself.) Not exactly as desired, but good starting points: http://invisible-island.net/cproto/cproto.html http://www.hwaci.com/sw/mkhdr/ http://fossil-scm.org/xfer/doc/trunk/src/makeheaders.html http://techtinkering.com/2013/02/12/using-dynamically-generated-header-files-with-cmake/ R.W.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-10-01 23:58 +0200 |
| Subject | Re: Generating header files (Was: Unexpected and difficult to understand SIGSEGV) |
| Message-ID | <muka8v$o42$1@speranza.aioe.org> |
| In reply to | #71552 |
On 01.10.2015 19:40, Roberto Waltman wrote: > ais523 wrote: > >> ... >> The end result would be that the files you use as input would use the >> normal style for C source files (definitions in the file itself with >> prototypes, no extern declarations in the file itself, but with the >> extern definitions included via a header file), but that instead of the >> header files being entirely written by hand, the portions of the header >> files that specified declarations would be automatically generated. >> >> Does anyone know of a build system that works like this? Would such a >> thing be useful? Are there any big reasons to avoid this sort of system? >> (I'm vaguely minded to work on something like this myself.) > > Not exactly as desired, but good starting points: > > http://invisible-island.net/cproto/cproto.html > http://www.hwaci.com/sw/mkhdr/ > http://fossil-scm.org/xfer/doc/trunk/src/makeheaders.html > http://techtinkering.com/2013/02/12/using-dynamically-generated-header-files-with-cmake/ The makeheaders project does part of what we've been discussing, but it doesn't format well or include comments/documentation. I'm thinking a C parser that can feed some other program with function definitions and related comments could be a good way to go about it, so that the parser part doesn't have to be built from scratch. And maybe constants etc. as well. And maybe have a switch for including extern variables, or switches for each separate class of function/variable? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-04 14:06 -0700 |
| Message-ID | <kfnd1wu8hsh.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71536 |
ais523 <ais523@nethack4.org> writes: > [..how to deal with function declarations..] > > However, I've had some thoughts about removing the duplication the > other way instead. The idea would be to look at a source file, > and automatically extract prototypes from all the function > definitions (tools that do this already exist, although IIRC > they're mostly dying out because they were mostly used to convert > between prototype-based and K&R C, and K&R C is mostly dead). > Then the tool would write a header file containing all the > declarations. > > The end result would be that the files you use as input would use > the normal style for C source files (definitions in the file > itself with prototypes, no extern declarations in the file itself, > but with the extern definitions included via a header file), but > that instead of the header files being entirely written by hand, > the portions of the header files that specified declarations would > be automatically generated. > > Does anyone know of a build system that works like this? Would > such a thing be useful? Are there any big reasons to avoid this > sort of system? (I'm vaguely minded to work on something like > this myself.) I have used such a system for more than ten years. My experience in that environment is that it gives C program development an extremely different feel, almost like it's a different language. I find it enormously helpful.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-09-27 21:05 -0400 |
| Message-ID | <mua3kk$2dg$1@dont-email.me> |
| In reply to | #71308 |
On 09/27/2015 06:33 PM, Morten W. Petersen wrote:
> On 28.09.2015 00:23, Eric Sosman wrote:
>> On 9/27/2015 5:33 PM, Morten W. Petersen wrote:
>>> On 27.09.2015 23:01, James Kuyper wrote:
>>>>
>>>> [...]Using a header allows
>>>> you to make changes in only two places: the header itself, and the
>>>> translation unit where the object or function is identified. Laziness
>>>> should be impelling you to use headers, not to avoid them.
> [...]
>>> And functions defined in decode_xml.c are called in tests.c,
>>> and the resulting executable decode_xml does the right thing.
>>
>> "It happened to do the right thing" is a far cry from "It's
>> right" or "It's damage-resistant."
>>
>>> Are you saying I should add a header file for functions defined
>>> in decode_xml.c at this point, to save myself from extra work?
>>
>> I believe that's what he's saying. It's what I'd say, too.
>
> OK. Since there are error checking benefits that otherwise don't
> come into play, I agree, function prototypes should be used.
>
> I was thinking along the lines of keeping things simple so that
> I wouldn't have to update the same thing in different places which
> could create something to trip in if one forgot the other place(s).
Yes, that's a very good reason to favor putting function prototypes for
functions with external linkage in separate header files. Then the only
places you have to update are the header file and the definition of the
function, rather than having to update every file where the function is
used. There's an added bonus: if you forget to update one of the two
places when you make a change, you'll get a diagnostic message reminding
you of your mistake.
> 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; }
Special care needs to be taken with inline functions, which I could
provide advice about, if you weren't using C90. I would expect that
similar issues probably apply to __inline__ functions, but I can't
provide any advice about that.
> ?
>
> I was thinking the header file could basically be the API description
> and the only place the function signature was located..
That is in fact what you should be doing.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-29 10:26 +0200 |
| Message-ID | <mudhsh$cp6$1@dont-email.me> |
| In reply to | #71338 |
On 28/09/15 03:05, James Kuyper wrote: > On 09/27/2015 06:33 PM, Morten W. Petersen wrote: >> On 28.09.2015 00:23, Eric Sosman wrote: >>> On 9/27/2015 5:33 PM, Morten W. Petersen wrote: >>>> On 27.09.2015 23:01, James Kuyper wrote: >>>>> >>>>> [...]Using a header allows >>>>> you to make changes in only two places: the header itself, and the >>>>> translation unit where the object or function is identified. Laziness >>>>> should be impelling you to use headers, not to avoid them. >> [...] >>>> And functions defined in decode_xml.c are called in tests.c, >>>> and the resulting executable decode_xml does the right thing. >>> >>> "It happened to do the right thing" is a far cry from "It's >>> right" or "It's damage-resistant." >>> >>>> Are you saying I should add a header file for functions defined >>>> in decode_xml.c at this point, to save myself from extra work? >>> >>> I believe that's what he's saying. It's what I'd say, too. >> >> OK. Since there are error checking benefits that otherwise don't >> come into play, I agree, function prototypes should be used. >> >> I was thinking along the lines of keeping things simple so that >> I wouldn't have to update the same thing in different places which >> could create something to trip in if one forgot the other place(s). > > Yes, that's a very good reason to favor putting function prototypes for > functions with external linkage in separate header files. Then the only > places you have to update are the header file and the definition of the > function, rather than having to update every file where the function is > used. There's an added bonus: if you forget to update one of the two > places when you make a change, you'll get a diagnostic message reminding > you of your mistake. > My standard is that a function in a file "unit.c" is either declared static, or it has a matching "extern" prototype in "unit.h". (The same applies to variables.) Some gcc warnings (in addition to -Wall) help enforce this rule: -Wredundant-decls -Wnested-externs -Wmissing-declarations (for C++) -Wmissing-prototypes (for C)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-09-27 21:15 -0400 |
| Message-ID | <mua489$44g$1@dont-email.me> |
| In reply to | #71308 |
On 09/27/2015 06: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; }
Sorry - I didn't realize what that you were proposing to define your
function prototypes *as macros* until I read other people's responses. I
should have realized it if I'd read the above function definition more
clearly. This is a bad idea. If there's one place where the names and
types of your function's arguments and the type of its return value
should be clearly and directly visible, it's in the definition of the
function. Hiding them in a macro defined in a separate header file will
make it harder to write your functions correctly, and harder to debug
them when something goes wrong.
Duplicating the function prototype in the definition and in a separate
header file is simple, easy, and well worth the cost compared to this
approach. And so long as you #include the header file into the same
translation unit as the definition of the function, you'll be immediate
reminded of any failure to keep them compatible, the next time you try
to compile your code.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-09-28 09:52 -0400 |
| Message-ID | <mubgj7$f1e$1@dont-email.me> |
| In reply to | #71308 |
On 9/27/2015 6:33 PM, Morten W. Petersen wrote:
> [...]
> I was thinking along the lines of keeping things simple so that
> I wouldn't have to update the same thing in different places which
> could create something to trip in if one forgot the other place(s).
If the declaration is in a header, the number of places you need
to change is two: The header, and the .c file containing the definition.
If the function is defined in one file and used in N other files
that have their own free-standing declarations, the number of places
you need to change is N+1. Using the header is a win if N>1.
... and although it's only a break-even if N==1, there's a gain
in safety: Since you #include the same header in both the file that
uses the function and the file that defines it, the compiler will be
able to spot a mismatch that would elude it if the user's declaration
were free-standing and hadn't kept up.
If N==0 (the function is used only in the same file that defines
it) and if you can position the definition prior to the first use
(so you need no forward declaration), you can do without the header
altogether. Make the function `static' because it's "private" to
just the one file.
> 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.
> I was thinking the header file could basically be the API description
> and the only place the function signature was located..
Yes to the first part, but No to the second. The function
definition must specify the "signature," even if that signature
has already been declared elsewhere. Note that a function
defined as
#include <math.h>
int func(int count, double ratio) {
return 1.0 - pow(1.0 - ratio, count);
}
could be declared as
int func(int fieldGoalAttempts, double successProbability);
or even as
int func(int, double);
That is, the parameter names in the declaration need not be the
same as those in the definition, and need not even be present at
all: They are "optional documentation." The definition, though,
absolutely needs the parameter names in order to refer to the
parameters within the function body.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-09-28 10:36 -0400 |
| Message-ID | <mubj68$prj$1@dont-email.me> |
| In reply to | #71368 |
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.
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.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-09-28 10:40 -0400 |
| Message-ID | <mubjdc$qto$1@dont-email.me> |
| In reply to | #71369 |
On 9/28/2015 10:36 AM, James Kuyper 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.
>
> 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!
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-09-28 15:55 +0100 |
| Message-ID | <mubk8j$uhr$1@dont-email.me> |
| In reply to | #71370 |
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. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-29 01:16 +0200 |
| Message-ID | <muchn2$1io$1@speranza.aioe.org> |
| In reply to | #71371 |
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? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-09-29 00:26 +0100 |
| Message-ID | <muci7a$qvc$1@dont-email.me> |
| In reply to | #71404 |
On 29/09/15 00:16, 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) >>>> <outrageously selective snip> > > Is this supposed to be funny or obnoxious? Looks like both. -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-29 10:34 +0200 |
| Message-ID | <mudibc$edg$1@dont-email.me> |
| In reply to | #71404 |
On 29/09/15 01:16, 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? > 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. 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. 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.
[toc] | [prev] | [next] | [standalone]
Page 13 of 17 — ← Prev page 1 … 11 12 [13] 14 15 … 17 Next page →
Back to top | Article view | comp.lang.c
csiph-web