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 9 of 17 — ← Prev page 1 … 7 8 [9] 10 11 … 17 Next page →
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-20 16:06 +0000 |
| Message-ID | <56266614.12275890@news.xs4all.nl> |
| In reply to | #72847 |
supercat@casperkitty.com wrote: > On Wednesday, October 14, 2015 at 6:00:48 AM UTC-5, Richard Bos wrote: > > Well, yes; but that doesn't require any change to the Standard. By the > > as-if rule, _any_ optimisation which doesn't change the behaviour of > > conforming code is allowed. This already includes your suggestion. As > > long as the code behaves _as if_ the values are 0, 1 and 2, it doesn't > > matter if, behind the scenes, they're really 2**0, 2**1 and 2**2. > > Indeed. We're both agreed that if a compiler can ascertain that a programmer > will never be able to see how values are stored, a compiler can substitute > whatever it likes. > > I would suggest that beyond those cases there are also cases where a > programmer might be able to see how things are stored, but *not care*; If you don't care, don't look at it. If you look at it, you signal to the computer that you are interested in the "official" value of these constants, and that, therefore, it should give them to you. There's no need whatsoever to make writing compilers that more difficult just because you don't understand optimisation. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-17 07:32 -0700 |
| Message-ID | <kfn1tctin05.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #72657 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> supercat@casperkitty.com writes:
>>> On Friday, October 9, 2015 at 4:10:31 PM UTC-5, Tim Rentsch wrote:
>>>> The Rationale document talks about enumerated types briefly. My
>>>> sense is they wanted to strike a balance between strict typing
>>>> and no typing, and this is the compromise point they reached.
>>>
>>> [snip] There are times when it's useful to have an enum type which
>>> is compatible with integer types. There are other times where it
>>> would be more useful to have an enum type which is deliberately
>>> not compatible with integer types. For enum types that are only
>>> used within a single compilation unit, it could even be helpful to
>>> have types whose representation and ordering is left up to the
>>> compiler [sharing values across compilation units is only useful
>>> if all units use the same representation, but for types used
>>> within a single unit such issues wouldn't apply].
>>
>> Note that the behavior described can be provided in a
>> conforming C implementation.
>
> How so? I think supercat is suggesting that given
>
> enum foo { zero, one };
>
> the values of zero and one are not necessarily 0 and 1, respectively,
> and `zero < one` is not necessarily true.
Oh. That wasn't the impression I got reading his earlier
posting, but on reading subsequent comments I believe you are
right. Why someone would want to do that is beyond me, but let
me go ahead and address the various questions.
First, regarding type compatibility. In most (all?) existing
implementations, each enumerated types is compatible with one of
the standard integer types (or char). But this doesn't have to
be true. An implementation could choose to create an extended
integer type for each distinct class of enumerated types, where
a class corresponds to enumerated types that are compatible if
they were declared in separate translation units. Since there is
no other way of naming these extended types, each enumerated type
is effectively compatible only with enumerated types that it
would be compatible with anyway. So the confusion between an
enumerated type and its corresponding compatible integer type
disappears.
Now that I think about it, maybe what was being asked for was not
non-compatibility but non-interoperability. That is, I took the
word "compatible" to have the same meaning as it does in the
Standard, but maybe it wasn't meant that way. Let me put this in
the category of "unorthodox semantics", which can (if desired) be
addressed in the same way as the other cases described below.
For other kinds of non-standard semantics, all of these can be
provided by means of an extension. Suppose for example we want
an enumerated type that is usable within a translation unit, but
not across translation units, ie, no inter-TU compatibility. To
accommodate such a constract, combine a typedef with an extension
that exploits using a reserved identifier, eg,
typedef enum _Local_only { ... } Foo;
Needless to say the semantics of this type can be whatever we
want, because declaring the reserved identifier _Local_only
(declared only as a tag, but still declared) puts the program
into the realm of undefined behavior. That may seem like a
cheat, but it works nicely syntactically, and at some level
is why, or at least one of the reasons why, the Standard goes to
the trouble of identifiying classes of reserved identifiers in
the first place, so they can be used to provide non-standard
semantics. So I think it is fair to say this suggestion follows
the spirit of the Standard as well as the letter of the Standard.
Obviously this idea can be expanded to provide other sorts of
unorthodox or non-standard semantics for enumerated types, if
such are desired.
That all make sense?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-17 07:51 -0700 |
| Message-ID | <344dd69b-48f1-4e81-988a-31f775717bc7@googlegroups.com> |
| In reply to | #73147 |
On Saturday, October 17, 2015 at 9:32:58 AM UTC-5, Tim Rentsch wrote:
> > How so? I think supercat is suggesting that given
> >
> > enum foo { zero, one };
> >
> > the values of zero and one are not necessarily 0 and 1, respectively,
> > and `zero < one` is not necessarily true.
>
> Oh. That wasn't the impression I got reading his earlier
> posting, but on reading subsequent comments I believe you are
> right. Why someone would want to do that is beyond me, but let
> me go ahead and address the various questions.
...
> For other kinds of non-standard semantics, all of these can be
> provided by means of an extension....
>
> typedef enum _Local_only { ... } Foo;
>
> Needless to say the semantics of this type can be whatever we
> want, because declaring the reserved identifier _Local_only
> (declared only as a tag, but still declared) puts the program
> into the realm of undefined behavior.
Basically, one of the things I would like to see in C would be a range of
standardized extensions such that any implementation would be allowed to
include or not include any extension, but there would be a means via which
code could determine whether an extension was included (and perhaps include
an alternate, less efficient, way of implementing things in the absence of
an extension).
Further, I would like to see a category and syntax for extensions which
any compiler would be free to ignore, but which would allow compilers to
operate under more relaxed rules than would otherwise be applicable. If
no compilers presently have any #pragma or __pragma directives which start
with a certain prefix, the Standard could reserve those to future versions
of the Standard. Thus, for example:
enum __pragma(__UXC_arbitrary_strict_enum_nz) foo {zero, one};
would indicate that for this particular declaration, the value "one" could
be mapped to any other value [e.g. 255], and also that a compiler would be
entitled to write tests that would arbitrary yield true or false if the enum
were given any non-listed value. Was my example insufficiently clear as to
why this could be beneficial?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-17 15:51 -0700 |
| Message-ID | <ln1tct2jnu.fsf@kst-u.example.com> |
| In reply to | #73147 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> supercat@casperkitty.com writes:
>>>> On Friday, October 9, 2015 at 4:10:31 PM UTC-5, Tim Rentsch wrote:
>>>>> The Rationale document talks about enumerated types briefly. My
>>>>> sense is they wanted to strike a balance between strict typing
>>>>> and no typing, and this is the compromise point they reached.
>>>>
>>>> [snip] There are times when it's useful to have an enum type which
>>>> is compatible with integer types. There are other times where it
>>>> would be more useful to have an enum type which is deliberately
>>>> not compatible with integer types. For enum types that are only
>>>> used within a single compilation unit, it could even be helpful to
>>>> have types whose representation and ordering is left up to the
>>>> compiler [sharing values across compilation units is only useful
>>>> if all units use the same representation, but for types used
>>>> within a single unit such issues wouldn't apply].
>>>
>>> Note that the behavior described can be provided in a
>>> conforming C implementation.
>>
>> How so? I think supercat is suggesting that given
>>
>> enum foo { zero, one };
>>
>> the values of zero and one are not necessarily 0 and 1, respectively,
>> and `zero < one` is not necessarily true.
>
> Oh. That wasn't the impression I got reading his earlier
> posting, but on reading subsequent comments I believe you are
> right. Why someone would want to do that is beyond me,
Me too.
> but let
> me go ahead and address the various questions.
>
> First, regarding type compatibility. In most (all?) existing
> implementations, each enumerated types is compatible with one of
> the standard integer types (or char). But this doesn't have to
> be true. An implementation could choose to create an extended
> integer type for each distinct class of enumerated types, where
> a class corresponds to enumerated types that are compatible if
> they were declared in separate translation units. Since there is
> no other way of naming these extended types, each enumerated type
> is effectively compatible only with enumerated types that it
> would be compatible with anyway. So the confusion between an
> enumerated type and its corresponding compatible integer type
> disappears.
Even in the absence of extended integer types, the implementation's
choice of which predefined type a given enumerated type is compatible
with is arbitrary, and there's no way for a program to determine
which type was chosen. As far as I can see, that alone makes the
requirement nearly useless, unless you're willing to write code
that depends on the implementation-defined characteristcs of HCC.
(That's Hypothetical C Compiler if you were wondering.)
If I want enumerations that are compatible with a particular type
(say, unsigned short), I can do the equivelent anyway just by using
unsigned short objects:
enum /* anonymous */ { this, that, the_other };
typedef unsigned short enum_foo;
enum_foo obj = this;
Enumeration constants aren't tied to the enumerated type anyway.
> Now that I think about it, maybe what was being asked for was not
> non-compatibility but non-interoperability. That is, I took the
> word "compatible" to have the same meaning as it does in the
> Standard, but maybe it wasn't meant that way. Let me put this in
> the category of "unorthodox semantics", which can (if desired) be
> addressed in the same way as the other cases described below.
C++'s "enum class" feature is something that could be nice to have, and
I wouldn't mind seeing something similar in a future C. The main
feature, as I understand it, is that there is no implicit conversion
between such a type and any integer type, though casts are still
permitted.
Probably "enum class" would not be the best syntax for C. I suggest
"enum static". 8-)}
[big snip]
> That all make sense?
Yes.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-02 10:09 +0000 |
| Message-ID | <560e5791.4241828@news.xs4all.nl> |
| In reply to | #71576 |
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. > > Are there any cases where a program could run without diagnostic in sub- > dialects of the LLP64 dialect in which "int32_t" is aliased to "int" and > run differently, also without diagnostic, in otherwise-identical sub- > dialects where "int32_t" is aliased to "long"? Possibly; but whether or not such cases _now_ exist, they very well _could_. More importantly, it is not wise to assume that your code always does, and always will, run only on LLP64 implementations. Richard
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-10-02 08:55 -0400 |
| Message-ID | <muluoc$ui0$1@dont-email.me> |
| In reply to | #71576 |
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.
Keep in mind that something like gcc is a package of several
implementations: The equivalences in a "-ansi" compilation and
those in a "-std=c11" compilation need not agree. The flags have,
in effect, invoked different implementations.
> Are there any cases where a program could run without diagnostic in sub-
> dialects of the LLP64 dialect in which "int32_t" is aliased to "int" and
> run differently, also without diagnostic, in otherwise-identical sub-
> dialects where "int32_t" is aliased to "long"? Given that dialects in
> which both "int" and "long" are 32 bits are collectively referred to
> under the common name LLP64, would there be any problem with allowing a
> compiler to accept programs that use "int32_t" and "int" interchangeably
> as well as those that use "int32_t" and "long" interchangeably?
I'm confused by your use of "LLP64" in connection with 32-bit types,
so I won't address this one.
> On a related note, would anything forbid a perverse C implementation
> from having "int32_t" as an alias to "int", but "uint32_t" as an alias to
> "unsigned long"? I think the Standard specifies that if an unsigned
> integer type holds a value which is representable in the corresponding
> signed type, it may be accessed using a pointer of the signed type. Does
> that rule apply to "int32_t" and "uint32_t", or could a perverse but
> conforming implementation alias them to incompatible types?
To the first question, I don't know of any prohibition against
the perversity you mention. To the second, I think what you're talking
about is 6.2.5p9, which requires identical representation for the values
common to both a signed integer type and its corresponding unsigned
integer type. Identity of representation is not compatibility, nor
does a type's compatibility with another depend on what values some
objects of those types may happen to represent at the moment. It is
never the case that `int32_t' and `uint32_t' are compatible types.
> If one has two libraries which are supposed to act upon the same array of
> 32-bit values, and one library expects to receive a pointer to the array
> as "int*" and the other as "long*", is there any way via which code which
> will never need to run on any platform where "int" and "long" do not both
> have the same representation as "int32_t" can be written such that a
> compiler for such a system would not be allowed to mess with it?
No strictly-conforming program could use both libraries on the
same array. Beyond that, I'm not sure what you're asking because
I don't know what you mean by "mess with."
--
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 08:59 -0700 |
| Message-ID | <2da82a81-43ee-49eb-9357-6a7e06cfac03@googlegroups.com> |
| In reply to | #71601 |
On Friday, October 2, 2015 at 7:55:40 AM UTC-5, Eric Sosman wrote:
> I'm confused by your use of "LLP64" in connection with 32-bit types,
> so I won't address this one.
I've often seen the term "LLP64" used as a short-hand to refer to compilers
with the following type sizes (none with any padding)
char = 8 bits
short = 16 bits
int = 32 bits
long = 32 bits
long long = 64 bits
all pointers = 64 bits
The term "LP64" is used to refer to dialects where "long" and "long long"
are both 64. Other terms include "ILP64" [ints as well as longs and pointers
are 64], "LL64" [only long longs are 64], etc. The reason I use the term
here was to make the point that terms like "LLP64", "LP64", etc. are often
used as though they say everything a programmer would need to know about
integer sizes on a system, but by the sound of it there are two disjoint
dialects and conforming compilers are for some reason not allowed to
implement both even for programs whose meaning would be unambiguous. (There
is also a third dialect, but it's a proper subset of both of the others).
> To the first question, I don't know of any prohibition against
> the perversity you mention. To the second, I think what you're talking
> about is 6.2.5p9, which requires identical representation for the values
> common to both a signed integer type and its corresponding unsigned
> integer type. Identity of representation is not compatibility, nor
> does a type's compatibility with another depend on what values some
> objects of those types may happen to represent at the moment. It is
> never the case that `int32_t' and `uint32_t' are compatible types.
Pointers are not convertible without a typecast, but I believe it's been
hashed out that e.g. passing a positive signed argument to a "%x" printf
parameter is required to behave identically to passing the same value as
the corresponding unsigned type. I suppose that it might in theory be
possible for a printf implementation to do something other than reading
an "int" using an "unsigned *" in that case, but it would seem like there
would have to be some form of compatibility there.
I'll admit I've never fully understood all the weird intricacies of the
Strict Aliasing Rule (which IMHO is poorly designed in that it fails to
allow many useful optimizations while simultaneously requiring programmers
to jump through hoops to perform useful kinds of type punning), so I don't
know exactly what compilers are and are not allowed to do with code that
typecasts pointers to various kinds of unions. I believe that code which
holds a union must expect that a write to an unknown pointer of any of the
constituent types must be regarded as a potential write to the union, but
I'm not clear about when writes to pointers of union type need to be
regarded as writes to pointers of constituent types, but I think there is
some form of aliasing compatibility between pointers to unions and pointers
to their constituent types.
> > If one has two libraries which are supposed to act upon the same array of
> > 32-bit values, and one library expects to receive a pointer to the array
> > as "int*" and the other as "long*", is there any way via which code which
> > will never need to run on any platform where "int" and "long" do not both
> > have the same representation as "int32_t" can be written such that a
> > compiler for such a system would not be allowed to mess with it?
>
> No strictly-conforming program could use both libraries on the
> same array. Beyond that, I'm not sure what you're asking because
> I don't know what you mean by "mess with."
By "mess with" I mean, basically, "perform in a fashion inconsistent with
how the program would behave if all pointers to signed 32-bit numbers were
pointers to the same signed 32-bit type." Some compiler writers believe
that if the Standard imposes no requirements in a particular situation,
compilers should aggressively exploit that, even if the "natural" behavior
on that platform would have been useful. In C89, for a program to cast an
"int*" to a "long*" and proceed to use it would have been 100% defined
behavior in all cases where the original pointer was valid and the types
had identical representations and padding requirements; if there is no
means for C99 to achieve the same semantics, I would consider that to be a
significant way in which C89 was superior to C99.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-02 17:35 -0700 |
| Message-ID | <ln1tdc23h6.fsf@kst-u.example.com> |
| In reply to | #71617 |
supercat@casperkitty.com writes:
> On Friday, October 2, 2015 at 7:55:40 AM UTC-5, Eric Sosman wrote:
>> I'm confused by your use of "LLP64" in connection with 32-bit types,
>> so I won't address this one.
>
> I've often seen the term "LLP64" used as a short-hand to refer to compilers
> with the following type sizes (none with any padding)
>
> char = 8 bits
> short = 16 bits
> int = 32 bits
> long = 32 bits
> long long = 64 bits
> all pointers = 64 bits
>
> The term "LP64" is used to refer to dialects where "long" and "long long"
> are both 64. Other terms include "ILP64" [ints as well as longs and pointers
> are 64], "LL64" [only long longs are 64], etc. The reason I use the term
> here was to make the point that terms like "LLP64", "LP64", etc. are often
> used as though they say everything a programmer would need to know about
> integer sizes on a system, but by the sound of it there are two disjoint
> dialects and conforming compilers are for some reason not allowed to
> implement both even for programs whose meaning would be unambiguous. (There
> is also a third dialect, but it's a proper subset of both of the others).
A given C implementation defines specific sizes for the various types.
Some compilers might have options to specify different sizes, but then
the compiler invoked with and without such an option would effectively
be two different implementations.
I don't know what you mean by "programs whose meaning would be
unambiguous".
[...]
> Pointers are not convertible without a typecast, but I believe it's been
> hashed out that e.g. passing a positive signed argument to a "%x" printf
> parameter is required to behave identically to passing the same value as
> the corresponding unsigned type. I suppose that it might in theory be
> possible for a printf implementation to do something other than reading
> an "int" using an "unsigned *" in that case, but it would seem like there
> would have to be some form of compatibility there.
Here's what the standard says: N1570 6.2.5p9:
The range of nonnegative values of a signed integer type is a
subrange of the corresponding unsigned integer type, and the
representation of the same value in each type is the same.
with a footnote:
The same representation and alignment requirements are meant to
imply interchangeability as arguments to functions, return values
from functions, and members of unions.
This applies only to corresponding signed and unsigned types, such as
int and unsigned int; it says nothing about, int vs. long, for example.
So `printf("%x\n", 42)` is "meant" to print 42, even though "%x" expects
and unsigned int argument and 42 is of type int.
`printf("%d\n", 42L)` has undefined behavior *even if int and long
happen to have the same representation*. (Of course an implementation
is free to make it work in the expected manner.)
[...]
> In C89, for a program to cast an
> "int*" to a "long*" and proceed to use it would have been 100% defined
> behavior in all cases where the original pointer was valid and the types
> had identical representations and padding requirements; if there is no
> means for C99 to achieve the same semantics, I would consider that to be a
> significant way in which C89 was superior to C99.
I don't believe that's correct. 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. Furthermore, C90 6.3 says:
An object shall have its stored value accessed only by an
lvalue that has one of the following types:
-- the declared type of the object,
-- a qualified version of the declared type of the object,
-- a type that is the signed or unsigned type corresponding to the
declared type of the object,
-- a type that is the signed or unsigned type corresponding to a
qualified version of the declared type of the object,
-- an aggregate or union type that includes one of the
aforementioned types among its members (including, recursively,
a member of a subaggregate or contained union), or
-- a character type.
The use of "shall" means that an access via any other type has
undefined behavior. The wording is a bit different in C11 (in
particular it uses the phrase "effective type"), but the general idea
is the same.
This:
int n = 42;
long l = *(long*)&n;
has undefined behavior in C89/C90, in C99, and in C11, regardless of the
representations of int and long.
--
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 10:02 -0700 |
| Message-ID | <efbd4fa7-3d38-4a11-97b3-54acc72cee57@googlegroups.com> |
| In reply to | #71653 |
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.
I would suggest that writing of portable code in C could be greatly
facilitated by defining additional types such that the code could be
written as either:
int blah(uwrap32_t x, uwrap32_t y, uwrap32_t z) ... // Same content
or
int blah(unum32_t x, unum32_t y, unum32_t z) ... // Same content
depending upon which behavior was intended, with the proviso that any
compiler which accepts the first must cause uwrap32_t to be promoted to
a signed type only in those cases where a system with a 32-bit "unsigned
int" type would have been promoted likewise, and a compiler that accepts
the second must always promote unum32_t to a signed type that can hold
the arithmetical values resulting from subtracting two unum32_t values.
If such types existed, the meaning of either function above would be
system-independent. For a system where "int" was larger than 32 bits to
support "uwrap32_t" the rules regarding promotion would have to be
changed, since presently they would not allow for the existence of
extra integer types whose values are all within the range of "int" but
which would not get promoted to that type, but having a type which worked
the way "uint32_t" works on 32-bit systems would greatly assist in the
migration of 32-bit code to systems where "int" is 64 bits.
> I don't believe that's correct. 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. Furthermore, C90 6.3 says:
Maybe the issue isn't one of what the standard says, but merely how the
interpretation has changed over the years. C89 was published after many
C compilers had been around for years, and so the fact that it didn't
impose requirements in particular cases where everybody knew how compilers
should behave wasn't seen as an issue. From what I recall of the time, the
general interpretation among people I knew was that some weird systems might have issues with pointer-based type punning, but on systems where types'
representations were 100% defined as byte sequences there was no perception
that the Standard was intended to deprecate production code. I think my
confusion regarding the Standard may stem from the fact that there seems to
be a "de-facto" standard for how compilers in "C89 mode" should behave
which goes a bit beyond the requirements of the Official Standard.
Thinking back a bit, some vendors were working on compilers which tried to
add more error-trapping features to C, and so there would have been some
value to saying "If you want to have a program that can run with a compiler
that includes extra features to try to trap errors and you want to do
something unusual, here's how you need to go about it". One of the reasons
that C thrived, however, was that code which didn't need to run on such
error-trapping compilers could do things like assemble 32-bit values out of
16-bit values.
There were some compilers even before C89 which had optimization options
that imposed additional aliasing restrictions beyond what the C Standard
required. For example, I recall some that would assume that, if enabled,
would cause a compiler to assume that pointers to local variables passed
to subroutines would not be persisted thereby, such that given:
int blah(void)
{
int foo;
scanf("%d",&foo);
foo++;
goo();
foo++;
zoo();
return foo;
}
a compiler might load "foo" into a register after the scanf and keep it
there across the calls to "goo" and "zoo". A practical and simple
optimization that saved code, but present rules offer no way to tell the
compiler that such an optimization is safe, except by writing code in a way
that would make it slower on many compilers, e.g.
int blah(void)
{
int temp,foo;
scanf("%d",&temp);
foo=temp;
foo++;
goo();
foo++;
zoo();
return foo;
}
A good compiler could detect that the value of "temp" was never used
after the assignment to "foo", and the value of "foo" was never used
before that, and would thus not have to generate any code for the
assignment, but adding extra variables and assignments in the hope
that a compiler will optimize them out seems rather backward to me.
> The use of "shall" means that an access via any other type has
> undefined behavior. The wording is a bit different in C11 (in
> particular it uses the phrase "effective type"), but the general idea
> is the same.
From what I understand (please tell me if I'm wrong), the "effective type"
language extends the concept such the Standard no longer imposes any
requirements on:
uint8_t buff[8];
(float*)buff = 12.34f;
memcpy(buff+4, buff, 4);
uint32_t x = (uint32_t*)buff+4;
which used to be required to set "x" to the uint32_t interpretation of the
binary representation of the "float" value 12.34f, since the "memcpy"
operation would set the "effective type" of the last four bytes of "buff"
to "float", such that reading the values as "uint32_t" would yield
Undefined Behavior. I understand that the change does allow some useful
optimizations that would not otherwise be possible in cases where e.g. the
memcpy was being used to copy one part of a "float[]" to another (since
C still has no type-specific means of copying an array or segment thereof)
but would also suggest that it increases the severity of C's lack of a
clear means by which the programmer can indicate what aliasing-related
assumptions compilers should and should not break.
I think probably the fundamental problem with C as a standardized language
stems from a failure to accept that some kinds of programs will require
features that not all compilers can support. There's thus no middle ground
between "strictly-conforming" programs, which will behave correctly on all
standard-compliant compilers but have to go out of its way to do anything
(e.g. using an "l" suffix on a lot of integer literals, avoiding any
meaningful depth of subroutine calls, etc.) and "conforming" programs which
merely have to behave correctly on at least one C compiler someplace (I
think the shortest conforming program would be three bytes on a Unix system
since a standard-compliant compiler could interpret "__<newline>" as a
macro that happens to expand to a program that does something which a
programmer might want).
> This:
>
> int n = 42;
> long l = *(long*)&n;
>
> has undefined behavior in C89/C90, in C99, and in C11, regardless of the
> representations of int and long.
I guess the Standard might not have required compilers to do anything with
it, even in that case, but if someone had asked, before the Standard was
published, what a compiler where "int" and "long" have the same
representation should do with that code, some might have accepted the idea
that a hyper-pendantic compiler might try to generate code that would trap,
but that a compiler which isn't being hyper-pedantic should simply set
l to 42. If someone had suggested that a compiler should assume that a
program would never be fed any inputs that would cause a value stored as
a 32-bit "int" to be read as a "long" with the same representation, and
should use such an assumption to eliminate code which would only be relevant
if such inputs were received (as opposed to merely assuming that in any cases
where a program might receive such input, it would be acceptable for the
compiler to trigger an implementation-defined trap if one existed, or to
interpret the bits as a "long" if the implementation did not specify that
a trap would occur).
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-10-03 16:11 -0500 |
| Message-ID | <h2h01bt6jip1misjmqimv8cnu9rd1pk5ft@4ax.com> |
| In reply to | #71684 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-10-03 17:27 -0400 |
| Message-ID | <muph4b$8f0$1@dont-email.me> |
| In reply to | #71737 |
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.)
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-10-03 16:58 -0500 |
| Message-ID | <jej01blpim3ebvoff7qpcp60i4j2a5jtpc@4ax.com> |
| In reply to | #71740 |
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).
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-03 15:16 -0700 |
| Message-ID | <0f0ffd70-d5b9-4a29-9648-1cd99d4fd69a@googlegroups.com> |
| In reply to | #71744 |
On Saturday, October 3, 2015 at 4:58:52 PM UTC-5, robert...@yahoo.com wrote: > 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 perfectly legitimate for a compiler to have "int" be 64 bits, "short" be 16 bits, and have "uint32_t" be some type that ranks between "short" and "int". Indeed, on many processors with 64 bit registers, doing so could be good for efficiency and correctness *if* there were a type which behaves the way that "uint32_t" behaves on systems where "int" is 32 bits, and code which requires such behavior could be migrated toward using that type. While some people might not think it's too horrible to require people writing portable code to multiply two uint32_t values x and y to write "x*=1u*y" rather than "x*=y", I would suggest that such an attitude suggests a belief that programmers exist to serve the language, rather than the language existing to serve programmers.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-03 18:21 -0400 |
| Message-ID | <mupk9k$mm3$1@dont-email.me> |
| In reply to | #71744 |
On 10/03/2015 05: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.
Padding bits are what allow a 33-bit int to exist on the same machine as
a uint32_t. The difference in the width of two integer types must be a
multiple of CHAR_BIT, which must be at least 8, so such an int would
have to have at least 7 padding bits.
> ... 2-3
> for 32 bit unsigned binary numbers must result in 0xffffffff.
True, but on a system with 33-bit int, that function won't be
calculating 2-3 as unsigned numbers, The expressions x, y, and z will
all promote to 'int', and all calculations will be performed using that
type.
The same problem applies to uint8_t on all platforms where it is
defined, which is why he gave you that hint about uint8_t.
> ... 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).
Why not? As far as I can see, CHAR_BIT==8, uint32_t defined as a 4-byte
type and int defined as a 5 byte type with 7 padding bits would be fully
conforming.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-10-03 18:23 -0400 |
| Message-ID | <mupke0$mld$1@dont-email.me> |
| In reply to | #71744 |
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?
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-03 18:52 -0400 |
| Message-ID | <mupm2q$tcv$1@dont-email.me> |
| In reply to | #71752 |
On 10/03/2015 06:23 PM, Eric Sosman wrote: > On 10/3/2015 5:58 PM, Robert Wessel wrote: ... >> 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. ... .... > 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? There is no such requirement. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-03 16:16 -0700 |
| Message-ID | <f27745d6-b4a8-42c3-9d2f-0bc5ff370143@googlegroups.com> |
| In reply to | #71759 |
On Saturday, October 3, 2015 at 5:52:10 PM UTC-5, James Kuyper wrote:
> There is no such requirement.
What exactly would the Standard specify given:
int main(void)
{
int32_t x=-65537;
int16_t y=x;
printf("%ld\n",(long)y);
return 0;
}
Would it be legitimate for an implementation to raise an implementation-
defined signal or use some implementation-defined method of conversion
that yields a value other than -1? The Standard clearly implies that
a legitimate implementation must supply documentation sufficient to
ascertain what the above code would do on that implementation, and
most implementations would certainly yield -1, but the fact that an
int16_t is required to use a two's-complement representation would not
in and of itself preclude the possibility of an implementation defining
some other means of doing the conversion (e.g. saturating to -32767 or
-32768).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-03 19:13 -0700 |
| Message-ID | <lnzizzxtwr.fsf@kst-u.example.com> |
| In reply to | #71762 |
supercat@casperkitty.com writes:
> On Saturday, October 3, 2015 at 5:52:10 PM UTC-5, James Kuyper wrote:
>> There is no such requirement.
>
> What exactly would the Standard specify given:
>
> int main(void)
> {
> int32_t x=-65537;
> int16_t y=x;
> printf("%ld\n",(long)y);
> return 0;
> }
Since the value of x is outside the range of int16_t, the implicit
conversion yields an implementation-defined result or raises an
implementation-defined signal.
> Would it be legitimate for an implementation to raise an implementation-
> defined signal or use some implementation-defined method of conversion
> that yields a value other than -1?
Certainly. (The common implementation of 2's-complement arithmetic has
wraparound semantics, but the standard says nothing about that.)
> The Standard clearly implies that
> a legitimate implementation must supply documentation sufficient to
> ascertain what the above code would do on that implementation, and
> most implementations would certainly yield -1, but the fact that an
> int16_t is required to use a two's-complement representation would not
> in and of itself preclude the possibility of an implementation defining
> some other means of doing the conversion (e.g. saturating to -32767 or
> -32768).
Correct.
--
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 23:34 -0700 |
| Message-ID | <0dfde5bd-6147-4295-ad24-647a320257b9@googlegroups.com> |
| In reply to | #71770 |
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?
If not, why does the Standard require that implementations must use one of
three forms of integer representation? I sometimes wonder if the process
of Standard writing involved a process whereby the most logical compromise
between specifying things precisely enough to be useful, or loosely enough
to avoid overly restricting implementations, was to specify things tightly
enough to restrict implementations, but too loosely to let portable code
do anything it couldn't do without the specification. It seems there are
a lot of things like that [e.g. the storage format of bitfields is specified
too tightly to let a compiler for a system with 8-bit "char" render:
struct EightTriples { signed a,b,c,d,e,f,g,h : 3; };
as a three-byte structure, but too loosely to offer any benefit versus
letting implementations lay them out however they see fit provided they do
not overlap non-bitfield members. It's not hard to imagine hardware
usefully providing arithmetic instructions which would yield treat the bit
pattern commonly used for -MAX_INT-1 as a NaN (which would greatly
facilitate the writing of efficient code where overflow detection was
important) but for such a thing to be efficiently useful it would likely
be necessary to restrict 64-bit signed overflow-checked values to the
range -0x7FFFFFFFF00000000 to +0x7FFFFFFFFFFFFFFFF (if all bit patterns
of the form 0x80000000nnnnnnnn are treated as NaN, long-integer arithmetic
could compute the lower word before having to examine the upper word; if
NaN were required to only be 0x8000000000000000 [the C Standard would allow
implementations to treat that as NaN] double-word arithmetic would be a lot
more cumbersome.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-04 07:09 +0000 |
| Message-ID | <muqjbg$vbv$1@speranza.aioe.org> |
| In reply to | #71789 |
supercat@casperkitty.com wrote: > 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? > If not, why does the Standard require that implementations must use > one of three forms of integer representation? As far as I know it, the standard requires the bit patterns for non-negative values of signed integers to match the bit patterns for unsigned integers. The above not mentioned three formats agree. That requirement disallows a biased representation, such as you would get inverting the sign bit of twos complement. As far as I know, K&R didn't have this restriction, and would, for example, allow for BCD representation. > I sometimes wonder if the process > of Standard writing involved a process whereby the most logical compromise > between specifying things precisely enough to be useful, or loosely enough > to avoid overly restricting implementations, was to specify things tightly > enough to restrict implementations, but too loosely to let portable code > do anything it couldn't do without the specification. (snip) -- glen
[toc] | [prev] | [next] | [standalone]
Page 9 of 17 — ← Prev page 1 … 7 8 [9] 10 11 … 17 Next page →
Back to top | Article view | comp.lang.c
csiph-web