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 8 of 17 — ← Prev page 1 … 6 7 [8] 9 10 … 17 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-04 19:13 -0400 |
| Message-ID | <5611B2B1.2090809@verizon.net> |
| In reply to | #71879 |
On 10/04/2015 06:37 PM, Richard Damon wrote:
> On 10/4/15 6:01 PM, Keith Thompson wrote:
...
>> Actually, that raises a question. Given:
>>
>> enum foo { zero, one, two };
>>
>> let's assume that the compiler chooses to make `enum foo` compatible
>> with unsigned. Is there a practical difference between `enum
>> foo` being *compatible* with unsigned vs. being the *same type*
>> as unsigned (similar to a typedef)? Is there a C program that
>> would behave differently if `enum foo` and unsigned were the same
>> type rather than being distinct but compatible types?
>>
> One big one, pointers, an enum foo* is a distinct type to unsigned*, and
> not at all interchangable.
"For two pointer types to be compatible, both shall be identically
qualified and both shall be pointers to compatible types." (6.7.6.1p2)
If enum foo is compatible with unsigned, then enum foo* is compatible
with unsigned *. Can you identify any context other than re-defined
typedefs where the fact that they are different types causes a problem?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-04 17:57 -0700 |
| Message-ID | <ln8u7iw2sg.fsf@kst-u.example.com> |
| In reply to | #71879 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 10/4/15 6:01 PM, Keith Thompson wrote:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> > Keith Thompson <kst-u@mib.org> writes:
>> >> [snip]
>> >>
>> >> I *think* it's accurate to say that two integer types are
>> >> compatible if and only if they're the same type.
>> >
>> > Do you mean to exclude enumerated types? Enumerated types
>> > are compatibile with a signed or unsigned integer type (or
>> > char), but are nonetheless distinct types.
>> >
>> > If enumerated types are excluded, I believe the statement
>> > is right.
>>
>> You're right, I glossed over enumerated types. (Actually I forgot
>> that they're classified as "integer types"; I should have checked.)
>>
>> Actually, that raises a question. Given:
>>
>> enum foo { zero, one, two };
>>
>> let's assume that the compiler chooses to make `enum foo` compatible
>> with unsigned. Is there a practical difference between `enum
>> foo` being *compatible* with unsigned vs. being the *same type*
>> as unsigned (similar to a typedef)? Is there a C program that
>> would behave differently if `enum foo` and unsigned were the same
>> type rather than being distinct but compatible types?
>>
> One big one, pointers, an enum foo* is a distinct type to unsigned*, and
> not at all interchangable.
Actually, given that enum foo and unsigned are compatible, enum foo* and
unsigned* are also compatible. For example, this is valid (and gcc at
least doesn't complain about it):
enum foo { zero, one, two };
void func(enum foo);
void func(unsigned);
enum foo obj = zero;
unsigned *ptr = &obj;
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-10-04 21:57 -0400 |
| Message-ID | <gOkQx.4283$7h3.781@fx31.iad> |
| In reply to | #71909 |
On 10/4/15 8:57 PM, Keith Thompson wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>> On 10/4/15 6:01 PM, Keith Thompson wrote:
>>>
>>> Actually, that raises a question. Given:
>>>
>>> enum foo { zero, one, two };
>>>
>>> let's assume that the compiler chooses to make `enum foo` compatible
>>> with unsigned. Is there a practical difference between `enum
>>> foo` being *compatible* with unsigned vs. being the *same type*
>>> as unsigned (similar to a typedef)? Is there a C program that
>>> would behave differently if `enum foo` and unsigned were the same
>>> type rather than being distinct but compatible types?
>>>
>> One big one, pointers, an enum foo* is a distinct type to unsigned*, and
>> not at all interchangable.
>
> Actually, given that enum foo and unsigned are compatible, enum foo* and
> unsigned* are also compatible. For example, this is valid (and gcc at
> least doesn't complain about it):
>
> enum foo { zero, one, two };
>
> void func(enum foo);
> void func(unsigned);
>
> enum foo obj = zero;
> unsigned *ptr = &obj;
>
That is a little surprising to me. It may be that I am more used to the
more strict rules in C++.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-05 01:53 -0700 |
| Message-ID | <kfnvbal3dcu.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71870 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> [snip]
>>>
>>> I *think* it's accurate to say that two integer types are
>>> compatible if and only if they're the same type.
>>
>> Do you mean to exclude enumerated types? Enumerated types
>> are compatibile with a signed or unsigned integer type (or
>> char), but are nonetheless distinct types.
>>
>> If enumerated types are excluded, I believe the statement
>> is right.
>
> You're right, I glossed over enumerated types. (Actually I forgot
> that they're classified as "integer types"; I should have checked.)
>
> Actually, that raises a question. Given:
>
> enum foo { zero, one, two };
>
> let's assume that the compiler chooses to make `enum foo` compatible
> with unsigned. Is there a practical difference between `enum
> foo` being *compatible* with unsigned vs. being the *same type*
> as unsigned (similar to a typedef)? Is there a C program that
> would behave differently if `enum foo` and unsigned were the same
> type rather than being distinct but compatible types?
Yes, because type compatibility is not transitive. Two types,
enum foo and enum bas, can each be compatible with unsigned, but
still not compatible with each other (and are not, I believe,
under the Standard's rules). This situation is different from
the behavior if either enum type is the same type as unsigned
rather than just being compatible.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-05 09:37 -0700 |
| Message-ID | <ln37xp5l1j.fsf@kst-u.example.com> |
| In reply to | #71955 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> Actually, that raises a question. Given:
>>
>> enum foo { zero, one, two };
>>
>> let's assume that the compiler chooses to make `enum foo` compatible
>> with unsigned. Is there a practical difference between `enum
>> foo` being *compatible* with unsigned vs. being the *same type*
>> as unsigned (similar to a typedef)? Is there a C program that
>> would behave differently if `enum foo` and unsigned were the same
>> type rather than being distinct but compatible types?
>
> Yes, because type compatibility is not transitive. Two types,
> enum foo and enum bas, can each be compatible with unsigned, but
> still not compatible with each other (and are not, I believe,
> under the Standard's rules). This situation is different from
> the behavior if either enum type is the same type as unsigned
> rather than just being compatible.
Yes, that's it.
For example:
enum foo { f0, f1, f2 };
enum bar { b0, b1, b2 };
void func(enum foo);
void func(unsigned);
void func(enum bar);
gcc accepts the first two declarations of func, and complains on the
third:
c.c:6:6: error: conflicting types for 'func'
void func(enum bar);
^
c.c:5:6: note: previous declaration of 'func' was here
void func(unsigned);
^
Of course (IMHO) the first two declarations are both non-portable
and horrid style. I wonder why the authors of the C standard felt
the need to make each enumerated types compatible with some integer
type in the first place. They could have required them to have
the same representation as some integer type and left it at that.
Given that the choice of compatible type is implementation-defined,
I don't see that compatibility is useful. (Quite possibly I'm
missing something again.)
--
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-09 14:10 -0700 |
| Message-ID | <kfnfv1j21fm.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71984 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>
> [...]
>
>>> Actually, that raises a question. Given:
>>>
>>> enum foo { zero, one, two };
>>>
>>> let's assume that the compiler chooses to make `enum foo` compatible
>>> with unsigned. Is there a practical difference between `enum
>>> foo` being *compatible* with unsigned vs. being the *same type*
>>> as unsigned (similar to a typedef)? Is there a C program that
>>> would behave differently if `enum foo` and unsigned were the same
>>> type rather than being distinct but compatible types?
>>
>> Yes, because type compatibility is not transitive. Two types,
>> enum foo and enum bas, can each be compatible with unsigned, but
>> still not compatible with each other (and are not, I believe,
>> under the Standard's rules). This situation is different from
>> the behavior if either enum type is the same type as unsigned
>> rather than just being compatible.
>
> Yes, that's it.
>
> For example:
>
> enum foo { f0, f1, f2 };
> enum bar { b0, b1, b2 };
>
> void func(enum foo);
> void func(unsigned);
> void func(enum bar);
>
> gcc accepts the first two declarations of func, and complains on the
> third:
>
> c.c:6:6: error: conflicting types for 'func'
> void func(enum bar);
> ^
> c.c:5:6: note: previous declaration of 'func' was here
> void func(unsigned);
> ^
>
> Of course (IMHO) the first two declarations are both non-portable
> and horrid style. I wonder why the authors of the C standard felt
> the need to make each enumerated types compatible with some integer
> type in the first place.
My reaction isn't as strong as yours. Also there may be factors
that had to be considered (notably, preserving the semantics of
existing code) that I don't know about. The existing rule seems
okay to me, even if at the same time I would advise against
taking advantage of the "compatibility quirks", if I may call
them that.
> They could have required them to have
> the same representation as some integer type and left it at that.
> Given that the choice of compatible type is implementation-defined,
> I don't see that compatibility is useful. (Quite possibly I'm
> missing something again.)
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.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-09 14:35 -0700 |
| Message-ID | <6bced3f2-33d5-4427-b747-49ee06d60a9b@googlegroups.com> |
| In reply to | #72333 |
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. I wish people designing more languages would be more open to the idea that different kinds of applications often have different requirements for their widgets, and in many cases it may be better to define two slightly- different kinds of widgets, with rules which while mostly similar have a few differences tailored to fit different needs, than to formulate a single set of rules for widgets. 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].
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-10 11:43 +1300 |
| Message-ID | <d7qu8uFntp6U5@mid.individual.net> |
| In reply to | #72338 |
supercat@casperkitty.com wrote: > 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. > > I wish people designing more languages would be more open to the idea that > different kinds of applications often have different requirements for > their widgets, and in many cases it may be better to define two slightly- > different kinds of widgets, with rules which while mostly similar have a > few differences tailored to fit different needs, than to formulate a single > set of rules for widgets. > > 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]. This is a pretty good summary of the philosophy behind the new enum types in C++11. Another case of the C++ committee listening to the developer community :) -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-12 09:17 -0700 |
| Message-ID | <kfn612cm57h.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #72338 |
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.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-12 12:32 -0700 |
| Message-ID | <fa6cfc9f-2f39-4bc7-b331-ef44b57230c4@googlegroups.com> |
| In reply to | #72626 |
On Monday, October 12, 2015 at 11:17:53 AM UTC-5, Tim Rentsch wrote: > supercat writes: > > [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. Would there be any way in which a conforming implementation could reorder the values of an enum in circumstances where it would be possible for the value of the enum to be observable in any fashion? In something like an embedded system which allocates memory from a pool rather than using malloc() is there any way to tell a conforming implementation that the sequence of enum values will not be of interest to the programmer and may be rearranged even though the compiler can't prove there's no way code could observe it?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-12 14:12 -0700 |
| Message-ID | <lnfv1fbxkp.fsf@kst-u.example.com> |
| In reply to | #72626 |
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.
--
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-12 14:52 -0700 |
| Message-ID | <10b3c5e0-58e2-4e26-9de0-e363a374803d@googlegroups.com> |
| In reply to | #72657 |
On Monday, October 12, 2015 at 4:13:02 PM UTC-5, Keith Thompson 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.
Given:
static enum { ZERO, ONE, TWO } zero_one_two;
a compiler which determined that zero_one never had its address taken and
was never assigned any value other than 0, 1, or 2 could legitimately (and
perhaps usefully) replace the values 1 and 2 with 64 and 128, respectively,
when targeting a processor like the 6502 which could test bits 6 and
7 of a byte with a single instruction, but would require two instructions
to test any other bit. Any code which tried to store an integer [which
must be 100% guaranteed to be in the range 0-2] into zero_one_two would
be required to shift it left 6 bits; and any code which tried to use
zero_one_two like an integer would have to shift it left six bits, but
something like:
if (zero_one_two == ONE)
...
which would normally require:
lda _zero_one_two
cmp #1
bne NOT_ONE
could be reduced to:
bit _zero_one_two
bvc NOT_ONE
If the value is loaded with or tested against constants much more often than
it is used like an integer, such an optimization may be a significant "win".
It would not be usable, however, if there would be any defined means by
which code would be able to detect its existence.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-13 03:00 +0000 |
| Message-ID | <mvhs4b$541$1@speranza.aioe.org> |
| In reply to | #72661 |
supercat@casperkitty.com wrote:
> On Monday, October 12, 2015 at 4:13:02 PM UTC-5, Keith Thompson 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.
> Given:
> static enum { ZERO, ONE, TWO } zero_one_two;
> a compiler which determined that zero_one never had its address taken and
> was never assigned any value other than 0, 1, or 2 could legitimately (and
> perhaps usefully) replace the values 1 and 2 with 64 and 128, respectively,
> when targeting a processor like the 6502 which could test bits 6 and
> 7 of a byte with a single instruction, but would require two instructions
> to test any other bit.
Seems to me that the compiler has to also be sure that you don't see
the value any other way, such as with printf. Well, I suppose the
other possibility is that it does a fix-up before letting you see
the value.
On the other hand, if you used a debugger, you might be surprised
to see what it actually stored.
> Any code which tried to store an integer [which
> must be 100% guaranteed to be in the range 0-2] into zero_one_two would
> be required to shift it left 6 bits; and any code which tried to use
> zero_one_two like an integer would have to shift it left six bits, but
> something like:
> if (zero_one_two == ONE)
> ...
In many cases, C has to use the usual 0, 1, 2 values as you might
pass the value to a separately compiled routine which wouldn't know
that the bits were different.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-12 23:34 -0700 |
| Message-ID | <18d78df1-be3c-408d-8f08-0993d45f0d1d@googlegroups.com> |
| In reply to | #72675 |
On Monday, October 12, 2015 at 10:00:42 PM UTC-5, glen herrmannsfeldt wrote: > Seems to me that the compiler has to also be sure that you don't see > the value any other way, such as with printf. Well, I suppose the > other possibility is that it does a fix-up before letting you see > the value. Exactly. Code wouldn't have to use the thing very often as a number before the cost of the fixups exceeded the savings on conditional tests. On the other hand, there are a lot of programs where the enum would get used as a number zero times, so the cost of such fixups would be irrelevant. > On the other hand, if you used a debugger, you might be surprised > to see what it actually stored. Yeah, but the C Standard doesn't say anything about that. > In many cases, C has to use the usual 0, 1, 2 values as you might > pass the value to a separately compiled routine which wouldn't know > that the bits were different. Same as any other scenario requiring fix-ups.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-14 11:00 +0000 |
| Message-ID | <561e34ed.5443953@news.xs4all.nl> |
| In reply to | #72661 |
supercat@casperkitty.com wrote:
> Given:
>
> static enum { ZERO, ONE, TWO } zero_one_two;
>
> a compiler which determined that zero_one never had its address taken and
> was never assigned any value other than 0, 1, or 2 could legitimately (and
> perhaps usefully) replace the values 1 and 2 with 64 and 128, respectively,
> when targeting a processor like the 6502 which could test bits 6 and
> 7 of a byte with a single instruction, but would require two instructions
> to test any other bit.
> If the value is loaded with or tested against constants much more often than
> it is used like an integer, such an optimization may be a significant "win".
> It would not be usable, however, if there would be any defined means by
> which code would be able to detect its existence.
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.
Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-14 08:34 -0700 |
| Message-ID | <fa54b8bb-0918-4763-9975-28eddab7710d@googlegroups.com> |
| In reply to | #72820 |
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*; while other language needs are more pressing than this particular case with enums, I think that in general the language is lacking in ways to tell the compiler want things the programmer cares about and what things the programmer does not care about.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-14 11:34 -0700 |
| Message-ID | <lnk2qp8fjx.fsf@kst-u.example.com> |
| In reply to | #72847 |
supercat@casperkitty.com writes:
> 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*; while
> other language needs are more pressing than this particular case with
> enums, I think that in general the language is lacking in ways to tell the
> compiler want things the programmer cares about and what things the
> programmer does not care about.
A big part of language design is deciding what features to include.
A bigger and more difficult part is deciding what features *not*
to include.
I haven't been keeping track of the directives you've proposed adding
to the language, but my general impression is that they would make
the language substantially more complicated than it already is.
--
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-14 11:57 -0700 |
| Message-ID | <72d20010-a8b0-46c7-94cf-51e8e1b32425@googlegroups.com> |
| In reply to | #72870 |
On Wednesday, October 14, 2015 at 1:34:49 PM UTC-5, Keith Thompson wrote:
> I haven't been keeping track of the directives you've proposed adding
> to the language, but my general impression is that they would make
> the language substantially more complicated than it already is.
For something like Universal eXtended C as I would envision it, anyone
wishing to use features from version (e.g.) 23 of UXC would be required
to have a copy of the "defaults-assigning" header file for that version
(or at least whatever subset of that version the programmer was interested
in) but a compiler's sole obligation for minimal UXC conformance would
be that it refrain from defining any identifiers starting with __UXC_ or
__uxc_ in a fashion inconsistent with the UXC standard. While it would
be helpful for compilers to define identifiers describing aspects of their
behavior that programmers would likely find useful, compiler writers
would be free to ignore any parts they would not expect programmers to
find useful.
Likewise, programmers would be free to use parts of the Standard that are
necessary to meet their needs, and free to ignore any parts that would
not be helpful to them.
It would be really nice if the C processor had a means by which one could
encapsulate the concept
#if ~((defined Fooble) ? Fooble : Foo) & 23
#error Uh oh
#endif
but unfortunately I don't think that's possible; the lack of such a feature
would make some aspects of UXC more cumbersome than would be desirable, but
I know of no way around that.
Otherwise, I'd suggest that the biggest part of UXC would basically center
around identifying whether the set of behaviors that a programmer would
find acceptable in various situations is a subset of the behaviors that
an implementation might perform in those situations. Pretty straightforward
even though the preprocessor doesn't work well as a database.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-15 00:03 +0000 |
| Message-ID | <mvmqhd$a1r$1@speranza.aioe.org> |
| In reply to | #72870 |
Keith Thompson <kst-u@mib.org> wrote: > supercat@casperkitty.com writes: (snip) >> 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*; >> while other language needs are more pressing than this particular >> case with enums, I think that in general the language is lacking >> in ways to tell the compiler want things the programmer cares >> about and what things the programmer does not care about. > A big part of language design is deciding what features to include. > A bigger and more difficult part is deciding what features *not* > to include. I have always wondered about the decision to add complex data types and such to C. COMPLEX has been part of Fortran for a long time, though for much of that time only single precision. But even so, it isn't used all that much. For one example, a favorite use of complex values is the FFT (Fast Fourier Transform) but the usual way of writing FFT routines is with arrays of REAL. I suspect that complex was a feature not with the cost of adding it. Are there good examples of actually using it, where arrays of (float) or (double) wouldn't have been just as good? > I haven't been keeping track of the directives you've proposed adding > to the language, but my general impression is that they would make > the language substantially more complicated than it already is. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-15 10:57 -0700 |
| Message-ID | <kfn4mhsj9ql.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #72893 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> supercat@casperkitty.com writes:
>
> (snip)
>
>>> 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*; while other language needs are more pressing than this
>>> particular case with enums, I think that in general the language
>>> is lacking in ways to tell the compiler want things the programmer
>>> cares about and what things the programmer does not care about.
>>
>> A big part of language design is deciding what features to include.
>> A bigger and more difficult part is deciding what features *not* to
>> include.
>
> I have always wondered about the decision to add complex data
> types and such to C. [snip]
The Rationale document says this:
A new feature of C99: Complex types were added to C as part
of the effort to make C suitable and attractive for general
numerical programming. Complex arithmetic is used heavily
in certain important application areas.
[toc] | [prev] | [next] | [standalone]
Page 8 of 17 — ← Prev page 1 … 6 7 [8] 9 10 … 17 Next page →
Back to top | Article view | comp.lang.c
csiph-web