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 10 of 17 — ← Prev page 1 … 8 9 [10] 11 12 … 17 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-04 14:43 -0700 |
| Message-ID | <lnio6mxqbv.fsf@kst-u.example.com> |
| In reply to | #71789 |
supercat@casperkitty.com writes:
> On Saturday, October 3, 2015 at 9:13:57 PM UTC-5, Keith Thompson wrote:
>> Certainly. (The common implementation of 2's-complement arithmetic has
>> wraparound semantics, but the standard says nothing about that.)
>
> Is there any standardized way by which a program can refuse compilation on
> any machine which defines narrowing conversion as doing anything other than
> two's-complement reduction?
No.
> If not, why does the Standard require that implementations must use one of
> three forms of integer representation?
This requirement was added in C99. The requirement addresses
representation of integers, not results of operations. I don't see any
specific discussion of this in the C99 Rationale.
All three permitted representations meet the requirement that values
within the range of a corresponding signed and unsigned type have the
same representation. I don't know of any other representation schemes
*in real-world use* that meet that requirement.
Probably all existing systems use one of the three forms (the vast
majority use 2's-complement), so that requirement imposed no significant
burden on implementations, and may permit writing portable code to work
with integer representations.
Imposing requirements on the results of overflowing computations would
be a different matter. The standard would have had either to require or
to forbid trapping on overflow, for example -- or make the behavior
implementation-defined. The committee chose not to do 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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-10-04 03:19 -0500 |
| Message-ID | <n6o11bp0j2984659t0k9csn25u1i23prt6@4ax.com> |
| In reply to | #71752 |
On Sat, 3 Oct 2015 18:23:48 -0400, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote:
>On 10/3/2015 5:58 PM, Robert Wessel wrote:
>> On Sat, 3 Oct 2015 17:27:26 -0400, Eric Sosman
>> <esosman@comcast-dot-net.invalid> wrote:
>>
>>> On 10/3/2015 5:11 PM, Robert Wessel wrote:
>>>> On Sat, 3 Oct 2015 10:02:01 -0700 (PDT), supercat@casperkitty.com
>>>> wrote:
>>>>
>>>>> On Friday, October 2, 2015 at 7:36:05 PM UTC-5, Keith Thompson wrote:
>>>>>> I don't know what you mean by "programs whose meaning would be
>>>>>> unambiguous".
>>>>>
>>>>> Consider the function:
>>>>>
>>>>> int blah(uint32_t x, uint32_t y, uint32_t z)
>>>>> {
>>>>> return x-y > z;
>>>>> }
>>>>>
>>>>> What is the value of "blah(2,3,1);"? In some dialects it is required to
>>>>> be 1; in others, it is required to be 0. I first used the term "dialect"
>>>>> used in reference to distinguish "signed char C" from "unsigned char C",
>>>>> but I think it is equally applicable to other variations in the type
>>>>> system as well.
>>>>
>>>>
>>>> uint32_t is a two's complement, 32-bit, unsigned binary integers on
>>>> all platforms where it's defined. On what platforms would blah(2,3,1)
>>>> *not* evaluate to 1?
>>>
>>> On a platform with an `int' of 33 or more non-padding bits.
>>>
>>> Exercise: Predict the outcome if `uint32_t' is replaced with
>>> `uint8_t'. See if your compiler agrees with your prediction.
>>>
>>> (By the way: `uint32_t' does *not* use two's complement.
>>> Exercise: Explain what the `u' stands for.)
>>
>>
>> That's certainly a bit of a brain fart... But they are conventional
>> binary (all the signed types are required to be two's comp), and those
>> all have defined behavior on overflow. Padding bits don't matter. 2-3
>> for 32 bit unsigned binary numbers must result in 0xffffffff. And on
>> platform with 33 bit ints, uin32_t would not be defined in a
>> conforming implementation (unless there were also an exactly 32 bit
>> type other than int).
>
> It is possible (though perverse) for an implementation to provide
>both `uint32_t' and a 33-bit `int'. The latter would require padding
>bits, but the Standard allows those for the standard integer types.
>Besides, 33 is just a lower bound: Consider a 48- or 64-bit `int' if it
>makes things clearer.
>
> On a platform with a wide `int', the integer promotions will
>convert `uint32_t' to `int' before performing the subtraction. The
>subtraction will then be carried out according to the `int' rules, and
>will yield a negative value; this will compare less than 1 and the
>function will return 0.
>
> Question for the experts: Do the exact-width signed integer types
>have defined behavior on overflow, as asserted above? They must
>use two's complement representation, yes, but are they required to
>wrap around silently rather than fly off to UB-land?
That was inartfully worded. I did not mean to imply that the signed
numbers have defined wrap-around behavior, the parenthetical just
confuses things.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-04 14:48 -0700 |
| Message-ID | <kfnzizy71ba.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71653 |
Keith Thompson <kst-u@mib.org> writes: > [..concerning pointer conversion in C90..] > > The C90 standard discusses pointer conversions in section 6.2.2.3; > it doesn't even mention converting a pointer of one type to a > pointer of another type (other than to and from void*). > Apparently the behavior of converting an int* to a long* was > undefined in C90. [snip] Pointer conversions in C90 are (also?) detailed in section 6.3.4. I believe the rules are essentially the same as in C99, just in a different place.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-04 16:26 -0700 |
| Message-ID | <lnk2r2w6zq.fsf@kst-u.example.com> |
| In reply to | #71866 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> [..concerning pointer conversion in C90..]
>>
>> The C90 standard discusses pointer conversions in section 6.2.2.3;
>> it doesn't even mention converting a pointer of one type to a
>> pointer of another type (other than to and from void*).
>> Apparently the behavior of converting an int* to a long* was
>> undefined in C90. [snip]
>
> Pointer conversions in C90 are (also?) detailed in section 6.3.4.
> I believe the rules are essentially the same as in C99, just in a
> different place.
You're right, I didn't see that. C90 documents pointer conversion in
the section on the cast operator; C99 moved it to the section on
conversions.
The wording changed, but in a quick glance I didn't see any significant
changes in semantics.
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-02 13:21 -0700 |
| Message-ID | <lnlhbl10ot.fsf@kst-u.example.com> |
| In reply to | #71601 |
Eric Sosman <esosman@comcast-dot-net.invalid> writes:
[...]
> I'm confused by your use of "LLP64" in connection with 32-bit types,
> so I won't address this one.
As I understand it, "LLP64" is a common name for a certain "data
model" (which happens to be the one used by 64-bit Windows) in
which int and long are both 32 bits, and long long and pointers
are 64 bits. It's also referred to as "IL32P64".
64-bit Linux commonly uses "LP64" (aka "I32LP64") in which int is
32 bits, and long, long long, and pointers are all 64 bits.
The terms omit a lot of information if you're not familiar with them.
I already mentioned that "32-bit int and long" would have expressed
supercat's intent more clearly, but I suppose "LLP64" might be
clearer to someone who's already familiar with that terminology.
https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models
[...]
--
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-02 17:05 -0400 |
| Message-ID | <mumre9$htn$1@dont-email.me> |
| In reply to | #71639 |
On 10/2/2015 4:21 PM, Keith Thompson wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
> [...]
>> I'm confused by your use of "LLP64" in connection with 32-bit types,
>> so I won't address this one.
>
> As I understand it, "LLP64" is a common name for a certain "data
> model" (which happens to be the one used by 64-bit Windows) in
> which int and long are both 32 bits, and long long and pointers
> are 64 bits. It's also referred to as "IL32P64".
Well, he didn't just write "LLP64," but "sub-dialects of the
LLP64 dialect in which ..." I still find that confusing, and I
still won't try to answer a question I can't defog. Maybe he
can get his answers from less-confusable people than me.
--
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-02 15:11 -0700 |
| Message-ID | <32488046-f029-4722-ac30-b99be6a05b26@googlegroups.com> |
| In reply to | #71642 |
On Friday, October 2, 2015 at 4:05:21 PM UTC-5, Eric Sosman wrote: > Well, he didn't just write "LLP64," but "sub-dialects of the > LLP64 dialect in which ..." I still find that confusing, and I > still won't try to answer a question I can't defog. Maybe he > can get his answers from less-confusable people than me. Although C is often referred to as a language, it is in practice a label given to a variety of dialects which have some common features. I would suggest that if two compilers both implement a common language and one of them is required by the language standard to interpret a particular construct a certain way, it should be at least permissible for the other to do likewise. I have no problem with the fact that the Standard does not require any compiler to accept both void foo(uint32_t x); void foo(int x); and void bar(int32_t x); void bar(long x); I can see good reasons for the Standard to recognize the existence of at least three C dialects where both "int" and "long" are 32 bits with no padding: 1. Those where "int32_t" is compatible with "int" but not "long". 2. Those where "int32_t" is compatible with "long" but not "int". 3. Those where "int32_t" is not compatible with "int" nor "long". Such fragmentation of the language into dialects would not be a particular problem if a compiler were allowed to define a dialect that was a superset of the above: 4. Those where "int32_t" is compatible with both "int" and "long". Users of such a compiler could then ignore any distinctions among the above dialects. As it is, both 1 and 2 are proper supersets of 3, but the Standard says that no Standard-C conforming dialect can be a proper subset of both 1 and 2. IMHO, the view that C should be viewed as a single language, rather than as a collection of dialects, is detrimental to the development of a useful core language where compilers would be allowed the freedom to support or reject various constructs, but where: 1. Any feature which was supported by a compiler, implemented using a syntax which had no pre-existing meaning on any other compiler, and met a fairly low bar for usefulness could be standardized such that any compiler which accepted that syntax would be required to assign the same meaning to it. The only burden that such standardization would impose on any compiler vendor would be a requirement to refrain from using the same syntax for anything other than the standard meaning. 2. In cases where some compilers provide some functionality using some syntax but other compilers are forbidden from using that same syntax for the same purpose, a new syntax would be defined which would allow code to specify the required behavior with implementation-independent meaning. It's unlikely that any compiler would ever support all behaviors, and many behaviors would likely never be supported by all compilers, but the code written using such features would be guaranteed to have the same meaning on all implementations that accept it. I suspect that a lot of the resistance toward such standardization comes from the maintainers of obscure platforms who are afraid that if C becomes too strongly attached to the notion of 8/16/32/64-bit types then nobody will write code that can work with their 36-bit hardware. I would posit that such people should embrace rather than oppose the recognition of platform- independent features, since providing a standardized way of specifying a such things would make it possible to write a compiler for x86 that could run code a lot of code written for a 36-bit machine, or write a compiler for a 36-bit platform which could run a lot of code written for 32-bit machines.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-02 20:55 -0700 |
| Message-ID | <lnsi5szjuy.fsf@kst-u.example.com> |
| In reply to | #71645 |
supercat@casperkitty.com writes:
> On Friday, October 2, 2015 at 4:05:21 PM UTC-5, Eric Sosman wrote:
>> Well, he didn't just write "LLP64," but "sub-dialects of the
>> LLP64 dialect in which ..." I still find that confusing, and I
>> still won't try to answer a question I can't defog. Maybe he
>> can get his answers from less-confusable people than me.
>
> Although C is often referred to as a language, it is in practice a label given
> to a variety of dialects which have some common features.
If you're going to refer to implementation-defined variations as
"dialects", you should make it very clear what you mean, preferably with
specific examples.
> I would suggest that
> if two compilers both implement a common language and one of them is required
> by the language standard to interpret a particular construct a certain way, it
> should be at least permissible for the other to do likewise.
That's a very general and seemingly reasonable statement that IMHO has
led you to some unreasonable conclusions.
> I have no
> problem with the fact that the Standard does not require any compiler to
> accept both
>
> void foo(uint32_t x);
> void foo(int x);
I presume you meant int32_t, not uint32_t.
> and
>
> void bar(int32_t x);
> void bar(long x);
>
> I can see good reasons for the Standard to recognize the existence of at
> least three C dialects where both "int" and "long" are 32 bits with no
> padding:
>
> 1. Those where "int32_t" is compatible with "int" but not "long".
> 2. Those where "int32_t" is compatible with "long" but not "int".
> 3. Those where "int32_t" is not compatible with "int" nor "long".
I wouldn't call those "dialects". Rather, they're variations in one
particular implementation-defined choice, namely the underlying type for
int32_t. But ok, let's call them dialects for the moment.
> Such fragmentation of the language into dialects would not be a particular
> problem if a compiler were allowed to define a dialect that was a superset
> of the above:
>
> 4. Those where "int32_t" is compatible with both "int" and "long".
For that to be possible, either (a) int and long would have to be
compatible with each other (at least on some implementations), or (b)
we'd have to break transitivity of compatibility for integer types. I
dislike either alternative.
For (a), I'm guessing that you'd want int and long to be treated as
compatible types (essentially the *same* type) in any implementation
where they happen to have the same representation. Likewise, I presume,
for any other pair of integer types.
That would mean that if I accidentally wrote:
int n;
/* hundreds of lines of code */
long *ptr = &n;
then the compiler probably wouldn't warn me *if* I happened to use a
compiler where they're both 32 bits. Then when I try to recompile on a
64-bit system, it fails to compile.
I *like* the fact that types can be distinct even if they have the same
representation.
As for int32_t, I do agree that there's a potential problem. The intN_t
types were added on top of C's existing system of integer types, and
each of them is defined as a typedef of one of those existing types.
That means that the choice of *which* type int32_t is compatible with
will vary from one compiler to another, and if both int and long qualify
then the choice is arbitrary. Which means that if I write code that
depends on which other integer types int32_t is compatible with, I can
get into trouble. (This can be an issue for generic selections, which
require all the listed types to be distinct.)
Your proposal would to extend that problem to the predefined types.
An alternative would have been to define [u]intN_t and friends as
distinct types, perhaps using some newly invented syntax for defining
new integer types.
But there's an incredibly simple solution, at least to the narrow
problem you mentioned:
void foo(int32_t x);
void foo(int x);
Just don't do that. It's (mildly) annoying that the above may or may
not compile depending on how int32_t is defined, but the solution is to
use the same type name in both declarations. We've just spent a great
deal of time discussing how to do 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 | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-03 12:00 -0700 |
| Message-ID | <f6e37ed1-695e-42bd-87ad-a480cdae4e1e@googlegroups.com> |
| In reply to | #71656 |
On Friday, October 2, 2015 at 10:55:44 PM UTC-5, Keith Thompson wrote:
> That would mean that if I accidentally wrote:
>
> int n;
> /* hundreds of lines of code */
> long *ptr = &n;
>
> then the compiler probably wouldn't warn me *if* I happened to use a
> compiler where they're both 32 bits. Then when I try to recompile on a
> 64-bit system, it fails to compile.
My intention is by no means to require that compilers be required to regard
"int" and "long" as equivalent, but merely that the Standard recognize that
a compiler may *at its option* document the types as equivalent (likewise
on 16-bit systems for "short" and "int"), preferably defining macros with
some standardized names if it does so, and that code which tests for a
macro indicating such equivalence may, if the macro is defined, legitimately
regard the types as equivalent.
> I *like* the fact that types can be distinct even if they have the same
> representation.
I like the fact that types *can* be distinct. Indeed, I wish C provided an
ability to create types with the same storage layout as other type without
then being equivalent; such a thing could greatly facilitate optimizations,
though for such a feature to be really useful it should be coupled with a an
"__unalias(void *p, size_t length)" function or intrinsic, such that the
result of writing a block of memory as any type, calling __unalias on the
block, and then reading the block as any other type would be equivalent to
having all of the writes and reads performed on the underlying "char"
representations. I think such functionality could be achieved by:
void __unalias(void *p, size_t length)
{
unsigned char *pp = p;
while(length--)
{
*pp+=0; // Even if *pp was part of some other type, I think this
// would force the compiler to treat it as "unsigned char".
}
}
though of course on many compilers that would be ridiculously inefficient.
On many compilers, __unalias() could be a macro that expands to nothing;
only in rare cases would it actually have to generate any code other beyond
flushing any cached register values that might be aliased to any memory in
the indicated range.
> As for int32_t, I do agree that there's a potential problem. The intN_t
> types were added on top of C's existing system of integer types, and
> each of them is defined as a typedef of one of those existing types.
> That means that the choice of *which* type int32_t is compatible with
> will vary from one compiler to another, and if both int and long qualify
> then the choice is arbitrary. Which means that if I write code that
> depends on which other integer types int32_t is compatible with, I can
> get into trouble. (This can be an issue for generic selections, which
> require all the listed types to be distinct.)
While it would certainly be desirable to be consistent in one's use of
integer types, code sometimes has to deal with libraries written by other
people who don't always use the same types, and for which source code may
not always be available. If a system only has one representation for 32-
bit unsigned values, and I have a method (object code only) written by
someone else with a signature:
void do_something(int command, void* buffer, size_t size);
and a certain command is documented as filling the supplied buffer with
32-bit values, but doesn't specify which particular type it used, should
code be required to use something like the nasty __unalias routine above
to force the compiler to regard everything in the buffer as having
effective type "unsigned char" prior to reading it as any 32-bit type?
Which is more helpful:
1. Having a means by which code can say "I need to be able to interpret
the bytes in this buffer as type X regardless of how it was written", or
2. Allowing a whole-program optimizer that can somehow figure out that a
buffer cannot have been written with e.g. "unsigned long" or any form
of "char", would be entitled to regard as unreachable any code which
tried to read out the buffer as "unsigned long" unless the programmer
has taken the precaution of byte-copying the buffer in a way that would
prevent the compiler from keeping information about the effective type.
> An alternative would have been to define [u]intN_t and friends as
> distinct types, perhaps using some newly invented syntax for defining
> new integer types.
What I would prefer as a default behavior would be to have a compiler regard
the xxx_t types as being distinct from "int" and company for purposes of
generating warnings, but as being compatible types for purposes of aliasing
optimizations.
> But there's an incredibly simple solution, at least to the narrow
> problem you mentioned:
>
> void foo(int32_t x);
> void foo(int x);
>
> Just don't do that. It's (mildly) annoying that the above may or may
> not compile depending on how int32_t is defined, but the solution is to
> use the same type name in both declarations. We've just spent a great
> deal of time discussing how to do that.
If one has control over both the caller-side and callee-side code, that's
great. If one has object files and headers for one piece of outside code
that needs to receive a buffer pointer as type "int*" and another that
needs to receive it as "long*", and if there is no realistic likelihood of
migrating the code to work on any platform where those types don't have
the same representation, I would see value in saying that a compiler may,
if the implementer chooses, regard as legitimate(*) a program which needs to
exchange data in the above fashion, though I would make a slight tweak to
the C Standard with regard to ill-formed programs:
Compilers must, via some implementation-defined means, indicate whether
a program is considered ill-formed, such that:
1. If a compiler is required to regard a program as well-formed, the
compiler must via the aformentioned means, indicate that.
2. If a compiler is required to regard a program as ill-formed, the
compiler must via the aformentioned means, indicate that.
3. If a program makes use of optional or implementation-defined features
such that compilers could legitimately regard it as well-formed or
ill-formed, a compiler must either indicate that a program is ill-
formed or else implement the behavior defined by the Standard for
optional or implementation-defined features used thereby.
I would suggest that equivalence any particular combinations of types which
could legally have equivalent behavior (e.g. a 32-bit "int", "int32_t", and
a 32-bit "long") should be regarded as an "optional feature", such that a
compiler would be allowed to accept or reject:
void foo(int *x);
void foo(int32_t *x);
and *independently* accept or reject:
void foo(long *x);
void foo(int32_t *x);
but if it accepts the former it would be required to regard the types as
equivalent everywhere (including aliasing), and if it accepts the latter
it would likewise be required to regard those types as equivalent everywhere.
The requirement given above is probably closer to the intention of the spec
than its meaningless "issue at least one diagnostic", but would be far more
useful. At present, if a programmer writes:
int main(int argc)
{
if (argc == 5)
printf("Hey!");
else
{
int p;
int32_t *q = &p;
*q=23;
}
return 0;
}
there is no requirement that a compiler indicate whether it regards the
assignment of &p to q as valid. The compiler must output a diagnostic
message if it doesn't, but since a compiler which simply printed a random
message at the end of every compilation (even when fed a strictly-conforming
program) would satisfy that requirement I don't see it as very useful.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-03 16:52 -0700 |
| Message-ID | <ln7fn3zf14.fsf@kst-u.example.com> |
| In reply to | #71705 |
supercat@casperkitty.com writes:
> On Friday, October 2, 2015 at 10:55:44 PM UTC-5, Keith Thompson wrote:
>> That would mean that if I accidentally wrote:
>>
>> int n;
>> /* hundreds of lines of code */
>> long *ptr = &n;
>>
>> then the compiler probably wouldn't warn me *if* I happened to use a
>> compiler where they're both 32 bits. Then when I try to recompile on a
>> 64-bit system, it fails to compile.
>
> My intention is by no means to require that compilers be required to regard
> "int" and "long" as equivalent, but merely that the Standard recognize that
> a compiler may *at its option* document the types as equivalent (likewise
> on 16-bit systems for "short" and "int"), preferably defining macros with
> some standardized names if it does so, and that code which tests for a
> macro indicating such equivalence may, if the macro is defined, legitimately
> regard the types as equivalent.
You keep using the word "equivalent". It's not clear what that's
supposed to mean. Do you mean "compatible" (a term that's defined
in the Standard)?
In C as it's currently defined, int and long are *never* compatible.
I wouldn't want to change that. (And of course that eliminates
the need for a macro that tells me whether they're equivalent --
other than __STDC__.)
>> I *like* the fact that types can be distinct even if they have the same
>> representation.
>
> I like the fact that types *can* be distinct. Indeed, I wish C provided an
> ability to create types with the same storage layout as other type without
> then being equivalent; such a thing could greatly facilitate optimizations,
> though for such a feature to be really useful it should be coupled with a an
> "__unalias(void *p, size_t length)" function or intrinsic, such that the
> result of writing a block of memory as any type, calling __unalias on the
> block, and then reading the block as any other type would be equivalent to
> having all of the writes and reads performed on the underlying "char"
> representations. I think such functionality could be achieved by:
>
> void __unalias(void *p, size_t length)
> {
> unsigned char *pp = p;
> while(length--)
> {
> *pp+=0; // Even if *pp was part of some other type, I think this
> // would force the compiler to treat it as "unsigned char".
> }
> }
>
> though of course on many compilers that would be ridiculously inefficient.
> On many compilers, __unalias() could be a macro that expands to nothing;
> only in rare cases would it actually have to generate any code other beyond
> flushing any cached register values that might be aliased to any memory in
> the indicated range.
You're proposing a *lot* of complex machinery for, in my opinion, not
much benefit.
You can define a new type that's distinct from any other type by
defining a struct. That doesn't give you integer operations, of course.
Then again, if you want C++, you know where to find it.
>> As for int32_t, I do agree that there's a potential problem. The intN_t
>> types were added on top of C's existing system of integer types, and
>> each of them is defined as a typedef of one of those existing types.
>> That means that the choice of *which* type int32_t is compatible with
>> will vary from one compiler to another, and if both int and long qualify
>> then the choice is arbitrary. Which means that if I write code that
>> depends on which other integer types int32_t is compatible with, I can
>> get into trouble. (This can be an issue for generic selections, which
>> require all the listed types to be distinct.)
>
> While it would certainly be desirable to be consistent in one's use of
> integer types, code sometimes has to deal with libraries written by other
> people who don't always use the same types, and for which source code may
> not always be available. If a system only has one representation for 32-
> bit unsigned values, and I have a method (object code only) written by
> someone else with a signature:
>
> void do_something(int command, void* buffer, size_t size);
>
> and a certain command is documented as filling the supplied buffer with
> 32-bit values, but doesn't specify which particular type it used, should
> code be required to use something like the nasty __unalias routine above
> to force the compiler to regard everything in the buffer as having
> effective type "unsigned char" prior to reading it as any 32-bit type?
If a library doesn't have adequate documentation, no change to the
language is going to make it easy to use. If a library provides
a function only as object code, without so much as a .h file that
declares it, that's the library's problem. (I don't think I've ever
encountered such a library; have you?)
> Which is more helpful:
>
> 1. Having a means by which code can say "I need to be able to interpret
> the bytes in this buffer as type X regardless of how it was written", or
>
> 2. Allowing a whole-program optimizer that can somehow figure out that a
> buffer cannot have been written with e.g. "unsigned long" or any form
> of "char", would be entitled to regard as unreachable any code which
> tried to read out the buffer as "unsigned long" unless the programmer
> has taken the precaution of byte-copying the buffer in a way that would
> prevent the compiler from keeping information about the effective type.
>
>> An alternative would have been to define [u]intN_t and friends as
>> distinct types, perhaps using some newly invented syntax for defining
>> new integer types.
>
> What I would prefer as a default behavior would be to have a compiler regard
> the xxx_t types as being distinct from "int" and company for purposes of
> generating warnings, but as being compatible types for purposes of aliasing
> optimizations.
Then talk to the compiler vendors about the warnings you want.
Currently, C *never* requires warnings. Syntax errors and constraint
violations require diagnostics, which may be either fatal or non-fatal;
any such violation permits a compiler to reject the program altogether.
>> But there's an incredibly simple solution, at least to the narrow
>> problem you mentioned:
>>
>> void foo(int32_t x);
>> void foo(int x);
>>
>> Just don't do that. It's (mildly) annoying that the above may or may
>> not compile depending on how int32_t is defined, but the solution is to
>> use the same type name in both declarations. We've just spent a great
>> deal of time discussing how to do that.
>
> If one has control over both the caller-side and callee-side code, that's
> great. If one has object files and headers for one piece of outside code
> that needs to receive a buffer pointer as type "int*" and another that
> needs to receive it as "long*", and if there is no realistic likelihood of
> migrating the code to work on any platform where those types don't have
> the same representation,
[snip]
If you have headers and object files for this outside code, then a
compiler is unlikely to perform optimization across
[...]
> I would suggest that equivalence any particular combinations of types which
> could legally have equivalent behavior (e.g. a 32-bit "int", "int32_t", and
> a 32-bit "long") should be regarded as an "optional feature", such that a
> compiler would be allowed to accept or reject:
>
> void foo(int *x);
> void foo(int32_t *x);
>
> and *independently* accept or reject:
>
> void foo(long *x);
> void foo(int32_t *x);
>
> but if it accepts the former it would be required to regard the types as
> equivalent everywhere (including aliasing), and if it accepts the latter
> it would likewise be required to regard those types as equivalent everywhere.
If by "equivalent" you mean "compatible", then I disagree. Different
libraries using different types can be a problem; your proposed solution
is IMHO worse.
> The requirement given above is probably closer to the intention of the spec
> than its meaningless "issue at least one diagnostic", but would be far more
> useful. At present, if a programmer writes:
>
> int main(int argc)
> {
> if (argc == 5)
> printf("Hey!");
> else
> {
> int p;
> int32_t *q = &p;
> *q=23;
> }
> return 0;
> }
>
> there is no requirement that a compiler indicate whether it regards the
> assignment of &p to q as valid. The compiler must output a diagnostic
> message if it doesn't, but since a compiler which simply printed a random
> message at the end of every compilation (even when fed a strictly-conforming
> program) would satisfy that requirement I don't see it as very useful.
Sure, a compiler can be conforming without being useful.
It is implementation-defined whether int and int32_t are compatible,
which means that bad code like the above may or may not be diagnosed. A
compiler that remembers that q was defined as an int32_t*, and that
issues a warning based on that, could be quite useful. A change to the
standard that would mandate such a warning would IMHO be a good thing,
but I'm not sure how to do that without breaking existing valid code
and/or making the language unreasonably complicated.
--
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:40 -0700 |
| Message-ID | <kfn4mi68g8i.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71601 |
Eric Sosman <esosman@comcast-dot-net.invalid> writes:
> On 10/1/2015 6:38 PM, supercat@casperkitty.com wrote:
>> 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.
>
> In each implementation, "compatible" induces an equivalence
> relation on types. Implementations may disagree about which types
> are or are not compatible, so the equivalence relations proffered
> by different implementations may differ, but within any single
> implementation the equivalence relation exists.
This statement is either wrong or misleading. The compatibility
relationship is symmetric and reflexive, but not transitive.
There are lots of examples (using ~ to mean is compatible with):
(int[3]) ~ (int[]) and (int[]) ~ (int[5]),
but (int[3]) !~ (int[5])
(int (int)) ~ (int ()) and (int ()) ~ (int (double)),
but (int (int)) !~ (int (double))
two enumerated types may each be compatible with (int),
but still not compatible with each other. (I agree
the Standard is a little fuzzy on this one, but
certainly I don't find anything in the Standard that
says two different enumerated types are or can be
compatible; in the absence of any explicit wording
to the contrary, distinct types are normally held to
be not compatible, and each enumerated type is a
distinct type.)
The type (struct foo) in one translation unit may be
compatible with (struct foo) types in two other
translation units, yet the types in those other TUs
need not be compatible with each other.
It is true that type compatibility can be seen as /inducing/
an equivalence relationship. But that induced relationship
is not the same as type compatibility.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-01 22:02 -0400 |
| Message-ID | <mukof2$5kq$1@dont-email.me> |
| In reply to | #71564 |
On 10/01/2015 03:57 PM, David Brown wrote:
> 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).
Since the meaning is precisely the same, regardless of which names the
parameters are given, and regardless of which compatible type is used, I
have trouble understanding why you consider the lack of a warning to be
a problem.
If the committee had been stupid enough to allow parameter name
differences, despite making the parameter names meaningful outside of
the function definition, then I would see a point in your objection. But
they did nothing that foolish.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-02 10:09 +0100 |
| Message-ID | <mulhgo$dha$1@dont-email.me> |
| In reply to | #71584 |
On 02/10/2015 03:02, James Kuyper wrote:
> On 10/01/2015 03:57 PM, David Brown wrote:
[JK won't see this post as I have apparently been kill-filled. But it's
not specifically aimed at anybody, just debating some points.]
>> You can not only rename parameters, but you can also use different
>> typedefs on the types (as long as they are compatible).
>
> Since the meaning is precisely the same, regardless of which names the
> parameters are given, and regardless of which compatible type is used, I
> have trouble understanding why you consider the lack of a warning to be
> a problem.
It was suggested earlier in the thread that header declarations were a
source of API information in the absence of proper docs (something I've
had to rely before on although I've very rarely seen parameter names in
there).
So if that interface information for functions relies heavily on user
typedefs and parameter names in the header, then it's a big deal if the
compiler allows those to be utterly different from those in the
definition, perhaps because the two are out of sync.
Keeping them aligned by hand is error prone.
> If the committee had been stupid enough to allow parameter name
> differences, despite making the parameter names meaningful outside of
> the function definition, then I would see a point in your objection. But
> they did nothing that foolish.
Apparently they /have/ allowed parameter name differences, unless all
the compilers I've tried are non-conforming. Maybe they did so because
the practice was widespread and they saw no harm in it either.
Take this example of a header prototype derived by copy&paste from a
definition:
typedef int Hours;
typedef int Minutes;
typedef int Seconds;
void set_alarm(Hours h, Minutes m, Seconds d);
However, someone decides to change the parameter order in the definition to:
void set_alarm(Seconds d, Minutes m, Hours h) {...}
and they forget to change the header. But it compiles with no errors. It
might even pass tests, if they call it with 7:06:10 (ie.
set_alarm(10,6,7) according to the function def) and it triggers at 7:06:10.
Someone who can only see the header, will on the other hand get
completely the wrong idea as to how it is called. If they want to set an
alarm for 7:06:10, the headers suggests they should use set_alarm(7,6,10).
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-02 08:19 -0700 |
| Message-ID | <lntwq91enr.fsf@kst-u.example.com> |
| In reply to | #71587 |
Bartc <bc@freeuk.com> writes:
[...]
> It was suggested earlier in the thread that header declarations were a
> source of API information in the absence of proper docs (something I've
> had to rely before on although I've very rarely seen parameter names in
> there).
Or rather, in addition to proper docs.
[...]
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-10-02 03:17 -0700 |
| Message-ID | <7356e08f-df5f-4727-91cb-a004c9487758@googlegroups.com> |
| In reply to | #71584 |
On Friday, October 2, 2015 at 3:02:26 AM UTC+1, James Kuyper wrote: > Since the meaning is precisely the same, regardless of which names the > parameters are given, and regardless of which compatible type is used, I > have trouble understanding why you consider the lack of a warning to be > a problem. > atan2(y, x) and atan2(x, y) mean different things to a human, though not to a machine. If they're not in synch, a warning or even an error is perfectly reasonable.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-02 13:02 +0200 |
| Message-ID | <mulo47$5id$1@dont-email.me> |
| In reply to | #71584 |
On 02/10/15 04:02, James Kuyper wrote:
> On 10/01/2015 03:57 PM, David Brown wrote:
>> 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).
>
> Since the meaning is precisely the same, regardless of which names the
> parameters are given, and regardless of which compatible type is used, I
> have trouble understanding why you consider the lack of a warning to be
> a problem.
The meaning to the compiler is exactly the same - but the meaning to
someone reading (or writing) code is completely different. Many warning
messages that compilers can give are for code whose meaning in C is
perfectly clear, well-defined and unambiguous, but which is wrong or at
least confusing for the programmer. For example, compilers (with
appropriate flags enabled) could warn on "if (x = 2) ...", since the
programmer probably meant to write "if (x == 2) ...". I would put a
warning on such mismatches of parameter names in the same category.
> If the committee had been stupid enough to allow parameter name
> differences, despite making the parameter names meaningful outside of
> the function definition, then I would see a point in your objection. But
> they did nothing that foolish.
>
I can understand that the committee did not want to make the names
meaningful outside of the definitions. I don't think that was a good
decision (I would have preferred mismatches to require a diagnostic at
least), but I believe I can understand why they did it. However, there
is nothing to stop a compiler adding non-default warning options to
enhance checking in code, to help programmers write safer and more
consistent code. People who /want/ to have mismatches, or omit
parameter names, can continue to do so - that is their standards-given
right. And people who want to enforce consistency and check for
accidental mistakes could do so using the warning flags.
(Obviously the place to ask for such a feature is the gcc bugzilla
wishlists, but that does not mean that it cannot be discussed here. It
turns out that there is an old enhancement request already in gcc
bugzilla, which was closed as "won't fix" - with arguments that I
strongly disagree with.
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19994>)
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-10-01 18:33 -0700 |
| Message-ID | <MPG.30777eb6791731846a@news.eternal-september.org> |
| In reply to | #71543 |
James Kuyper wrote: Re proposal to automatically generate a header containing the public functions in a module > 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. In addition, any type definitions* (both typedefs and new types) that are used in the function declarations should also be considered part of the public interface of the module and should be placed in the generated include file. * and, dare I say it, macro definitions. > 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. Except for checking parameter names.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-10-01 11:17 -0400 |
| Message-ID | <mujin9$tpa$1@dont-email.me> |
| In reply to | #71536 |
On 10/1/2015 10:05 AM, ais523 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.)
One drawback might be that it could become clumsy or even
difficult to put comments into the header that were not already
present in the source. Since header comments are frequently used
as API documentation (I'm not saying they're always adequate, but
they're often (ab)used this way), writing such comments should be
as easy as possible. You could run the header-generator once and
then edit the .h file, but this sort of clashes with the idea of
having header-generation as part of the "make" process. Or you
could invent a special markup in the .c files to indicate which
comments should get copied into the generated .h, but that makes
it more rather than less burdensome to write such comments.
As described, the tool presupposes a one-to-one correspondence
between .c files and .h files, but this isn't always a good model.
Maybe you've got a math library with code for a few hundred special
functions; do you really want a separate header for every function?
In the Standard C library we have <math.h>, not <sin.h> and <tan.h>
and <sqrt.h> and ... So, the tool should be able to generate one .h
from multiple .c's. That's not so hard, but it raises the comment
issue again: Each .c file may have comments for its own functions,
but where are the comments that apply to no single .c but to the
package as a whole? In Java, the documentation-extraction tool
ran across a similar problem, and eventually had to invent special
file names to hold commentary that belonged to a whole suite of
source files rather than to any single one of them. A header generator
for C could adopt a similar convention -- but is the extra burden
worth the trouble?
It's reasonably straightforward to extract function declarations
from function definitions, but which data type definitions should
also make it into the header? If you've got a suite of functions
that manipulate the nodes of a red-black tree, say, you might want
to publish a `struct redblacknode' or something of the kind by declaring
the type in the header. If so, the declaration belongs *only* in
the header -- so from what .c file should you extract it? Referring
again to the Standard C library (and supposing it's written in C),
which .c source file holds the `struct tm' declaration? Again, there
could be special markup: Maybe suppress the .c's declaration with
`#ifdef MOVE_TO_GENERATED_HEADER' to draw the tool's attention while
making the content invisible to the compiler -- but again, complexity
(and perhaps hokiness) is increased.
It's not uncommon for a library to have separate headers for the
public API and for the private internals. Since C lacks anything like
a "package-private" access level, the public and internal functions
all look the same to a tool: They're all defined at file scope and
with external linkage. How should the tool determine which belong in
"public.h" and which belong in "private.h"? Yet more special markup?
I think you're right in guessing at why tools of this kind seem
to be dwindling away: They were useful as a first step in modernizing
big existing collections of K&R code, but not clever enough to deal
with other (and perhaps quirkier) software engineering issues. Once
everybody started writing prototypes, the need for mechanical generation
pretty much died out. I can see (and value) a tool of this sort as a
way to get a head start on a big task, but I can't see it as an ongoing
component of a repeated build process.
IMHO, my two cents, YMMV, etc.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-01 17:06 +0100 |
| Message-ID | <mujli3$9d6$1@dont-email.me> |
| In reply to | #71536 |
On 01/10/2015 15:05, ais523 wrote: > Keith Thompson wrote: >> It's a clever idea, and it's perfectly reasonable to *think* that >> it's a good one. (It *is* a good idea to avoid having to write the same information twice. Do you think if C made it possible to write only a function definition, that anyone would waste time manually writing a prototype ever again?) > 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.) I don't use build systems. But I used a scheme that worked like this: * Source code was written in a source file with extension .cc, eg. module.cc. Function prototypes were not used. * A very simple preprocessor was used that took module.cc and generated: module.c Version of module.cc module.cl Local function prototypes module.cx Exported function prototypes module.cl should have been #included in the program.cc. module.cx would be #included in a shared header. module.c is compiled normally. (This preprocessor also took care of a few other annoyances with C, that's why it needed to be converted from .cc to .c. But this step also ensures the .cl and .cx files have been generated before compiling.) The preprocessor was kept ultra-simple by insisting function declarations were consistently written in a specified manner. Distributing source code is a bit harder: you need to distribute module.c with the contents of module.cl actually inserted into the file (otherwise people will wonder what that file was). And the shared header would need the .cx files inserted too. At that point, the files will be conventional C, but with meticulous correlation between the prototypes and corresponding definitions. You might then choose to make the preprocessing an on-off operation used to automatically generate the prototypes, then do further development on module.c. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-01 11:45 -0700 |
| Message-ID | <ln7fn62zs7.fsf@kst-u.example.com> |
| In reply to | #71547 |
Bartc <bc@freeuk.com> writes:
> On 01/10/2015 15:05, ais523 wrote:
>> Keith Thompson wrote:
>>> It's a clever idea, and it's perfectly reasonable to *think* that
>>> it's a good one.
>
> (It *is* a good idea to avoid having to write the same information
> twice. Do you think if C made it possible to write only a function
> definition, that anyone would waste time manually writing a prototype
> ever again?)
Yes, because a list of the function declarations without their full
definitions is useful as documentation.
[...]
--
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]
Page 10 of 17 — ← Prev page 1 … 8 9 [10] 11 12 … 17 Next page →
Back to top | Article view | comp.lang.c
csiph-web