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 7 of 17 — ← Prev page 1 … 5 6 [7] 8 9 … 17 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-09-30 06:08 -0700 |
| Message-ID | <00beb84a-7a23-4381-aa8f-9a67ee4cb627@googlegroups.com> |
| In reply to | #71476 |
On Wednesday, September 30, 2015 at 6:17:47 AM UTC-5, Jorgen Grahn wrote:
> Parameter names aren't checked by the compiler so they /can/ go out of
> sync, but they still are too valuable as documentation to be omitted.
>
> I rarely or never see people omitting them.
I've seen some libraries supplied with distinct human-readable and minimal
header files; the former included parameter names and comments, while the
latter contained nothing wasn't needed by the compiler. Back before the
days of precompiled headers (BTW, I wonder why precompiled header files are
so *huge*?) cutting out stuff the compiler wasn't going to use could make
compilation noticeably faster.
Although I don't know that I've seen any widely-published tools to automate
such, I would think a sensible pattern would be to have a project not use
human-constructed header files, but instead use markers in each source file
to identify content which also belongs in headers, and then have header-file
generation be part of the build process. One slight complication would be
that to work nicely with the make process, it would probably be necessary to
have two files for each header, and have the make logic work as follows:
if foo.c is newer than foo.h.time, then generate header data from foo.c
into a temporary buffer. If that does not match foo.h, write it to
foo.h; then generate a dummy file foo.h.time whether or not foo.h was
written.
Every change to foo.c would cause the time on foo.h.time to get changed, but
would only update foo.h if the change would need to percolate to the header.
Changes to foo.c which don't result in changes to foo.h should not require
any changes to anything which includes foo.h. Note that if the tool can
generate both human-readable and minimized headers, changes to the source
file which should affect the human-readable form only would not necessitate
recompilation of dependent files.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-27 17:09 -0700 |
| Message-ID | <lnwpvb76c3.fsf@kst-u.example.com> |
| In reply to | #71313 |
"Morten W. Petersen" <morphex@gmail.com> writes:
[...]
> A bit awkward perhaps, but this works:
>
> #include <stdio.h>
>
> #define my_func_SIGNATURE int my_func(int a, int b)
>
> my_func_SIGNATURE;
>
> __inline__ my_func_SIGNATURE {
> return a+b;
> }
>
> int main() {
> int a = 1;
> int b = 2;
> printf("Result of a+b: %i\n", my_func(a,b));
> }
This works and is not awkward:
#include <stdio.h>
int my_func(int a, int b);
inline int my_func(int a, int b) {
return a+b;
}
int main(void) {
int a = 1;
int b = 2;
printf("Result of a+b: %i\n", my_func(a,b));
}
(You could just omit the separate declaration in this case, but it's
useful, or even required, in more complicated code.)
I changed your "int main()" to "int main(void)" because the latter is
more correct (that's a very minor point).
"__inline__" is a non-standard gcc extension. Just use "inline" unless
you need to cater to pre-C99 compilers.
Your "my_func_SIGNATURE" just makes your code more difficult to read.
Every time I see it, I have to track down its definition to understand
what it means.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-28 02:17 +0200 |
| Message-ID | <mua0tl$asl$1@speranza.aioe.org> |
| In reply to | #71322 |
On 28.09.2015 02:09, Keith Thompson wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
[...]
>> A bit awkward perhaps, but this works:
>>
>> #include <stdio.h>
>>
>> #define my_func_SIGNATURE int my_func(int a, int b)
>>
>> my_func_SIGNATURE;
>>
>> __inline__ my_func_SIGNATURE {
>> return a+b;
>> }
>>
>> int main() {
>> int a = 1;
>> int b = 2;
>> printf("Result of a+b: %i\n", my_func(a,b));
>> }
>
> This works and is not awkward:
>
> #include <stdio.h>
>
> int my_func(int a, int b);
>
> inline int my_func(int a, int b) {
> return a+b;
> }
>
> int main(void) {
> int a = 1;
> int b = 2;
> printf("Result of a+b: %i\n", my_func(a,b));
> }
[...]
> Your "my_func_SIGNATURE" just makes your code more difficult to read.
> Every time I see it, I have to track down its definition to understand
> what it means.
Well it does make it clear what's going on with a capital SIGNATURE,
tracking it down doesn't seem like a big deal.
It's a trade-off for maintainability and I'll be using it when
prototypes are added.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-28 09:00 -0700 |
| Message-ID | <lnsi5y7cuv.fsf@kst-u.example.com> |
| In reply to | #71324 |
"Morten W. Petersen" <morphex@gmail.com> writes:
> On 28.09.2015 02:09, Keith Thompson wrote:
>> "Morten W. Petersen" <morphex@gmail.com> writes:
> [...]
>>> A bit awkward perhaps, but this works:
>>>
>>> #include <stdio.h>
>>>
>>> #define my_func_SIGNATURE int my_func(int a, int b)
>>>
>>> my_func_SIGNATURE;
>>>
>>> __inline__ my_func_SIGNATURE {
>>> return a+b;
>>> }
>>>
>>> int main() {
>>> int a = 1;
>>> int b = 2;
>>> printf("Result of a+b: %i\n", my_func(a,b));
>>> }
>>
>> This works and is not awkward:
>>
>> #include <stdio.h>
>>
>> int my_func(int a, int b);
>>
>> inline int my_func(int a, int b) {
>> return a+b;
>> }
>>
>> int main(void) {
>> int a = 1;
>> int b = 2;
>> printf("Result of a+b: %i\n", my_func(a,b));
>> }
> [...]
>> Your "my_func_SIGNATURE" just makes your code more difficult to read.
>> Every time I see it, I have to track down its definition to understand
>> what it means.
>
> Well it does make it clear what's going on with a capital SIGNATURE,
> tracking it down doesn't seem like a big deal.
>
> It's a trade-off for maintainability and I'll be using it when
> prototypes are added.
You can, of course, do whatever you like.
But a number of people with more C experience than you have are
telling you that your suggested approach causes more problems than
it solves.
It's a clever idea, and it's perfectly reasonable to *think* that
it's a good one. It lets you write certain information only once,
whereas the conventional approach requires you to duplicate the
same information in two separate source files (the .h and the
corresponding .c).
But what we're trying to tell you, based on a great deal of
experience, is that writing the declaration twice *works*.
The initial work of writing it is trivial; just copy-and-paste.
If the declaration and definition get out of sync, the compiler
will flag the error for you.
You'll commonly have several declarations in a .h file, with matching
definitions in the corresponding .c file. With your approach,
that means you'll have multiple macros, one for each function.
And the parameter names and types *won't be visible* when you're
editing the function definition. That may be the biggest problem
with your approach.
And your macro name "my_func_SIGNATURE" isn't much shorter than
the actual declaration "int my_func(int a, int b)".
Finally, if you look at existing C code, you'll find few if any
examples that use this approach. There are reasons for that.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | ais523 <ais523@nethack4.org> |
|---|---|
| Date | 2015-10-01 14:05 +0000 |
| Message-ID | <mujejp$cns$1@dont-email.me> |
| In reply to | #71376 |
Keith Thompson wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: >> On 28.09.2015 02:09, Keith Thompson wrote: >>> Your "my_func_SIGNATURE" just makes your code more difficult to read. >>> Every time I see it, I have to track down its definition to understand >>> what it means. >> >> Well it does make it clear what's going on with a capital SIGNATURE, >> tracking it down doesn't seem like a big deal. >> >> It's a trade-off for maintainability and I'll be using it when >> prototypes are added. > > You can, of course, do whatever you like. > > But a number of people with more C experience than you have are > telling you that your suggested approach causes more problems than > it solves. > > It's a clever idea, and it's perfectly reasonable to *think* that > it's a good one. It lets you write certain information only once, > whereas the conventional approach requires you to duplicate the > same information in two separate source files (the .h and the > corresponding .c). > > But what we're trying to tell you, based on a great deal of > experience, is that writing the declaration twice *works*. > The initial work of writing it is trivial; just copy-and-paste. > If the declaration and definition get out of sync, the compiler > will flag the error for you. > > You'll commonly have several declarations in a .h file, with matching > definitions in the corresponding .c file. With your approach, > that means you'll have multiple macros, one for each function. > And the parameter names and types *won't be visible* when you're > editing the function definition. That may be the biggest problem > with your approach. > > And your macro name "my_func_SIGNATURE" isn't much shorter than > the actual declaration "int my_func(int a, int b)". > > Finally, if you look at existing C code, you'll find few if any > examples that use this approach. There are reasons for that. Having to write each prototype twice (once in the declaration and once in the definition) is something that annoys me too, but I agree with the prevailing comp.lang.c opinion that using a macro for it (and thus making the names of the argument unclear from the definition) is unwise. However, I've had some thoughts about removing the duplication the other way instead. The idea would be to look at a source file, and automatically extract prototypes from all the function definitions (tools that do this already exist, although IIRC they're mostly dying out because they were mostly used to convert between prototype-based and K&R C, and K&R C is mostly dead). Then the tool would write a header file containing all the declarations. The end result would be that the files you use as input would use the normal style for C source files (definitions in the file itself with prototypes, no extern declarations in the file itself, but with the extern definitions included via a header file), but that instead of the header files being entirely written by hand, the portions of the header files that specified declarations would be automatically generated. Does anyone know of a build system that works like this? Would such a thing be useful? Are there any big reasons to avoid this sort of system? (I'm vaguely minded to work on something like this myself.) -- ais523
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-10-01 16:23 +0200 |
| Message-ID | <mujfjt$lg1$1@speranza.aioe.org> |
| In reply to | #71536 |
On 01.10.2015 16:05, ais523 wrote: > Keith Thompson wrote: [...] > However, I've had some thoughts about removing the duplication the other > way instead. The idea would be to look at a source file, and > automatically extract prototypes from all the function definitions > (tools that do this already exist, although IIRC they're mostly dying > out because they were mostly used to convert between prototype-based > and K&R C, and K&R C is mostly dead). Then the tool would write a header > file containing all the declarations. > > The end result would be that the files you use as input would use the > normal style for C source files (definitions in the file itself with > prototypes, no extern declarations in the file itself, but with the > extern definitions included via a header file), but that instead of the > header files being entirely written by hand, the portions of the header > files that specified declarations would be automatically generated. > > Does anyone know of a build system that works like this? Would such a > thing be useful? Are there any big reasons to avoid this sort of system? > (I'm vaguely minded to work on something like this myself.) I think that sounds like a good idea, if it also has the ability to include some text (comment) segments from before the function or from the start of the function that would suit my needs. -Morten
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-01 10:26 -0400 |
| Message-ID | <mujfnk$h5n$1@dont-email.me> |
| In reply to | #71536 |
On 10/01/2015 10:05 AM, ais523 wrote: ... > Having to write each prototype twice (once in the declaration and once > in the definition) is something that annoys me too, but I agree with the > prevailing comp.lang.c opinion that using a macro for it (and thus > making the names of the argument unclear from the definition) is unwise. > > However, I've had some thoughts about removing the duplication the other > way instead. The idea would be to look at a source file, and > automatically extract prototypes from all the function definitions > (tools that do this already exist, although IIRC they're mostly dying > out because they were mostly used to convert between prototype-based > and K&R C, and K&R C is mostly dead). Then the tool would write a header > file containing all the declarations. > > The end result would be that the files you use as input would use the > normal style for C source files (definitions in the file itself with > prototypes, no extern declarations in the file itself, but with the > extern definitions included via a header file), but that instead of the > header files being entirely written by hand, the portions of the header > files that specified declarations would be automatically generated. > > Does anyone know of a build system that works like this? Would such a > thing be useful? Are there any big reasons to avoid this sort of system? > (I'm vaguely minded to work on something like this myself.) It sounds like a good idea to me, probably because I had the same idea, about 20 years ago. If someone did create such a program, I'd be very interested in trying it out. I remember writing a program to do something like that, but it used a very simplistic approach, having been written at a time when I knew a lot less about the C standard than I do today. At a minimum, I'm fairly certain it handled typedefs incorrectly. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-01 16:53 +0200 |
| Message-ID | <mujh9g$nui$1@dont-email.me> |
| In reply to | #71538 |
On 01/10/15 16:26, James Kuyper wrote:
> On 10/01/2015 10:05 AM, ais523 wrote:
> ...
>> Having to write each prototype twice (once in the declaration and once
>> in the definition) is something that annoys me too, but I agree with the
>> prevailing comp.lang.c opinion that using a macro for it (and thus
>> making the names of the argument unclear from the definition) is unwise.
>>
>> However, I've had some thoughts about removing the duplication the other
>> way instead. The idea would be to look at a source file, and
>> automatically extract prototypes from all the function definitions
>> (tools that do this already exist, although IIRC they're mostly dying
>> out because they were mostly used to convert between prototype-based
>> and K&R C, and K&R C is mostly dead). Then the tool would write a header
>> file containing all the declarations.
>>
>> The end result would be that the files you use as input would use the
>> normal style for C source files (definitions in the file itself with
>> prototypes, no extern declarations in the file itself, but with the
>> extern definitions included via a header file), but that instead of the
>> header files being entirely written by hand, the portions of the header
>> files that specified declarations would be automatically generated.
>>
>> Does anyone know of a build system that works like this? Would such a
>> thing be useful? Are there any big reasons to avoid this sort of system?
>> (I'm vaguely minded to work on something like this myself.)
>
> It sounds like a good idea to me, probably because I had the same idea,
> about 20 years ago. If someone did create such a program, I'd be very
> interested in trying it out.
> I remember writing a program to do something like that, but it used a
> very simplistic approach, having been written at a time when I knew a
> lot less about the C standard than I do today. At a minimum, I'm fairly
> certain it handled typedefs incorrectly.
>
If you think something like this is a good idea for normal usage in
modern programming (as distinct from trying to convert massive ancient
code bases to newer C standards), I would suggest you need to get a
better editor/IDE (one that lets you view and edit more than one file at
a time, and that supports copy-and-paste), and probably better structure
for your code.
The header is the interface, showing users what the module does. The C
file tells the compiler how the functionality is implemented. These are
different things. In particular, the comments you put in the header
file are targeted to users of the module, while the comments you put in
C file are targeted at maintainers of the code.
So at best, such automated prototype extractors would be able to take a
C function like this:
int foo(int x, double y) {
...
}
and make a header line:
extern int foo(int x, double y);
Such a tool is hardly going to make a difference.
A far more useful tool would be one that read the header, read the C
file, and checked that the parameter names and types match up between
the declaration and the definition.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-01 11:26 -0400 |
| Message-ID | <mujj72$vjq$1@dont-email.me> |
| In reply to | #71540 |
On 10/01/2015 10:53 AM, David Brown wrote:
> On 01/10/15 16:26, James Kuyper wrote:
>> On 10/01/2015 10:05 AM, ais523 wrote:
>> ...
>>> Having to write each prototype twice (once in the declaration and once
>>> in the definition) is something that annoys me too, but I agree with the
>>> prevailing comp.lang.c opinion that using a macro for it (and thus
>>> making the names of the argument unclear from the definition) is unwise.
>>>
>>> However, I've had some thoughts about removing the duplication the other
>>> way instead. The idea would be to look at a source file, and
>>> automatically extract prototypes from all the function definitions
>>> (tools that do this already exist, although IIRC they're mostly dying
>>> out because they were mostly used to convert between prototype-based
>>> and K&R C, and K&R C is mostly dead). Then the tool would write a header
>>> file containing all the declarations.
>>>
>>> The end result would be that the files you use as input would use the
>>> normal style for C source files (definitions in the file itself with
>>> prototypes, no extern declarations in the file itself, but with the
>>> extern definitions included via a header file), but that instead of the
>>> header files being entirely written by hand, the portions of the header
>>> files that specified declarations would be automatically generated.
>>>
>>> Does anyone know of a build system that works like this? Would such a
>>> thing be useful? Are there any big reasons to avoid this sort of system?
>>> (I'm vaguely minded to work on something like this myself.)
>>
>> It sounds like a good idea to me, probably because I had the same idea,
>> about 20 years ago. If someone did create such a program, I'd be very
>> interested in trying it out.
>> I remember writing a program to do something like that, but it used a
>> very simplistic approach, having been written at a time when I knew a
>> lot less about the C standard than I do today. At a minimum, I'm fairly
>> certain it handled typedefs incorrectly.
>>
>
> If you think something like this is a good idea for normal usage in
> modern programming (as distinct from trying to convert massive ancient
> code bases to newer C standards), I would suggest you need to get a
> better editor/IDE (one that lets you view and edit more than one file at
> a time, and that supports copy-and-paste), and probably better structure
> for your code.
I can and do edit more than one file at a time, and copy-and-paste is
quite feasible - it's the manual and error-prone nature of the process
that bothers me, when all of the information needed to create the header
file is (or could be) stored in the implementation file.
I won't claim that this is a major problem, but it's enough of a problem
that I'd appreciate a solution of this type.
> The header is the interface, showing users what the module does. The C
> file tells the compiler how the functionality is implemented. These are
> different things. In particular, the comments you put in the header
> file are targeted to users of the module, while the comments you put in
> C file are targeted at maintainers of the code.
True - but nearly 100% of the code in the header file is a duplicate of
code in the implementation file, and must be a duplicate in order for
the header to work properly. That argues strongly for creation of the
header from the implementation file. The comments issue is the only
thing that argues otherwise, and I don't think it would be a horrible
thing to have sthe comments for the user also stored in the
implementation file, in order to allow them to be copied into the
generated header file. There just needs to be a convention for
distinguishing between comments for users and comments for implementors,
and it needn't involve any new syntax; it could be based upon the
location of the comments - any comments between the start of a function
definition and the body of the function could be considered user
comments, with all other comments treated as implementor comments.
Whether a comment that immediately precedes a function definition
(separated by at most one newline) should be treated as a user comment
is an issue I still have to think about.
The trickiest part, which would require close interaction with the
compiler, is that any #include files that are the source of the
definitions for identifiers used in the function declaration should also
be #included in the header file - this requires parsing the #included
header files and keeping track of the source of all definitions used in
the function declarations. That would be reversed from the way I
currently do things - since the header file is #included in the
implementation file, the implementation file itself doesn't contain
those #include directives. It only #includes those additional headers
needed for the body of the function (and for any static functions
defined in the same translation unit).
> So at best, such automated prototype extractors would be able to take a
> C function like this:
>
> int foo(int x, double y) {
> ...
> }
>
> and make a header line:
>
> extern int foo(int x, double y);
>
> Such a tool is hardly going to make a difference.
>
> A far more useful tool would be one that read the header, read the C
> file, and checked that the parameter names and types match up between
> the declaration and the definition.
Well, that already exists: such checking is mandatory if you #include
the header file in the implementation file.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-01 21:57 +0200 |
| Message-ID | <muk33b$3sv$1@dont-email.me> |
| In reply to | #71543 |
On 01/10/15 17:26, James Kuyper wrote:
> On 10/01/2015 10:53 AM, David Brown wrote:
>> A far more useful tool would be one that read the header, read the C
>> file, and checked that the parameter names and types match up between
>> the declaration and the definition.
>
> Well, that already exists: such checking is mandatory if you #include
> the header file in the implementation file.
>
The checking is too weak for my tastes (unless gcc or clang have gained
new warning options that I haven't noticed). In particular, compilers
are quite happy with this (since the C standards allow it) :
// module.h
extern int foo(int a, int b);
// module.c
#include "module.h"
int foo(int b, int a) { ... }
You can not only rename parameters, but you can also use different
typedefs on the types (as long as they are compatible).
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-01 13:30 -0700 |
| Message-ID | <8362e3dd-17c5-4d88-a88f-5116ea0f10e0@googlegroups.com> |
| In reply to | #71564 |
On Thursday, October 1, 2015 at 2:57:33 PM UTC-5, David Brown wrote:
> You can not only rename parameters, but you can also use different
> typedefs on the types (as long as they are compatible).
If a compiler deems types X and Y are sufficiently compatible that it does
not issue a diagnostic if a parameter which is of type X in one declaration
is specified as type Y in another, does that imply that for purposes of the
Strict Aliasing Rule, memory written using type X must be readable as type
Y?
For example, by my understanding, it would be legal to have a compiler where
"int", "long", and "int32_t" were all 32 bits, but which would nonetheless
assume that given:
int32_t blah(int32_t *p1, int *p2, long *p3)
{
*p1 = 0x00000001;
*p2 = 0x00000100;
*p3 = 0x00010000;
return *p1 + *p2 + *p3;
}
the return value would always be 0x00010101. Would such a compiler be
required to issue a diagnostic if the above code had been preceded by the
declaration:
int32_t blah(long *p1, int32_t *p2, int *p3);
If a compiler regards all three types as fully equivalent, I don't think
any diagnostic is required. Is there a requirement for a diagnostic if the
types aren't fully equivalent?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-01 13:57 -0700 |
| Message-ID | <ln37xu2tp6.fsf@kst-u.example.com> |
| In reply to | #71566 |
supercat@casperkitty.com writes:
> On Thursday, October 1, 2015 at 2:57:33 PM UTC-5, David Brown wrote:
>> You can not only rename parameters, but you can also use different
>> typedefs on the types (as long as they are compatible).
>
> If a compiler deems types X and Y are sufficiently compatible that it does
> not issue a diagnostic if a parameter which is of type X in one declaration
> is specified as type Y in another, does that imply that for purposes of the
> Strict Aliasing Rule, memory written using type X must be readable as type
> Y?
>
> For example, by my understanding, it would be legal to have a compiler where
> "int", "long", and "int32_t" were all 32 bits, but which would nonetheless
> assume that given:
>
> int32_t blah(int32_t *p1, int *p2, long *p3)
> {
> *p1 = 0x00000001;
> *p2 = 0x00000100;
> *p3 = 0x00010000;
> return *p1 + *p2 + *p3;
> }
>
> the return value would always be 0x00010101.
I believe a compiler could assume that only if int, long, and int32_t
are all distinct types. Perhaps short is also 32 bits, and int32_t is a
typedef for short.
A program could break that assumption by passing the same address
(converted appropriately) for two or more of the parameters, causing
undefined behavior.
> Would such a compiler be
> required to issue a diagnostic if the above code had been preceded by the
> declaration:
>
> int32_t blah(long *p1, int32_t *p2, int *p3);
Yes. The types have to be *compatible*, which is a stronger requirement
than having the same size and representation. For example, int and long
are *always* incompatible, which means that int* and long* are also
incompatible. Either int or long (but not both) may be compatible with
int32_t, but for your hypothetical implementation neither of them is.
> If a compiler regards all three types as fully equivalent, I don't think
> any diagnostic is required. Is there a requirement for a diagnostic if the
> types aren't fully equivalent?
I suppose that depends on what you mean by "fully equivalent".
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-10-01 17:19 -0400 |
| Message-ID | <muk7sk$n5h$1@dont-email.me> |
| In reply to | #71566 |
On 10/1/2015 4:30 PM, supercat@casperkitty.com wrote:
> On Thursday, October 1, 2015 at 2:57:33 PM UTC-5, David Brown wrote:
>> You can not only rename parameters, but you can also use different
>> typedefs on the types (as long as they are compatible).
>
> If a compiler deems types X and Y are sufficiently compatible that it does
> not issue a diagnostic if a parameter which is of type X in one declaration
> is specified as type Y in another, does that imply that for purposes of the
> Strict Aliasing Rule, memory written using type X must be readable as type
> Y?
"Sufficiently compatible" is a peculiar phrase. Two types
are compatible or they are not compatible; there's no such thing
as a pair of types that are 92% compatible.
Of course, two types that are compatible in one implementation
need not be compatible in another. `size_t' may or may not be
compatible with `unsigned int', for example.
(You might scratch out a notion of fractional compatibility by
appealing to a population of C implementations: "Types X and Y are
92% compatible because they are compatible types in 92% of all C
implementations, weighted by popularity, according to a survey
conducted by Marge Innovera." But that verges on the fanciful.)
> For example, by my understanding, it would be legal to have a compiler where
> "int", "long", and "int32_t" were all 32 bits, but which would nonetheless
> assume that given:
>
> int32_t blah(int32_t *p1, int *p2, long *p3)
> {
> *p1 = 0x00000001;
> *p2 = 0x00000100;
> *p3 = 0x00010000;
> return *p1 + *p2 + *p3;
> }
>
> the return value would always be 0x00010101. Would such a compiler be
> required to issue a diagnostic if the above code had been preceded by the
> declaration:
>
> int32_t blah(long *p1, int32_t *p2, int *p3);
>
> If a compiler regards all three types as fully equivalent, I don't think
> any diagnostic is required. Is there a requirement for a diagnostic if the
> types aren't fully equivalent?
A diagnostic is required. `long*' and `int*' are not compatible
types, even if they have identical representation (and even if `int'
and `long' have identical representation). Thus the two declarations
of blah() specify non-compatible types for the `p3' parameter, hence
specifying non-compatible types for blah() itself.
Furthermore, at least one of `p1' and `p2' must cause a similar
conflict. It is possible that `int32_t*' is compatible with `long*',
and possible that it is compatible with `int*', but it can't be
compatible with both simultaneously. (It might be compatible with
neither.) Again, the two declarations of blah() specify types that
are not compatible.
Compatible types have identical representations, but identity
of representation does not imply compatibility of type.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-01 15:38 -0700 |
| Message-ID | <9256d7fa-5b3e-4183-b071-d910254623ce@googlegroups.com> |
| In reply to | #71572 |
On Thursday, October 1, 2015 at 4:19:27 PM UTC-5, Eric Sosman wrote: > "Sufficiently compatible" is a peculiar phrase. Two types > are compatible or they are not compatible; there's no such thing > as a pair of types that are 92% compatible. I don't know enough about the wrinkles of C's type system to know whether type compatibility defines an equivalence relation in absolutely all cases, hence my use of hedged language. Are there any cases where a program could run without diagnostic in sub- dialects of the LLP64 dialect in which "int32_t" is aliased to "int" and run differently, also without diagnostic, in otherwise-identical sub- dialects where "int32_t" is aliased to "long"? Given that dialects in which both "int" and "long" are 32 bits are collectively referred to under the common name LLP64, would there be any problem with allowing a compiler to accept programs that use "int32_t" and "int" interchangeably as well as those that use "int32_t" and "long" interchangeably? On a related note, would anything forbid a perverse C implementation from having "int32_t" as an alias to "int", but "uint32_t" as an alias to "unsigned long"? I think the Standard specifies that if an unsigned integer type holds a value which is representable in the corresponding signed type, it may be accessed using a pointer of the signed type. Does that rule apply to "int32_t" and "uint32_t", or could a perverse but conforming implementation alias them to incompatible types? If one has two libraries which are supposed to act upon the same array of 32-bit values, and one library expects to receive a pointer to the array as "int*" and the other as "long*", is there any way via which code which will never need to run on any platform where "int" and "long" do not both have the same representation as "int32_t" can be written such that a compiler for such a system would not be allowed to mess with it?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-01 17:14 -0700 |
| Message-ID | <lny4fm15zu.fsf@kst-u.example.com> |
| In reply to | #71576 |
supercat@casperkitty.com writes:
> On Thursday, October 1, 2015 at 4:19:27 PM UTC-5, Eric Sosman wrote:
>> "Sufficiently compatible" is a peculiar phrase. Two types
>> are compatible or they are not compatible; there's no such thing
>> as a pair of types that are 92% compatible.
>
> I don't know enough about the wrinkles of C's type system to know whether
> type compatibility defines an equivalence relation in absolutely all cases,
> hence my use of hedged language.
>
> Are there any cases where a program could run without diagnostic in sub-
> dialects of the LLP64 dialect in which "int32_t" is aliased to "int" and
> run differently, also without diagnostic, in otherwise-identical sub-
> dialects where "int32_t" is aliased to "long"? Given that dialects in
> which both "int" and "long" are 32 bits are collectively referred to
> under the common name LLP64, would there be any problem with allowing a
> compiler to accept programs that use "int32_t" and "int" interchangeably
> as well as those that use "int32_t" and "long" interchangeably?
(It would have been simpler to refer to implementations in which both
int and long are 32 bits.)
The problem is that the compiler would be non-conforming. int32_t is
compatible with int *or* with long *or* with neither. It cannot be
compatible with both (since they are not compatible with each other.)
I *think* it's accurate to say that two integer types are compatible if
and only if they're the same type.
> On a related note, would anything forbid a perverse C implementation
> from having "int32_t" as an alias to "int", but "uint32_t" as an alias to
> "unsigned long"? I think the Standard specifies that if an unsigned
> integer type holds a value which is representable in the corresponding
> signed type, it may be accessed using a pointer of the signed type. Does
> that rule apply to "int32_t" and "uint32_t", or could a perverse but
> conforming implementation alias them to incompatible types?
Yes, N1570 7.20.1p1:
When typedef names differing only in the absence or
presence of the initial u are deļ¬ned, they shall denote
corresponding signed and unsigned types as described in 6.2.5;
an implementation providing one of these corresponding types
shall also provide the other.
> If one has two libraries which are supposed to act upon the same array of
> 32-bit values, and one library expects to receive a pointer to the array
> as "int*" and the other as "long*", is there any way via which code which
> will never need to run on any platform where "int" and "long" do not both
> have the same representation as "int32_t" can be written such that a
> compiler for such a system would not be allowed to mess with it?
I'm not sure.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-04 14:19 -0700 |
| Message-ID | <kfn8u7i8h7b.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71580 |
Keith Thompson <kst-u@mib.org> writes: > [snip] > > I *think* it's accurate to say that two integer types are > compatible if and only if they're the same type. Do you mean to exclude enumerated types? Enumerated types are compatibile with a signed or unsigned integer type (or char), but are nonetheless distinct types. If enumerated types are excluded, I believe the statement is right.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-04 15:01 -0700 |
| Message-ID | <lneghaxphm.fsf@kst-u.example.com> |
| In reply to | #71858 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> [snip]
>>
>> I *think* it's accurate to say that two integer types are
>> compatible if and only if they're the same type.
>
> Do you mean to exclude enumerated types? Enumerated types
> are compatibile with a signed or unsigned integer type (or
> char), but are nonetheless distinct types.
>
> If enumerated types are excluded, I believe the statement
> is right.
You're right, I glossed over enumerated types. (Actually I forgot
that they're classified as "integer types"; I should have checked.)
Actually, that raises a question. Given:
enum foo { zero, one, two };
let's assume that the compiler chooses to make `enum foo` compatible
with unsigned. Is there a practical difference between `enum
foo` being *compatible* with unsigned vs. being the *same type*
as unsigned (similar to a typedef)? Is there a C program that
would behave differently if `enum foo` and unsigned were the same
type rather than being distinct but compatible types?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-04 18:26 -0400 |
| Message-ID | <5611A77D.7050903@verizon.net> |
| In reply to | #71870 |
On 10/04/2015 06:01 PM, Keith Thompson wrote:
...
> Actually, that raises a question. Given:
>
> enum foo { zero, one, two };
>
> let's assume that the compiler chooses to make `enum foo` compatible
> with unsigned. Is there a practical difference between `enum
> foo` being *compatible* with unsigned vs. being the *same type*
> as unsigned (similar to a typedef)? Is there a C program that
> would behave differently if `enum foo` and unsigned were the same
> type rather than being distinct but compatible types?
I could find only a couple of places where the distinction between "same
type" and "compatible types" matters:
6.3.1.8p2: If two compatible types have different conversion ranks, the
result of the integer promotions will be the one with the higher rank.
However, without a typeof() operator, I don't see any way to use that
fact to cause a change in the observable behavior.
6.7p3: redefining a typedef is a constraint violation unless it's to the
same type; a type that's merely compatible isn't sufficient. It's not
clear to me that this was intentional.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-04 17:53 -0700 |
| Message-ID | <lnd1wuw2xo.fsf@kst-u.example.com> |
| In reply to | #71875 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 10/04/2015 06:01 PM, Keith Thompson wrote:
> ...
>> Actually, that raises a question. Given:
>>
>> enum foo { zero, one, two };
>>
>> let's assume that the compiler chooses to make `enum foo` compatible
>> with unsigned. Is there a practical difference between `enum
>> foo` being *compatible* with unsigned vs. being the *same type*
>> as unsigned (similar to a typedef)? Is there a C program that
>> would behave differently if `enum foo` and unsigned were the same
>> type rather than being distinct but compatible types?
>
> I could find only a couple of places where the distinction between "same
> type" and "compatible types" matters:
>
> 6.3.1.8p2: If two compatible types have different conversion ranks, the
> result of the integer promotions will be the one with the higher rank.
> However, without a typeof() operator, I don't see any way to use that
> fact to cause a change in the observable behavior.
Agreed, that doesn't seem to be a visible effect.
> 6.7p3: redefining a typedef is a constraint violation unless it's to the
> same type; a type that's merely compatible isn't sufficient. It's not
> clear to me that this was intentional.
It's probably intentional. For example, int[] and int[10] are
compatible. Redefining a typedef for one as a typedef for the other
would be confusing.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-10-04 18:37 -0400 |
| Message-ID | <AShQx.70721$_E1.59898@fx01.iad> |
| In reply to | #71870 |
On 10/4/15 6:01 PM, Keith Thompson wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
> > Keith Thompson <kst-u@mib.org> writes:
> >> [snip]
> >>
> >> I *think* it's accurate to say that two integer types are
> >> compatible if and only if they're the same type.
> >
> > Do you mean to exclude enumerated types? Enumerated types
> > are compatibile with a signed or unsigned integer type (or
> > char), but are nonetheless distinct types.
> >
> > If enumerated types are excluded, I believe the statement
> > is right.
>
> You're right, I glossed over enumerated types. (Actually I forgot
> that they're classified as "integer types"; I should have checked.)
>
> Actually, that raises a question. Given:
>
> enum foo { zero, one, two };
>
> let's assume that the compiler chooses to make `enum foo` compatible
> with unsigned. Is there a practical difference between `enum
> foo` being *compatible* with unsigned vs. being the *same type*
> as unsigned (similar to a typedef)? Is there a C program that
> would behave differently if `enum foo` and unsigned were the same
> type rather than being distinct but compatible types?
>
One big one, pointers, an enum foo* is a distinct type to unsigned*, and
not at all interchangable.
[toc] | [prev] | [next] | [standalone]
Page 7 of 17 — ← Prev page 1 … 5 6 [7] 8 9 … 17 Next page →
Back to top | Article view | comp.lang.c
csiph-web