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 12 of 17 — ← Prev page 1 … 10 11 [12] 13 14 … 17 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-05 10:38 +1300 |
| Message-ID | <d7dkjiFehaeU2@mid.individual.net> |
| In reply to | #71855 |
Bartc wrote: > On 04/10/2015 21:24, Ian Collins wrote: >> Bartc wrote: >>> >>> Ian Collins might also like to know that his more automated 2-keystroke >>> macro to do the job might not be as reliable as your method. >> >> Which macro would that be? > > You said this: > > > An reasonable editor or IDE can do the mechanical refactoring of the > > function declaration and definition in a couple of keystrokes and/or > > mouse clicks. Updating the function's callers is another story. > > Since it is impossible to do what is necessary in just two keystrokes, > it must invoke some sort of command or macro to do the job. (I didn't > mean a C macro.) I was hoping you would pick up on the significance of the last sentence in my quote. Changing a function declaration/definition pair is a trivial mechanical task, well suited to either a tool or a person. This change will only take a small number of seconds either way. What will take time is updating the code that calls the function. This isn't something a machine can easily do. Yes my IDE will find all of the uses of the function and add a dummy default for a new parameter, but I still have to go though all these changes and add a meaningful value. If the return type has changed, then there could be even more work to do. So given you're assertion that "I need to add parameters, change a return type, make a static function global, consolidate two functions into one, or vice versa..." you will be sending much longer doing structural changes to you code than updating a prototype. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-04 23:02 +0100 |
| Message-ID | <mus7hf$umd$1@dont-email.me> |
| In reply to | #71860 |
On 04/10/2015 22:38, Ian Collins wrote: > Bartc wrote: >> You said this: >> >> > An reasonable editor or IDE can do the mechanical refactoring of the >> > function declaration and definition in a couple of keystrokes and/or >> > mouse clicks. Updating the function's callers is another story. >> >> Since it is impossible to do what is necessary in just two keystrokes, >> it must invoke some sort of command or macro to do the job. (I didn't >> mean a C macro.) > > I was hoping you would pick up on the significance of the last sentence > in my quote. Changing a function declaration/definition pair is a > trivial mechanical task, well suited to either a tool or a person. This > change will only take a small number of seconds either way. > > What will take time is updating the code that calls the function. This > isn't something a machine can easily do. Yes my IDE will find all of > the uses of the function and add a dummy default for a new parameter, > but I still have to go though all these changes and add a meaningful > value. If the return type has changed, then there could be even more > work to do. > > So given you're assertion that "I need to add parameters, change a > return type, make a static function global, consolidate two functions > into one, or vice versa..." you will be sending much longer doing > structural changes to you code than updating a prototype. There may or may not be changes at various call sites (making a function global for example involves no changes). It's even more important then that the prototype in the header is accurate so that the compiler can pick up any new mismatches where it can. But where changes do need to be made, it's even sillier then to waste time updating the prototypes manually when there is more important work to do. Imagine the C language was such that prototypes were unnecessary, yet full information about functions was always available (like the language I mainly use now). Do you think the committee would vote to add them and generate all this extra work? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-05 11:10 +1300 |
| Message-ID | <d7dmf0FehaeU3@mid.individual.net> |
| In reply to | #71871 |
Bartc wrote: > On 04/10/2015 22:38, Ian Collins wrote: >> Bartc wrote: > >>> You said this: >>> >>> > An reasonable editor or IDE can do the mechanical refactoring of the >>> > function declaration and definition in a couple of keystrokes and/or >>> > mouse clicks. Updating the function's callers is another story. >>> >>> Since it is impossible to do what is necessary in just two keystrokes, >>> it must invoke some sort of command or macro to do the job. (I didn't >>> mean a C macro.) >> >> I was hoping you would pick up on the significance of the last sentence >> in my quote. Changing a function declaration/definition pair is a >> trivial mechanical task, well suited to either a tool or a person. This >> change will only take a small number of seconds either way. >> >> What will take time is updating the code that calls the function. This >> isn't something a machine can easily do. Yes my IDE will find all of >> the uses of the function and add a dummy default for a new parameter, >> but I still have to go though all these changes and add a meaningful >> value. If the return type has changed, then there could be even more >> work to do. >> >> So given you're assertion that "I need to add parameters, change a >> return type, make a static function global, consolidate two functions >> into one, or vice versa..." you will be sending much longer doing >> structural changes to you code than updating a prototype. > > There may or may not be changes at various call sites (making a function > global for example involves no changes). It's even more important then > that the prototype in the header is accurate so that the compiler can > pick up any new mismatches where it can. > > But where changes do need to be made, it's even sillier then to waste > time updating the prototypes manually when there is more important work > to do. Well in my case at least I don't waste any time: I just wiggle my rodent and go Refactor->Change Function Parameters and change everything in one pop. > Imagine the C language was such that prototypes were unnecessary, yet > full information about functions was always available (like the language > I mainly use now). Do you think the committee would vote to add them and > generate all this extra work? Your belief in "all this extra work" is misplaced. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-04 23:51 +0100 |
| Message-ID | <musad8$7t8$1@dont-email.me> |
| In reply to | #71872 |
On 04/10/2015 23:10, Ian Collins wrote: > Bartc wrote: >> But where changes do need to be made, it's even sillier then to waste >> time updating the prototypes manually when there is more important work >> to do. > > Well in my case at least I don't waste any time: I just wiggle my rodent > and go Refactor->Change Function Parameters and change everything in one > pop. > >> Imagine the C language was such that prototypes were unnecessary, yet >> full information about functions was always available (like the language >> I mainly use now). Do you think the committee would vote to add them and >> generate all this extra work? > > Your belief in "all this extra work" is misplaced. Yet, you have a preference for just clicking 'Refactor->Change Function Parameters' instead. I can understand how you don't think it's all that much work when you don't have to do it! People here are using copy and paste and having multiple windows open on source files and headers. You are effectively using the approach I'm advocating. (I don't know know if that mouse click works a function at a time or does the whole lot.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-05 11:56 +1300 |
| Message-ID | <d7dp55FehaeU5@mid.individual.net> |
| In reply to | #71884 |
Bartc wrote: > On 04/10/2015 23:10, Ian Collins wrote: >> Bartc wrote: > >>> But where changes do need to be made, it's even sillier then to waste >>> time updating the prototypes manually when there is more important work >>> to do. >> >> Well in my case at least I don't waste any time: I just wiggle my rodent >> and go Refactor->Change Function Parameters and change everything in one >> pop. >> >>> Imagine the C language was such that prototypes were unnecessary, yet >>> full information about functions was always available (like the language >>> I mainly use now). Do you think the committee would vote to add them and >>> generate all this extra work? >> >> Your belief in "all this extra work" is misplaced. > > Yet, you have a preference for just clicking 'Refactor->Change Function > Parameters' instead. To change them, yes. Creating them would be a cut'n paste. In my case (because of the process I follow) the cut'n paste is from the header to the source file. > I can understand how you don't think it's all that much work when you > don't have to do it! People here are using copy and paste and having > multiple windows open on source files and headers. > > You are effectively using the approach I'm advocating. (I don't know > know if that mouse click works a function at a time or does the whole lot.) In part, yes. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-05 07:38 +1300 |
| Message-ID | <d7da0sFehacU1@mid.individual.net> |
| In reply to | #71825 |
Bartc wrote: > > You work differently then. I need to add parameters, change a return > type, make a static function global, consolidate two functions into one, > or vice versa... Each type the prototype(s), wherever they happen to be, > have to change. In which case, updating the prototype is trivial compared to updating all of the code that supplies the new parameters or uses the changed return type. An reasonable editor or IDE can do the mechanical refactoring of the function declaration and definition in a couple of keystrokes and/or mouse clicks. Updating the function's callers is another story. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-04 23:51 +0200 |
| Message-ID | <mus6tc$pcc$1@dont-email.me> |
| In reply to | #71825 |
On 04/10/15 19:13, Bartc wrote: > On 04/10/2015 17:16, David Brown wrote: >> On 03/10/15 18:37, Bartc wrote: > >>> I suppose if your normal development environment consists of elaborate >>> compilers like gcc, make files, shell scripts, dozens of other utilities >>> each with /their/ own syntax, then small chores such as constantly >>> keeping header files updated from corresponding definitions would seem >>> insignificant. >> >> You have a very warped idea of how other people work. > > Yet, I am expected to have to deal with all that every time I need to > build someone's open source project. No, /you/ expect this to be the case. Most people (including other windows-only users of open source) don't have the issues you manage to create for yourself. Of course, /some/ people like to write shell scripts and work with them. Fans of autotools don't like to make shell scripts - that's why they use autotools to generate the ./config scripts and avoid doing it by hand. > >> My usual >> development process involves a makefile which invokes a few utilities >> (like sed, cp, rm, mkdir - and occasionally python scripts, > >> While gcc is arguably an "elaborate" compiler, the habit of putting >> function prototypes in a header file is hardly gcc-specific. > > No, but having to grapple with a recalcitrant compiler bristling with > options might overshadow the effort of generating up-to-date headers. I can't figure out any sense here. I'll assume it's just more of your rabid prejudice against gcc, which you are using to "justify" your nonsensical claims. > >> And if you need to work constantly in keeping your prototypes up to >> date, then I suggest you have a very poorly structured development >> process - I rarely change the prototypes in a module's header, because I >> am not in the habit of re-arranging a module's API on a regular basis. > > You work differently then. I need to add parameters, change a return > type, make a static function global, consolidate two functions into one, > or vice versa... Each type the prototype(s), wherever they happen to be, > have to change. I will sometimes have to do all of these things. Changing the prototype in the header is not a problem in such cases. > >> Most functions, of course, are static within the implementation - there >> are not prototypes (other than the one at the definition) to synchronise. > > Again that's not my experience. But I also use prototypes for static > functions. Then I need pay no attention to the order that definitions > occur in. Some people like to write these extra prototypes - personally, I don't (except in the very rare cases where they are necessary). But keeping these prototypes in sync is not a hardship either. > >>> But /my/ development environment is nothing like that. Switching from >>> function definition to header file and back again is a damn nuisance >>> when in you're in the middle of a complicated bit of development >>> involving dozens of functions and don't want to break concentration. >> >> Perhaps if you use an editor more sophisticated than Notepad, you will >> find it is not that big a problem. > > Both my editor and IDE are crude, but switching between related projects > is a single keypress. I've designed out the concept of function > prototypes as far as /I'm/ concerned (actually, the concept of header > files too, now), so at least that part of it I don't need to deal with. I am happy that you have a development method that you like, and tools that suit you. Now stop condemning the rest of the C programming world just because you can't imagine that other people are happily and efficiently working in a slightly different way. > >> Any serious editor is quite happy >> with having headers and implementation files open at the same time, and >> visible at the same time > > (Non-serious ones too; you just have multiple instances.) No, that would fail when having multiple editing windows open on the same file. > > - as well as having multiple editing windows >> onto the same file. It should also handle things like navigation >> between headers and source, definitions and prototypes, and bookmarks. > > I'm surprised that all these sophisticated tools you're always talking > about, can't automate the generation of prototype headers without any > manual intervention. Is there anything that a highly competent > developer, whose time is valuable, can add to a function prototype that > an automatic process couldn't? > Being a highly competent developer whose time is valuable, I am quite happy sorting out my prototypes manually. It is an insignificantly small part of my time - and learning and using an automated tool that was sophisticated enough to do the job I would need, assuming such a tool existed, would be more effort than cut-and-paste.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-04 23:44 +0100 |
| Message-ID | <musa17$6n8$1@dont-email.me> |
| In reply to | #71869 |
On 04/10/2015 22:51, David Brown wrote:
> On 04/10/15 19:13, Bartc wrote:
> I am happy that you have a development method that you like, and tools
> that suit you. Now stop condemning the rest of the C programming world
> just because you can't imagine that other people are happily and
> efficiently working in a slightly different way.
This part of a post recently made in this thread:
> ais523 <ais523@nethack4.org> writes:
>> 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.)
On 04/10/2015 22:06, Tim Rentsch wrote:
> 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.
ais523 seems to be asking about a system that works as I am suggesting
(working out prototypes from definitions). Tim Rentsch is saying he's
used such a system and it was helpful. (And this is the guy who can't
see the point of binary literals.)
That's one person who isn't happy with the manual way of doing this
stuff and another who is happy with not having to do it manually.
So it's not just me. There were presumably good reasons for Tim's system
to decide to do it that way.
>> Is there anything that a highly competent
>> developer, whose time is valuable, can add to a function prototype that
>> an automatic process couldn't?
>>
>
> Being a highly competent developer whose time is valuable, I am quite
> happy sorting out my prototypes manually. It is an insignificantly
> small part of my time - and learning and using an automated tool that
> was sophisticated enough to do the job I would need, assuming such a
> tool existed, would be more effort than cut-and-paste.
My projects can end up with thousands of functions. That would be a lot
to maintain by hand!
(If anyone is interested in easy ways of creating their own prototype
generating tool, this is the approach I used a few years ago:
* If the module is called foo.c, then add the line #include "foo.cl" at
the start (it needs to go after any typedefs).
* Wherever the global prototypes have to go, then add the line #include
"foo.cx" in that header. (You can't call it foo.h and use that directly,
as it would normally need exported typedefs, macros etc as well. Those
need to be done by hand - but they don't need duplicating like functions
do.)
* Create these empty macros:
#define function
#define global
* Start all function definitions with "function " (static) or "global
function " (exported). Devise a consistent style for placing the first
"{" and any comment. It is simpler if the function signature is always
on one line.
* Now, it is child's play to write some script that looks for lines
starting with "global function" or "function", and creates a prototype
to be added to foo.cx or foo.cl respectively. The script is run before
normal compiling.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-05 11:52 +1300 |
| Message-ID | <d7dou7FehaeU4@mid.individual.net> |
| In reply to | #71881 |
Bartc wrote: > > * Now, it is child's play to write some script that looks for lines > starting with "global function" or "function", and creates a prototype > to be added to foo.cx or foo.cl respectively. The script is run before > normal compiling.) So you regenerate the header on each compile? Doesn't that muck up incremental builds? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-05 00:09 +0100 |
| Message-ID | <musbet$b16$1@dont-email.me> |
| In reply to | #71885 |
On 04/10/2015 23:52, Ian Collins wrote: > Bartc wrote: >> >> * Now, it is child's play to write some script that looks for lines >> starting with "global function" or "function", and creates a prototype >> to be added to foo.cx or foo.cl respectively. The script is run before >> normal compiling.) > > So you regenerate the header on each compile? As I used it, yes. > Doesn't that muck up incremental builds? My project was too small to have to do incremental builds. Usually I knew which module to compile (the one I'd just edited), and the linking was pretty quick. Every so often I would make an edit that I knew would probably need a global re-compile, but even then it was only a dozen modules. I suppose the script can be run conditionally, when it's clear that a function signature has been updated. That would be little different to making a decision to update a header manually, except the script can take care of hundreds of functions at the same time. (I'm assuming the function definition is the 'definitive' version (naturally), and the header prototype is derived from that. You apparently work the other way around.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-05 13:00 +1300 |
| Message-ID | <d7dstsFehaeU7@mid.individual.net> |
| In reply to | #71892 |
Bartc wrote: > On 04/10/2015 23:52, Ian Collins wrote: >> Bartc wrote: >>> >>> * Now, it is child's play to write some script that looks for lines >>> starting with "global function" or "function", and creates a prototype >>> to be added to foo.cx or foo.cl respectively. The script is run before >>> normal compiling.) >> >> So you regenerate the header on each compile? > > As I used it, yes. > >> Doesn't that muck up incremental builds? > > My project was too small to have to do incremental builds. Usually I > knew which module to compile (the one I'd just edited), and the linking > was pretty quick. Every so often I would make an edit that I knew would > probably need a global re-compile, but even then it was only a dozen > modules. > > I suppose the script can be run conditionally, when it's clear that a > function signature has been updated. That would be little different to > making a decision to update a header manually, except the script can > take care of hundreds of functions at the same time. Make has been invented :) In a makefile you could have a rule for building your headers which had the source file as a dependency. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-10-04 17:14 -0700 |
| Message-ID | <43g31bdtpg26sqts4g9av2op0rqc4vots2@4ax.com> |
| In reply to | #71903 |
On Mon, 05 Oct 2015 13:00:59 +1300, Ian Collins <ian-news@hotmail.com> wrote: >Make has been invented :) > >In a makefile you could have a rule for building your headers which had >the source file as a dependency. > Morten has actually done that. However he hasn't bothered with dependencies. He compiles makeheaders.c and invokes the program at every make, then compiles his decode_xml project.
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-10-05 09:40 -0700 |
| Message-ID | <MPG.307c47d8b74afd4a73@news.eternal-september.org> |
| In reply to | #71892 |
Bartc wrote: > Ian Collins wrote: > > Bartc wrote: > >> > >> * Now, it is child's play to write some script that looks for lines > >> starting with "global function" or "function", and creates a prototype > >> to be added to foo.cx or foo.cl respectively. The script is run before > >> normal compiling.) > > > > So you regenerate the header on each compile? > > As I used it, yes. > > > Doesn't that muck up incremental builds? > > My project was too small to have to do incremental builds. But you just said (20 minutes ago): > My projects can end up with thousands of functions. That would be > a lot to maintain by hand! And yet it is too small to want incremental builds?
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-05 18:32 +0100 |
| Message-ID | <muuc3b$usu$1@dont-email.me> |
| In reply to | #71985 |
On 05/10/2015 17:40, Philip Lantz wrote: > Bartc wrote: >> My project was too small to have to do incremental builds. > > But you just said (20 minutes ago): (Maybe we're on different times zones as it was a lot longer than 20 minutes.) >> My projects can end up with thousands of functions. That would be >> a lot to maintain by hand! > > And yet it is too small to want incremental builds? The project with the script preprocessing the C was less than 700 functions. Another older project (not C) had perhaps 3000, but the built program was still small enough to put onto a floppy. (It also used different enough development methods that the sorts of problems that people have with C compilers just didn't arise. Some of these choices were deliberately made for rapid development, such as offloading half the functionality onto interpreted code for example.) But even using C today, recompiling that entire 700-function project takes about 0.9 seconds using TinyC. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-10-05 21:59 -0700 |
| Message-ID | <MPG.307cf5261944e98775@news.eternal-september.org> |
| In reply to | #71992 |
Bartc wrote: > Philip Lantz wrote: > > Bartc wrote: > > >> My project was too small to have to do incremental builds. > > > > But you just said (20 minutes ago): > > (Maybe we're on different times zones as it was a lot longer than 20 > minutes.) That was the difference in the timestamps of your two messages; nothing to do with when I read them or when I replied. (Thanks for your reply to my comment, by the way. I snipped it simply because I have no further comment.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-05 01:13 -0700 |
| Message-ID | <kfn4mi54trv.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71881 |
Bartc <bc@freeuk.com> writes: > On 04/10/2015 22:06, Tim Rentsch wrote: > >> 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. > > ais523 seems to be asking about a system that works as I am > suggesting (working out prototypes from definitions). Tim Rentsch > is saying he's used such a system and it was helpful. (And this > is the guy who can't see the point of binary literals.) Now Bart, you be nice, or I won't invite you to my Christmas party. :)
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-06 17:14 +0000 |
| Message-ID | <5614013d.12314000@news.xs4all.nl> |
| In reply to | #71825 |
Bartc <bc@freeuk.com> wrote: > On 04/10/2015 17:16, David Brown wrote: > > And if you need to work constantly in keeping your prototypes up to > > date, then I suggest you have a very poorly structured development > > process - I rarely change the prototypes in a module's header, because I > > am not in the habit of re-arranging a module's API on a regular basis. > > You work differently then. I need to add parameters, change a return > type, make a static function global, consolidate two functions into one, > or vice versa... Each type the prototype(s), wherever they happen to be, > have to change. Then, beg pardon, you should either learn to plan ahead, or learn to keep your clients on a shorter leash. Probably both. Richard
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2015-10-02 14:56 +0100 |
| Message-ID | <87twq9nzls.fsf@gmail.com> |
| In reply to | #71594 |
Richard Heathfield <rjh@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.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-02 16:31 +0100 |
| Message-ID | <mum7sl$2t4$1@dont-email.me> |
| In reply to | #71609 |
On 02/10/15 14:56, Gareth Owen wrote: > Richard Heathfield <rjh@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. Well, yes, you could. Personally, I don't. I might conceivably do so if I had to do a large number of these in one go. Normally, though, this particular macro game is hardly worth the candle, at least in my view. The task is so easy to execute anyway, and is done so (relatively) rarely (in comparison with other tasks), that I find it easier to Just Do It than to take the time and trouble to define, and then *remember to use*, a macro to do the same job. -- 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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2015-10-02 20:11 +0100 |
| Message-ID | <87a8s1m6gn.fsf@gmail.com> |
| In reply to | #71614 |
Richard Heathfield <rjh@cpax.org.uk> writes: > (relatively) rarely (in comparison with other tasks), that I find it > easier to Just Do It than to take the time and trouble to define, I don't know about vi -- a quick google suggests the same thing exists as 'recording' -- but in emacs you can define an anonymous macro on the fly just by doing the commands - i.e. record a sequence of keystrokes for immediate or near-immediate replay. I find it unbelievably useful. > and then *remember to use*, a macro to do the same job. Well if you only defined it 30 seconds ago, remembering is relatively easy.
[toc] | [prev] | [next] | [standalone]
Page 12 of 17 — ← Prev page 1 … 10 11 [12] 13 14 … 17 Next page →
Back to top | Article view | comp.lang.c
csiph-web