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 3 of 17 — ← Prev page 1 2 [3] 4 5 … 17 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-05 12:57 +1300 |
| Message-ID | <d7dsngFehaeU6@mid.individual.net> |
| In reply to | #71890 |
Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> Tim Rentsch wrote: >> >>> I think our views are closer than it might seem. I glossed >>> over a point about workflow, which may explain the apparent >>> differences. Let me elaborate on that. >>> >>> I distinguish (at least) three different kinds of compilations: >>> development, code review, and production. The development kind >>> is what an individual developer does during his/her regular >>> daily work. The code review kind is what is done just before >>> (and in anticipation of) doing a code review. The production >>> kind is what is done as part of the check-in/commit process, >>> for any group-available complete build. >> >> It's interesting how different people's view of normal is. I >> would always use the same diagnostics for all compiles. Mistakes >> should be spotted and corrected as early as possible in the >> development process, so if anything the development compiles >> should be the ones with the most robust checking. > > That depends on whether you think all circumstances reported by > gcc's warning sets represent mistakes. I don't. Some of those > circumstances represent mistakes, but not all of them. So what is stopping you from selecting the ones you deem important and using them for all builds? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-06 09:23 -0700 |
| Message-ID | <kfnmvvw2cgr.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71902 |
Ian Collins <ian-news@hotmail.com> writes: > Tim Rentsch wrote: >> Ian Collins <ian-news@hotmail.com> writes: >> >>> Tim Rentsch wrote: >>> >>>> I think our views are closer than it might seem. I glossed >>>> over a point about workflow, which may explain the apparent >>>> differences. Let me elaborate on that. >>>> >>>> I distinguish (at least) three different kinds of compilations: >>>> development, code review, and production. The development kind >>>> is what an individual developer does during his/her regular >>>> daily work. The code review kind is what is done just before >>>> (and in anticipation of) doing a code review. The production >>>> kind is what is done as part of the check-in/commit process, >>>> for any group-available complete build. >>> >>> It's interesting how different people's view of normal is. I >>> would always use the same diagnostics for all compiles. Mistakes >>> should be spotted and corrected as early as possible in the >>> development process, so if anything the development compiles >>> should be the ones with the most robust checking. >> >> That depends on whether you think all circumstances reported by >> gcc's warning sets represent mistakes. I don't. Some of those >> circumstances represent mistakes, but not all of them. > > So what is stopping you from selecting the ones you deem important > and using them for all builds? Different types of conditions are important for different reasons, and not all the reasons are important all the time. If preparing for a code audit, usually it's a good idea to crank up the warning levels, even for checks that give a good fraction of false positives. At the other end of the spectrum, sometimes all that is wanted is to see whether the code compiles at all, intending to do another pass later for more stringent checks. IME stratifying the checking in this way helps both the speed and the quality of the process. In between the two ends, where code is being checked as part of an automated process that does integration builds, what is important is only the set of checks that are deemed as "must haves" for a submission to be allowed into the integrated build. Along a different axis, sometimes the checks thought important for one project are different from those of another project (eg, different externally imposed requirements). If code from different projects is combined into a single executable, as often happens in the open source world, there may be a need for multiple warning/error options within a single overall build. So I am accustomed to the idea of using different sets of warning/error options at different places and times, as my experience has been that doing that helps the overall process, compared to trying to use the same set all the time.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-07 11:18 +1300 |
| Message-ID | <d7ivktFectqU2@mid.individual.net> |
| In reply to | #72058 |
Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> Tim Rentsch wrote: >>> Ian Collins <ian-news@hotmail.com> writes: >>> >>>> Tim Rentsch wrote: >>>> >>>>> I think our views are closer than it might seem. I glossed >>>>> over a point about workflow, which may explain the apparent >>>>> differences. Let me elaborate on that. >>>>> >>>>> I distinguish (at least) three different kinds of compilations: >>>>> development, code review, and production. The development kind >>>>> is what an individual developer does during his/her regular >>>>> daily work. The code review kind is what is done just before >>>>> (and in anticipation of) doing a code review. The production >>>>> kind is what is done as part of the check-in/commit process, >>>>> for any group-available complete build. >>>> >>>> It's interesting how different people's view of normal is. I >>>> would always use the same diagnostics for all compiles. Mistakes >>>> should be spotted and corrected as early as possible in the >>>> development process, so if anything the development compiles >>>> should be the ones with the most robust checking. >>> >>> That depends on whether you think all circumstances reported by >>> gcc's warning sets represent mistakes. I don't. Some of those >>> circumstances represent mistakes, but not all of them. >> >> So what is stopping you from selecting the ones you deem important >> and using them for all builds? > > Different types of conditions are important for different > reasons, and not all the reasons are important all the time. If > preparing for a code audit, usually it's a good idea to crank up > the warning levels, even for checks that give a good fraction of > false positives. At the other end of the spectrum, sometimes > all that is wanted is to see whether the code compiles at all, > intending to do another pass later for more stringent checks. > IME stratifying the checking in this way helps both the speed > and the quality of the process. I agree with most of what you say above. I guess the difference in approaches stems from the difference in development process. With the process I follow (XP), every build is a potential release build, so it makes sense to use the same checks for both developer and continuous integration builds. > In between the two ends, where > code is being checked as part of an automated process that does > integration builds, what is important is only the set of checks > that are deemed as "must haves" for a submission to be allowed > into the integrated build. Along a different axis, sometimes > the checks thought important for one project are different from > those of another project (eg, different externally imposed > requirements). If code from different projects is combined into > a single executable, as often happens in the open source world, > there may be a need for multiple warning/error options within a > single overall build. So I am accustomed to the idea of using > different sets of warning/error options at different places and > times, as my experience has been that doing that helps the > overall process, compared to trying to use the same set all the > time. Fair enough. Open source projects have their own development process and I agree it's not a good idea to mess with the preferred (often too slack IMO!) build configuration. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-09 13:52 -0700 |
| Message-ID | <kfnk2qv229m.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #72090 |
Ian Collins <ian-news@hotmail.com> writes: > Tim Rentsch wrote: >> Ian Collins <ian-news@hotmail.com> writes: >> >>> Tim Rentsch wrote: >>>> Ian Collins <ian-news@hotmail.com> writes: >>>> >>>>> Tim Rentsch wrote: >>>>> >>>>>> I think our views are closer than it might seem. I glossed >>>>>> over a point about workflow, which may explain the apparent >>>>>> differences. Let me elaborate on that. >>>>>> >>>>>> I distinguish (at least) three different kinds of compilations: >>>>>> development, code review, and production. The development kind >>>>>> is what an individual developer does during his/her regular >>>>>> daily work. The code review kind is what is done just before >>>>>> (and in anticipation of) doing a code review. The production >>>>>> kind is what is done as part of the check-in/commit process, >>>>>> for any group-available complete build. >>>>> >>>>> It's interesting how different people's view of normal is. I >>>>> would always use the same diagnostics for all compiles. Mistakes >>>>> should be spotted and corrected as early as possible in the >>>>> development process, so if anything the development compiles >>>>> should be the ones with the most robust checking. >>>> >>>> That depends on whether you think all circumstances reported by >>>> gcc's warning sets represent mistakes. I don't. Some of those >>>> circumstances represent mistakes, but not all of them. >>> >>> So what is stopping you from selecting the ones you deem important >>> and using them for all builds? >> >> Different types of conditions are important for different >> reasons, and not all the reasons are important all the time. If >> preparing for a code audit, usually it's a good idea to crank up >> the warning levels, even for checks that give a good fraction of >> false positives. At the other end of the spectrum, sometimes >> all that is wanted is to see whether the code compiles at all, >> intending to do another pass later for more stringent checks. >> IME stratifying the checking in this way helps both the speed >> and the quality of the process. > > I agree with most of what you say above. I guess the difference in > approaches stems from the difference in development process. > > With the process I follow (XP), every build is a potential release > build, so it makes sense to use the same checks for both developer and > continuous integration builds. Okay. I will file that away for future reference, so in the future I might do a better job if discussing such things in that kind of environment. >> In between the two ends, where >> code is being checked as part of an automated process that does >> integration builds, what is important is only the set of checks >> that are deemed as "must haves" for a submission to be allowed >> into the integrated build. Along a different axis, sometimes >> the checks thought important for one project are different from >> those of another project (eg, different externally imposed >> requirements). If code from different projects is combined into >> a single executable, as often happens in the open source world, >> there may be a need for multiple warning/error options within a >> single overall build. So I am accustomed to the idea of using >> different sets of warning/error options at different places and >> times, as my experience has been that doing that helps the >> overall process, compared to trying to use the same set all the >> time. > > Fair enough. Open source projects have their own development process > and I agree it's not a good idea to mess with the preferred (often too > slack IMO!) build configuration. Yeah. And I second your "often too slack" sentiment.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-29 09:51 +0200 |
| Message-ID | <mudfr0$5uo$1@dont-email.me> |
| In reply to | #71248 |
On 27/09/15 02:32, Tim Rentsch wrote: > Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > >> On Sat, 2015-09-26, <william@wilbur.25thandClement.com> wrote: >> ... >>> Getting the code to compile cleanly[1] is a good goal [...] >>> >>> [1] Or as clean as reasonable, given that compilers will often complain >>> about perfectly valid and defensible code. >> >> Even with gcc -Wall -Wextra -pedantic, I don't find that extremely >> common. Most of my code compiles without warnings, and that's not >> because I've warped it to please the compiler. > > This doesn't match my experience. Last time I looked about half > of the conditions covered by -Wall and -Wextra are ones that > should be enabled at all times. The other half are a mixed bag, > ranging from an occasional false positive to pointless or worse. Some of these things are a matter of style and coding preferences. So while I agree with you that some warnings should be enabled all the time (preferably as errors) and others are pointless, I bet we'd disagree as to how to divide gcc's warnings into those categories. (I also use many warnings that are not in either -Wall or -Wextra.) > But then my view of how seriously warnings should be treated may > be more severe than yours; I advocate -Werror in all production > compiles. That is also my preference. It can be difficult when dealing with code from other people that doesn't follow the same coding rules - sometimes that means disabling warnings that I normally like. The key point is to find a set of warnings (typically starting with -Wall -Wextra, then disabling ones you don't like and enabling others that you do like) that suit your style and help you find bugs and mistakes as early as possible, and treat any warning as a serious indicator of a possible problem.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-09-29 11:07 +0000 |
| Message-ID | <slrnn0ks6u.eij.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71416 |
On Tue, 2015-09-29, David Brown wrote: > On 27/09/15 02:32, Tim Rentsch wrote: ... >> But then my view of how seriously warnings should be treated may >> be more severe than yours; I advocate -Werror in all production >> compiles. > > That is also my preference. It can be difficult when dealing with code > from other people that doesn't follow the same coding rules - sometimes > that means disabling warnings that I normally like. I think you can tell newer gcc that "use -Werror as a general rule, but let <these> remain mere warnings". Come to think of it, using that feature would make me like -Werror better. My negative experience was at work, and the "errors" were almost exclusively unused functions, parameters or variables. Not really errors, and quite common in code during development, or code with too many #ifdefs. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-29 15:09 +0200 |
| Message-ID | <mue2f5$9sl$1@dont-email.me> |
| In reply to | #71423 |
On 29/09/15 13:07, Jorgen Grahn wrote: > On Tue, 2015-09-29, David Brown wrote: >> On 27/09/15 02:32, Tim Rentsch wrote: > ... > >>> But then my view of how seriously warnings should be treated may >>> be more severe than yours; I advocate -Werror in all production >>> compiles. >> >> That is also my preference. It can be difficult when dealing with code >> from other people that doesn't follow the same coding rules - sometimes >> that means disabling warnings that I normally like. > > I think you can tell newer gcc that "use -Werror as a general rule, > but let <these> remain mere warnings". I think gcc has had that ability for quite some time. > > Come to think of it, using that feature would make me like -Werror > better. My negative experience was at work, and the "errors" were > almost exclusively unused functions, parameters or variables. Not > really errors, and quite common in code during development, or code > with too many #ifdefs. There is always the __attribute__((unused)) option, to tell the compiler that you know that variable or function is unused. And you can cast a variable or parameter to void as an alternative (this works on other compilers too). Of course, this kind of thing gets messy if you need it a lot in code - something like "-Wno-unused-parameter" or "-Wno-error=unused-parameter" might be more applicable, especially during development when you perhaps have a lot of empty stub functions. > > /Jorgen >
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-09-30 07:34 +0000 |
| Message-ID | <slrnn0n441.eij.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71427 |
On Tue, 2015-09-29, David Brown wrote: > On 29/09/15 13:07, Jorgen Grahn wrote: >> On Tue, 2015-09-29, David Brown wrote: >>> On 27/09/15 02:32, Tim Rentsch wrote: >> ... >> >>>> But then my view of how seriously warnings should be treated may >>>> be more severe than yours; I advocate -Werror in all production >>>> compiles. >>> >>> That is also my preference. It can be difficult when dealing with code >>> from other people that doesn't follow the same coding rules - sometimes >>> that means disabling warnings that I normally like. >> >> I think you can tell newer gcc that "use -Werror as a general rule, >> but let <these> remain mere warnings". > > I think gcc has had that ability for quite some time. Yes. When I wrote "newer" I meant the version that was current and stable a few years ago has the feature, but the one we were stuck with at work did not. It might have shown up in 2011 or so. >> Come to think of it, using that feature would make me like -Werror >> better. My negative experience was at work, and the "errors" were >> almost exclusively unused functions, parameters or variables. Not >> really errors, and quite common in code during development, or code >> with too many #ifdefs. > > There is always the __attribute__((unused)) option, to tell the compiler > that you know that variable or function is unused. And you can cast a > variable or parameter to void as an alternative (this works on other > compilers too). Yes. The latter is not ideal though, since you may say (void)foo; and then go on to use foo anyway. It shuts the compiler up, but will mislead the reader. Especially if you hide it in a macro so the code claims UNUSED(foo). > Of course, this kind of thing gets messy if you need it a lot in code - What annoyed me the most, I think, was #ifdefed code with static helper functions. You wanted to split out certain logic for clarity, but was somehow punished for the effort because you had to hide the declaration and definition of the helpers too, even if they were harmless. But of course #ifdef tends to become a punishment in general ... such code easily goes out of hand. > something like "-Wno-unused-parameter" or "-Wno-error=unused-parameter" > might be more applicable, especially during development when you perhaps > have a lot of empty stub functions. Yes. When I'm rewriting code I do it in increments, and I structure the work so the "unused function/parameter/variable" warnings serve as reminders that I'm not done yet in that area. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-30 10:33 +0200 |
| Message-ID | <mug6lf$mn8$1@dont-email.me> |
| In reply to | #71465 |
On 30/09/15 09:34, Jorgen Grahn wrote: > On Tue, 2015-09-29, David Brown wrote: >> On 29/09/15 13:07, Jorgen Grahn wrote: >>> On Tue, 2015-09-29, David Brown wrote: >>>> On 27/09/15 02:32, Tim Rentsch wrote: >>> ... >>> >>>>> But then my view of how seriously warnings should be treated may >>>>> be more severe than yours; I advocate -Werror in all production >>>>> compiles. >>>> >>>> That is also my preference. It can be difficult when dealing with code >>>> from other people that doesn't follow the same coding rules - sometimes >>>> that means disabling warnings that I normally like. >>> >>> I think you can tell newer gcc that "use -Werror as a general rule, >>> but let <these> remain mere warnings". >> >> I think gcc has had that ability for quite some time. > > Yes. When I wrote "newer" I meant the version that was current and > stable a few years ago has the feature, but the one we were stuck with > at work did not. It might have shown up in 2011 or so. > >>> Come to think of it, using that feature would make me like -Werror >>> better. My negative experience was at work, and the "errors" were >>> almost exclusively unused functions, parameters or variables. Not >>> really errors, and quite common in code during development, or code >>> with too many #ifdefs. >> >> There is always the __attribute__((unused)) option, to tell the compiler >> that you know that variable or function is unused. And you can cast a >> variable or parameter to void as an alternative (this works on other >> compilers too). > > Yes. The latter is not ideal though, since you may say (void)foo; and > then go on to use foo anyway. It shuts the compiler up, but will > mislead the reader. Especially if you hide it in a macro so the code > claims UNUSED(foo). Change the name of the macro :-) #define MAYBE_UNUSED(x) (void)(sizeof(x)) By using sizeof, rather than casting x to void directly, you can avoid actually reading the data. For normal variables, assuming optimisation is enabled, "(void) x" will not read x. But if x is volatile, it will do the read - whereas the version with sizeof does not read x. It is perfectly safe to use the parameter or variable later on, even after the cast to void. It is arguably confusing to the reader to see this macro used, then later in the function the variable is used normally - but the compiler won't mind. > >> Of course, this kind of thing gets messy if you need it a lot in code - > > What annoyed me the most, I think, was #ifdefed code with static > helper functions. You wanted to split out certain logic for clarity, > but was somehow punished for the effort because you had to hide the > declaration and definition of the helpers too, even if they were > harmless. > > But of course #ifdef tends to become a punishment in general ... such > code easily goes out of hand. > >> something like "-Wno-unused-parameter" or "-Wno-error=unused-parameter" >> might be more applicable, especially during development when you perhaps >> have a lot of empty stub functions. > > Yes. When I'm rewriting code I do it in increments, and I structure > the work so the "unused function/parameter/variable" warnings serve as > reminders that I'm not done yet in that area. > > /Jorgen >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-09-30 11:14 +0100 |
| Message-ID | <87eghgciy0.fsf@bsb.me.uk> |
| In reply to | #71467 |
David Brown <david.brown@hesbynett.no> writes: <snip> > #define MAYBE_UNUSED(x) (void)(sizeof(x)) > > By using sizeof, rather than casting x to void directly, you can avoid > actually reading the data. For normal variables, assuming optimisation > is enabled, "(void) x" will not read x. But if x is volatile, it will > do the read - whereas the version with sizeof does not read x. There is a probably insignificant corner case here. If x is a VLA whose size is an expression that uses a volatile object, then that expression must be evaluated. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-30 12:26 +0200 |
| Message-ID | <mugd8h$dgc$1@dont-email.me> |
| In reply to | #71472 |
On 30/09/15 12:14, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> <snip>
>> #define MAYBE_UNUSED(x) (void)(sizeof(x))
>>
>> By using sizeof, rather than casting x to void directly, you can avoid
>> actually reading the data. For normal variables, assuming optimisation
>> is enabled, "(void) x" will not read x. But if x is volatile, it will
>> do the read - whereas the version with sizeof does not read x.
>
> There is a probably insignificant corner case here. If x is a VLA whose
> size is an expression that uses a volatile object, then that expression
> must be evaluated.
>
I agree that this case is not going to be a problem in many practical
situations, but c.l.c. would be nearly empty without discussions of
unrealistic corner cases!
I would have thought that in order to be able to make any reference to
the VLA, including just finding its size, the VLA would have to exist.
At its creation, the volatile object giving its size must be accessed.
But after that point, its size is fixed - the sizeof operator does not
need to refer to the volatile object.
extern volatile int v1;
extern volatile int v2;
void foo(void) {
v1 = 1;
char ar[v2];
v1 = 2;
(void) (sizeof ar);
v1 = 3;
}
(The writes to v1 are to make it clear exactly which line the volatile
accesses occur on.)
gcc -c -O2 -Wa,-ahdls
foo:
10 .LFB0:
11 .cfi_startproc
12 0000 C7050000 movl $1, v1(%rip)
12 00000100
12 0000
13 000a 8B050000 movl v2(%rip), %eax
13 0000
14 0010 C7050000 movl $2, v1(%rip)
14 00000200
14 0000
15 001a C7050000 movl $3, v1(%rip)
15 00000300
15 0000
16 0024 C3 ret
v2 is accessed when the VLA is created (though here the actual creation
is omitted after reading v2), but not for the sizeof.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-09-30 11:58 +0100 |
| Message-ID | <878u7ocgwy.fsf@bsb.me.uk> |
| In reply to | #71473 |
David Brown <david.brown@hesbynett.no> writes: > On 30/09/15 12:14, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> <snip> >>> #define MAYBE_UNUSED(x) (void)(sizeof(x)) >>> >>> By using sizeof, rather than casting x to void directly, you can avoid >>> actually reading the data. For normal variables, assuming optimisation >>> is enabled, "(void) x" will not read x. But if x is volatile, it will >>> do the read - whereas the version with sizeof does not read x. >> >> There is a probably insignificant corner case here. If x is a VLA whose >> size is an expression that uses a volatile object, then that expression >> must be evaluated. >> > > I agree that this case is not going to be a problem in many practical > situations, but c.l.c. would be nearly empty without discussions of > unrealistic corner cases! > > I would have thought that in order to be able to make any reference to > the VLA, including just finding its size, the VLA would have to exist. > At its creation, the volatile object giving its size must be accessed. > But after that point, its size is fixed - the sizeof operator does not > need to refer to the volatile object. Yes, I wasn't thinking clearly. The case I described requires x to be evaluated but that does not need to access to the volatile used for the size. The volatile object *would* be accessed if the argument x were a VLA *type* but that is beyond the scope envisaged for the MAYBE_UNUSED macro. There are other, totally contrived, cases involving an expression as the argument to the macro where you would get an unwanted access but, again, they are well beyond the intended use which is for simple named objects. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-10-01 19:16 +0000 |
| Message-ID | <slrnn0r1kb.eij.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71467 |
On Wed, 2015-09-30, David Brown wrote: > On 30/09/15 09:34, Jorgen Grahn wrote: >> On Tue, 2015-09-29, David Brown wrote: >>> On 29/09/15 13:07, Jorgen Grahn wrote: ... >>>> Come to think of it, using that feature would make me like -Werror >>>> better. My negative experience was at work, and the "errors" were >>>> almost exclusively unused functions, parameters or variables. Not >>>> really errors, and quite common in code during development, or code >>>> with too many #ifdefs. >>> >>> There is always the __attribute__((unused)) option, to tell the compiler >>> that you know that variable or function is unused. And you can cast a >>> variable or parameter to void as an alternative (this works on other >>> compilers too). >> >> Yes. The latter is not ideal though, since you may say (void)foo; and >> then go on to use foo anyway. It shuts the compiler up, but will >> mislead the reader. Especially if you hide it in a macro so the code >> claims UNUSED(foo). > > Change the name of the macro :-) > > #define MAYBE_UNUSED(x) (void)(sizeof(x)) Actually, I thought about doing exactly that! Although it would be a bit surreal for the variables marked MAYBE_UNUSED to be precisely those that the compiler never claims are unused ... perhaps it would be more honest to say #define USED(x) (void)(sizeof(x)) Oh well. My solution for now is to not work with ifdef:ed code. And if the subject comes up in a future project, try to make people read the "Ifdef Considered Harmful" paper, hoping that will minimize its use. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-30 16:21 +0200 |
| Message-ID | <mugr50$hh7$1@speranza.aioe.org> |
| In reply to | #71427 |
On 29.09.2015 15:09, David Brown wrote: > On 29/09/15 13:07, Jorgen Grahn wrote: [...] >> I think you can tell newer gcc that "use -Werror as a general rule, >> but let <these> remain mere warnings". > > I think gcc has had that ability for quite some time. > >> >> Come to think of it, using that feature would make me like -Werror >> better. My negative experience was at work, and the "errors" were >> almost exclusively unused functions, parameters or variables. Not >> really errors, and quite common in code during development, or code >> with too many #ifdefs. > > There is always the __attribute__((unused)) option, to tell the compiler > that you know that variable or function is unused. And you can cast a > variable or parameter to void as an alternative (this works on other > compilers too). > > Of course, this kind of thing gets messy if you need it a lot in code - > something like "-Wno-unused-parameter" or "-Wno-error=unused-parameter" > might be more applicable, especially during development when you perhaps > have a lot of empty stub functions. Well it looks like I have a truckload of work in front of me, understanding and dealing with all these errors. But no way around that.. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-10-01 19:27 +0000 |
| Message-ID | <slrnn0r29g.eij.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71484 |
On Wed, 2015-09-30, Morten W. Petersen wrote: > On 29.09.2015 15:09, David Brown wrote: >> On 29/09/15 13:07, Jorgen Grahn wrote: > [...] >>> I think you can tell newer gcc that "use -Werror as a general rule, >>> but let <these> remain mere warnings". >> >> I think gcc has had that ability for quite some time. >> >>> >>> Come to think of it, using that feature would make me like -Werror >>> better. My negative experience was at work, and the "errors" were >>> almost exclusively unused functions, parameters or variables. Not >>> really errors, and quite common in code during development, or code >>> with too many #ifdefs. >> >> There is always the __attribute__((unused)) option, to tell the compiler >> that you know that variable or function is unused. And you can cast a >> variable or parameter to void as an alternative (this works on other >> compilers too). >> >> Of course, this kind of thing gets messy if you need it a lot in code - >> something like "-Wno-unused-parameter" or "-Wno-error=unused-parameter" >> might be more applicable, especially during development when you perhaps >> have a lot of empty stub functions. > > Well it looks like I have a truckload of work in front of me, > understanding and dealing with all these errors. You mean things shown in the rest of the code, not specifically -Wno-unused-parameter and so on mentioned above? The good news is you discovered it fairly early after all. In the past it was not uncommon to enter a project and notice that people had been coding for years without even basic warnings enabled, and with all kinds of weird compiler-specific extensions enabled. It can be very hard to get out of that situation. Fortunately it seems to be rare today. > But no way around that.. Please keep asking about them here (but in separate threads I guess). /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-01 07:58 -0700 |
| Message-ID | <kfn612qbppy.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71416 |
David Brown <david.brown@hesbynett.no> writes: > On 27/09/15 02:32, Tim Rentsch wrote: >> Jorgen Grahn <grahn+nntp@snipabacken.se> writes: >> >>> On Sat, 2015-09-26, <william@wilbur.25thandClement.com> wrote: >>> ... >>>> Getting the code to compile cleanly[1] is a good goal [...] >>>> >>>> [1] Or as clean as reasonable, given that compilers will often complain >>>> about perfectly valid and defensible code. >>> >>> Even with gcc -Wall -Wextra -pedantic, I don't find that extremely >>> common. Most of my code compiles without warnings, and that's not >>> because I've warped it to please the compiler. >> >> This doesn't match my experience. Last time I looked about half >> of the conditions covered by -Wall and -Wextra are ones that >> should be enabled at all times. The other half are a mixed bag, >> ranging from an occasional false positive to pointless or worse. > > Some of these things are a matter of style and coding preferences. > So while I agree with you that some warnings should be enabled all > the time (preferably as errors) and others are pointless, I bet > we'd disagree as to how to divide gcc's warnings into those > categories. Perhaps so. However that doesn't change the main point about (not) blindly using all of -Wall and -Wextra. > (I also use many warnings that are not in either -Wall or > -Wextra.) I don't really pay attention to which is which anymore. I normally recommend looking at a full list of individual options, and selecting those thought appropriate for the environment or project in question. >> But then my view of how seriously warnings should be treated may >> be more severe than yours; I advocate -Werror in all production >> compiles. > > That is also my preference. My recommending -Werror stems not from my preference but from observing group behavior in lots of different environments. > It can be difficult when dealing > with code from other people that doesn't follow the same coding > rules - sometimes that means disabling warnings that I normally > like. It's important to distinguish between diagnostic conditions that are essentially always showing a defect and diagnostic conditions that mean "this code merits review with careful attention". If there are diagnostics for violation of coding standard rules, that is a third category. Lumping all these different types together confuses the issue and frequently leads to heated arguments. Conversely, keeping them separate clarifies the different concerns and leads (at least sometimes) to calmer discussions. I recommend classifying the various individual conditions explicitly to identify which is which. This is another reason to avoid adopting -Wall/-Wextra wholesale, as these sets lump together different types of conditions. > The key point is to find a set of warnings (typically starting > with -Wall -Wextra, then disabling ones you don't like and > enabling others that you do like) that suit your style and help > you find bugs and mistakes as early as possible, and treat any > warning as a serious indicator of a possible problem. IMO this advice is phrased badly, because it puts the emphasis on the wrong end of the spectrum. Conditions chosen because of personal stylistic preference constitute a fourth category, and the least important of the four. The emphasis should be on the most objective category first: which ones are essentially always defects; which ones are likely probable defects needing review; which ones correspond to coding standard violations (these may come before some in the previous category, depending on the particulars); and only then those reflecting personal stylistic preference.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-01 21:52 +0200 |
| Message-ID | <muk2q8$2o3$1@dont-email.me> |
| In reply to | #71541 |
On 01/10/15 16:58, Tim Rentsch wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 27/09/15 02:32, Tim Rentsch wrote: >>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes: >>> >>>> On Sat, 2015-09-26, <william@wilbur.25thandClement.com> wrote: >>>> ... >>>>> Getting the code to compile cleanly[1] is a good goal [...] >>>>> >>>>> [1] Or as clean as reasonable, given that compilers will often complain >>>>> about perfectly valid and defensible code. >>>> >>>> Even with gcc -Wall -Wextra -pedantic, I don't find that extremely >>>> common. Most of my code compiles without warnings, and that's not >>>> because I've warped it to please the compiler. >>> >>> This doesn't match my experience. Last time I looked about half >>> of the conditions covered by -Wall and -Wextra are ones that >>> should be enabled at all times. The other half are a mixed bag, >>> ranging from an occasional false positive to pointless or worse. >> >> Some of these things are a matter of style and coding preferences. >> So while I agree with you that some warnings should be enabled all >> the time (preferably as errors) and others are pointless, I bet >> we'd disagree as to how to divide gcc's warnings into those >> categories. > > Perhaps so. However that doesn't change the main point about > (not) blindly using all of -Wall and -Wextra. > >> (I also use many warnings that are not in either -Wall or >> -Wextra.) > > I don't really pay attention to which is which anymore. I > normally recommend looking at a full list of individual options, > and selecting those thought appropriate for the environment or > project in question. > >>> But then my view of how seriously warnings should be treated may >>> be more severe than yours; I advocate -Werror in all production >>> compiles. >> >> That is also my preference. > > My recommending -Werror stems not from my preference but from > observing group behavior in lots of different environments. > >> It can be difficult when dealing >> with code from other people that doesn't follow the same coding >> rules - sometimes that means disabling warnings that I normally >> like. > > It's important to distinguish between diagnostic conditions that > are essentially always showing a defect and diagnostic conditions > that mean "this code merits review with careful attention". If > there are diagnostics for violation of coding standard rules, > that is a third category. Lumping all these different types > together confuses the issue and frequently leads to heated > arguments. Conversely, keeping them separate clarifies the > different concerns and leads (at least sometimes) to calmer > discussions. I recommend classifying the various individual > conditions explicitly to identify which is which. This is > another reason to avoid adopting -Wall/-Wextra wholesale, as > these sets lump together different types of conditions. > >> The key point is to find a set of warnings (typically starting >> with -Wall -Wextra, then disabling ones you don't like and >> enabling others that you do like) that suit your style and help >> you find bugs and mistakes as early as possible, and treat any >> warning as a serious indicator of a possible problem. > > IMO this advice is phrased badly, because it puts the emphasis on > the wrong end of the spectrum. Conditions chosen because of > personal stylistic preference constitute a fourth category, and > the least important of the four. The emphasis should be on the > most objective category first: which ones are essentially always > defects; which ones are likely probable defects needing review; > which ones correspond to coding standard violations (these may > come before some in the previous category, depending on the > particulars); and only then those reflecting personal stylistic > preference. > I agree mostly with what you are saying, but again I think we have different ideas about what is personal style (or corporate style, or project style, depending on who you are working for at the time). One of the reasons why there are so many choices of warning flags, and why -Wall is not enabled by default, is that not everyone agrees on which are "essentially always defects" or other categories of warnings. There will be people happy to knowingly write certain types of undefined behaviour because "it works on /my/ system", even though you or I would probably count that as always a defect. And there will be projects where any accidental use of a "double" is a major defect, though the "-Wdouble-promotion" warning is not even in the -Wextra group. But I like the idea of considering different categories and types of warnings, and being sure to put the emphasis on the most important ones first - making such decisions as objectively as possible, but without making the mistake of thinking they are /truly/ objective. This would also make it practical to use different warning sets on different parts of a project - in particular, if different parts are written to different coding styles, then any coding-style specific warning messages could have different settings for the different parts.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-04 16:10 -0700 |
| Message-ID | <kfnegha6xiv.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71562 |
David Brown <david.brown@hesbynett.no> writes: > On 01/10/15 16:58, Tim Rentsch wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 27/09/15 02:32, Tim Rentsch wrote: >>>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes: >>>> >>>>> On Sat, 2015-09-26, <william@wilbur.25thandClement.com> wrote: >>>>> ... >>>>>> Getting the code to compile cleanly[1] is a good goal [...] >>>>>> >>>>>> [1] Or as clean as reasonable, given that compilers will often complain >>>>>> about perfectly valid and defensible code. >>>>> >>>>> Even with gcc -Wall -Wextra -pedantic, I don't find that extremely >>>>> common. Most of my code compiles without warnings, and that's not >>>>> because I've warped it to please the compiler. >>>> >>>> This doesn't match my experience. Last time I looked about half >>>> of the conditions covered by -Wall and -Wextra are ones that >>>> should be enabled at all times. The other half are a mixed bag, >>>> ranging from an occasional false positive to pointless or worse. >>> >>> Some of these things are a matter of style and coding preferences. >>> So while I agree with you that some warnings should be enabled all >>> the time (preferably as errors) and others are pointless, I bet >>> we'd disagree as to how to divide gcc's warnings into those >>> categories. >> >> Perhaps so. However that doesn't change the main point about >> (not) blindly using all of -Wall and -Wextra. >> >>> (I also use many warnings that are not in either -Wall or >>> -Wextra.) >> >> I don't really pay attention to which is which anymore. I >> normally recommend looking at a full list of individual options, >> and selecting those thought appropriate for the environment or >> project in question. >> >>>> But then my view of how seriously warnings should be treated may >>>> be more severe than yours; I advocate -Werror in all production >>>> compiles. >>> >>> That is also my preference. >> >> My recommending -Werror stems not from my preference but from >> observing group behavior in lots of different environments. >> >>> It can be difficult when dealing >>> with code from other people that doesn't follow the same coding >>> rules - sometimes that means disabling warnings that I normally >>> like. >> >> It's important to distinguish between diagnostic conditions that >> are essentially always showing a defect and diagnostic conditions >> that mean "this code merits review with careful attention". If >> there are diagnostics for violation of coding standard rules, >> that is a third category. Lumping all these different types >> together confuses the issue and frequently leads to heated >> arguments. Conversely, keeping them separate clarifies the >> different concerns and leads (at least sometimes) to calmer >> discussions. I recommend classifying the various individual >> conditions explicitly to identify which is which. This is >> another reason to avoid adopting -Wall/-Wextra wholesale, as >> these sets lump together different types of conditions. >> >>> The key point is to find a set of warnings (typically starting >>> with -Wall -Wextra, then disabling ones you don't like and >>> enabling others that you do like) that suit your style and help >>> you find bugs and mistakes as early as possible, and treat any >>> warning as a serious indicator of a possible problem. >> >> IMO this advice is phrased badly, because it puts the emphasis on >> the wrong end of the spectrum. Conditions chosen because of >> personal stylistic preference constitute a fourth category, and >> the least important of the four. The emphasis should be on the >> most objective category first: which ones are essentially always >> defects; which ones are likely probable defects needing review; >> which ones correspond to coding standard violations (these may >> come before some in the previous category, depending on the >> particulars); and only then those reflecting personal stylistic >> preference. > > I agree mostly with what you are saying, but again I think we have > different ideas about what is personal style (or corporate style, or > project style, depending on who you are working for at the time). One > of the reasons why there are so many choices of warning flags, and why > -Wall is not enabled by default, is that not everyone agrees on which > are "essentially always defects" or other categories of warnings. > There will be people happy to knowingly write certain types of > undefined behaviour because "it works on /my/ system", even though you > or I would probably count that as always a defect. And there will be > projects where any accidental use of a "double" is a major defect, > though the "-Wdouble-promotion" warning is not even in the -Wextra > group. > > But I like the idea of considering different categories and types of > warnings, and being sure to put the emphasis on the most important > ones first - making such decisions as objectively as possible, but > without making the mistake of thinking they are /truly/ objective. > This would also make it practical to use different warning sets on > different parts of a project - in particular, if different parts are > written to different coding styles, then any coding-style specific > warning messages could have different settings for the different > parts. I think it helps to mentally distinguish them, even if the distinctions aren't always completely objective. And it's even better if the separate categories are identified separately in the Makefile (eg, W_DEFECTS, W_REVIEW, etc), to make it easier to enable/disable them selectively. Needless to say I appreciate the positive comments. Let's have more of those. :)
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-27 11:15 +0100 |
| Message-ID | <mu8fge$hpg$1@dont-email.me> |
| In reply to | #71220 |
On 26/09/2015 16:28, Jorgen Grahn wrote: > On Sat, 2015-09-26, <william@wilbur.25thandClement.com> wrote: > ... >> Getting the code to compile cleanly[1] is a good goal [...] > >> [1] Or as clean as reasonable, given that compilers will often complain >> about perfectly valid and defensible code. > > Even with gcc -Wall -Wextra -pedantic, I don't find that extremely > common. Most of my code compiles without warnings, and that's not > because I've warped it to please the compiler. Try using multiple compilers and see if that's still the case. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-09-28 08:47 +0000 |
| Message-ID | <slrnn0hvlr.eij.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71269 |
On Sun, 2015-09-27, Bartc wrote: > On 26/09/2015 16:28, Jorgen Grahn wrote: >> On Sat, 2015-09-26, <william@wilbur.25thandClement.com> wrote: >> ... >>> Getting the code to compile cleanly[1] is a good goal [...] >> >>> [1] Or as clean as reasonable, given that compilers will often complain >>> about perfectly valid and defensible code. >> >> Even with gcc -Wall -Wextra -pedantic, I don't find that extremely >> common. Most of my code compiles without warnings, and that's not >> because I've warped it to please the compiler. > > Try using multiple compilers and see if that's still the case. Other compilers would not have those exact options. Note that I'm not arguing that it's feasible to have your code compile cleanly with /any/ compiler, using /any/ set of flags. I'm just saying that I find it feasible with gcc -Wall -Wextra -pedantic (and I should have added -std=c99 there). /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
Page 3 of 17 — ← Prev page 1 2 [3] 4 5 … 17 Next page →
Back to top | Article view | comp.lang.c
csiph-web