Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #124638 > unrolled thread
| Started by | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| First post | 2017-12-24 07:54 +0000 |
| Last post | 2017-12-24 07:03 -0800 |
| Articles | 20 on this page of 254 — 26 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: What every compiler writer should know about programmersWhat every compiler writer should know about programmers gazelle@shell.xmission.com (Kenny McCormack) - 2017-12-24 07:54 +0000
Re: What every compiler writer should know about programmersWhat every compiler writer should know about programmers bartc <bc@freeuk.com> - 2017-12-24 12:34 +0000
Re: What every compiler writer should know about programmersWhat every compiler writer should know about programmers Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-24 12:44 +0000
Re: UB in asm Noob <root@127.0.0.1> - 2017-12-24 15:26 +0100
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-24 14:58 +0000
Re: UB in asm Johannes Bauer <dfnsonfsduifb@gmx.de> - 2017-12-24 21:59 +0100
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-24 13:35 -0800
Re: UB in asm Robert Wessel <robertwessel2@yahoo.com> - 2017-12-24 16:10 -0600
Re: UB in asm Johannes Bauer <dfnsonfsduifb@gmx.de> - 2018-01-02 12:06 +0100
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2018-01-02 08:03 -0500
Re: UB in asm supercat@casperkitty.com - 2018-01-02 08:53 -0800
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2018-01-02 09:33 -0800
Re: UB in asm supercat@casperkitty.com - 2018-01-02 09:53 -0800
Re: UB in asm scott@slp53.sl.home (Scott Lurndal) - 2018-01-02 19:31 +0000
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2018-01-02 09:26 -0800
Re: UB in asm Johannes Bauer <dfnsonfsduifb@gmx.de> - 2018-01-04 10:56 +0100
Re: UB in asm James Kuyper <jameskuyper@verizon.net> - 2018-01-04 05:19 -0500
Re: UB in asm aph@littlepinkcloud.invalid - 2018-01-04 05:38 -0600
Re: UB in asm James Kuyper <jameskuyper@verizon.net> - 2018-01-04 07:05 -0500
Re: UB in asm aph@littlepinkcloud.invalid - 2018-01-04 06:46 -0600
Re: UB in asm scott@slp53.sl.home (Scott Lurndal) - 2018-01-04 16:09 +0000
Re: UB in asm supercat@casperkitty.com - 2018-01-04 08:12 -0800
Re: UB in asm supercat@casperkitty.com - 2018-01-04 08:00 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2018-01-04 10:02 -0500
Re: UB in asm James Kuyper <jameskuyper@verizon.net> - 2017-12-24 17:04 -0500
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-24 22:29 +0000
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-24 14:50 -0800
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-24 23:23 +0000
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-24 15:58 -0800
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-24 16:26 -0800
Re: UB in asm Gareth Owen <gwowen@gmail.com> - 2017-12-26 18:03 +0000
Re: UB in asm supercat@casperkitty.com - 2017-12-26 12:23 -0800
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-26 12:44 -0800
Re: UB in asm supercat@casperkitty.com - 2017-12-27 08:31 -0800
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-27 09:15 -0800
Re: UB in asm supercat@casperkitty.com - 2017-12-27 09:55 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-27 16:00 -0500
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-27 13:13 -0800
Re: UB in asm Tim Rentsch <txr@alumni.caltech.edu> - 2017-12-27 11:28 -0800
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-27 11:35 -0800
Re: UB in asm Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-27 20:29 +0000
Re: UB in asm supercat@casperkitty.com - 2017-12-27 12:46 -0800
Re: UB in asm Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-27 22:00 +0000
Re: UB in asm supercat@casperkitty.com - 2017-12-27 14:16 -0800
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-27 13:09 -0800
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-26 20:54 +0000
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-25 01:24 +0000
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-24 17:55 -0800
Re: UB in asm Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-27 18:24 +0000
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-29 19:39 -0800
Re: UB in asm Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-30 11:20 +0000
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-24 21:17 -0500
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-24 18:34 -0800
Re: UB in asm Noob <root@127.0.0.1> - 2017-12-25 14:36 +0100
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-25 15:52 +0000
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-24 21:22 -0500
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-25 13:08 +0000
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-25 10:06 -0500
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-26 16:07 +0100
Re: UB in asm Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-12-26 08:55 -0800
Re: UB in asm already5chosen@yahoo.com - 2017-12-26 09:45 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-26 13:12 -0500
Re: UB in asm jameskuyper@verizon.net - 2017-12-26 10:30 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-26 13:48 -0500
Re: UB in asm already5chosen@yahoo.com - 2017-12-26 10:51 -0800
Re: UB in asm Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-12-27 05:27 -0800
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-27 10:09 +0100
Re: UB in asm already5chosen@yahoo.com - 2017-12-27 04:10 -0800
Re: UB in asm "James R. Kuyper" <jameskuyper@verizon.net> - 2017-12-27 08:50 -0500
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-27 14:30 +0000
Re: UB in asm jameskuyper@verizon.net - 2017-12-27 06:49 -0800
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-27 15:25 +0000
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-27 17:05 +0100
Re: UB in asm supercat@casperkitty.com - 2017-12-27 09:45 -0800
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-27 20:40 +0100
Re: UB in asm supercat@casperkitty.com - 2017-12-27 12:43 -0800
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-28 10:09 +0100
Re: UB in asm Geoff <geoff@invalid.invalid> - 2017-12-28 11:24 -0800
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-29 08:59 +0100
Re: UB in asm Geoff <geoff@invalid.invalid> - 2017-12-29 13:25 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-29 11:29 -0500
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-27 18:06 +0000
Re: UB in asm Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-27 20:23 +0000
Re: UB in asm supercat@casperkitty.com - 2017-12-27 12:59 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-27 16:28 -0500
Re: UB in asm supercat@casperkitty.com - 2017-12-27 14:34 -0800
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-28 11:09 +0100
Re: UB in asm supercat@casperkitty.com - 2017-12-28 08:57 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-28 09:37 -0500
Re: UB in asm supercat@casperkitty.com - 2017-12-28 10:47 -0800
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-28 11:04 +0100
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-27 21:17 +0000
Re: UB in asm Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-28 01:45 +0000
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-28 11:11 +0100
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-27 16:17 -0500
Re: UB in asm supercat@casperkitty.com - 2017-12-27 13:51 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-27 17:49 -0500
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-27 22:08 +0000
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-27 17:41 -0500
Re: UB in asm supercat@casperkitty.com - 2017-12-27 15:36 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-29 11:49 -0500
Re: UB in asm supercat@casperkitty.com - 2017-12-29 12:53 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-29 21:27 -0500
Re: UB in asm supercat@casperkitty.com - 2017-12-29 20:42 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-30 20:50 -0500
Re: UB in asm supercat@casperkitty.com - 2018-01-02 08:41 -0800
Re: UB in asm supercat@casperkitty.com - 2017-12-27 14:41 -0800
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-28 10:58 +0100
Re: UB in asm already5chosen@yahoo.com - 2017-12-28 03:46 -0800
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-28 08:41 -0800
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-28 12:15 +0000
Re: UB in asm Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-12-28 05:23 -0800
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-28 13:49 +0000
Re: UB in asm Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-28 14:42 +0000
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-28 11:56 -0500
Re: UB in asm supercat@casperkitty.com - 2017-12-28 09:58 -0800
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-28 11:07 -0800
Re: UB in asm supercat@casperkitty.com - 2017-12-28 13:32 -0800
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-28 13:54 -0800
Re: UB in asm supercat@casperkitty.com - 2017-12-28 14:06 -0800
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-28 15:14 -0800
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-28 19:45 +0000
Re: UB in asm Ian Collins <ian-news@hotmail.com> - 2017-12-29 08:51 +1300
Re: UB in asm supercat@casperkitty.com - 2017-12-28 12:14 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-28 20:03 -0500
Re: UB in asm already5chosen@yahoo.com - 2017-12-29 02:28 -0800
Re: UB in asm Geoff <geoff@invalid.invalid> - 2017-12-29 13:54 -0800
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-29 14:51 -0800
Re: UB in asm Geoff <geoff@invalid.invalid> - 2017-12-29 16:04 -0800
Re: UB in asm Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-30 02:06 +0000
Re: UB in asm supercat@casperkitty.com - 2017-12-29 11:22 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-29 21:48 -0500
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-29 09:11 +0100
Re: UB in asm Spiros Bousbouras <spibou@gmail.com> - 2017-12-29 08:52 +0000
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-29 10:58 +0100
Re: UB in asm Spiros Bousbouras <spibou@gmail.com> - 2017-12-29 10:38 +0000
Re: UB in asm already5chosen@yahoo.com - 2017-12-29 03:01 -0800
Re: UB in asm already5chosen@yahoo.com - 2017-12-29 03:07 -0800
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-29 12:21 +0100
Re: UB in asm supercat@casperkitty.com - 2017-12-29 12:20 -0800
Re: UB in asm Robert Wessel <robertwessel2@yahoo.com> - 2017-12-29 16:05 -0600
Re: UB in asm supercat@casperkitty.com - 2017-12-29 14:48 -0800
Re: UB in asm Spiros Bousbouras <spibou@gmail.com> - 2017-12-29 23:05 +0000
Re: UB in asm supercat@casperkitty.com - 2017-12-29 17:12 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-29 22:09 -0500
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-29 21:56 -0500
Re: UB in asm Robert Wessel <robertwessel2@yahoo.com> - 2017-12-30 00:58 -0600
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-29 11:43 +0000
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-29 15:14 +0100
Re: UB in asm Geoff <geoff@invalid.invalid> - 2017-12-29 14:11 -0800
Re: UB in asm Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-30 02:27 +0000
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-29 22:25 -0500
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-28 14:55 +0100
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-28 08:46 -0800
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-28 17:50 +0100
Re: UB in asm Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-28 14:30 +0000
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-28 11:29 -0500
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-28 17:46 +0100
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-28 12:17 -0500
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-28 09:25 -0800
Re: UB in asm Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-28 17:08 +0000
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-28 14:57 +0000
Re: UB in asm Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-28 16:09 +0000
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-28 17:11 +0100
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-28 17:04 +0000
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-28 09:16 -0800
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-28 20:44 +0100
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-28 20:13 +0000
Re: UB in asm supercat@casperkitty.com - 2017-12-28 12:48 -0800
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-29 11:03 +0100
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-28 13:08 -0800
Re: UB in asm Ian Collins <ian-news@hotmail.com> - 2017-12-29 11:17 +1300
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-28 22:54 +0000
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-29 11:07 +0100
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-28 15:46 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-28 17:00 -0500
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-28 23:39 +0000
Re: UB in asm supercat@casperkitty.com - 2017-12-28 16:05 -0800
Re: UB in asm Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-12-28 15:55 -0800
Re: UB in asm Spiros Bousbouras <spibou@gmail.com> - 2017-12-29 07:49 +0000
Re: UB in asm Reinhardt Behm <rbehm@hushmail.com> - 2017-12-29 15:46 +0800
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-29 10:34 +0100
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-29 12:05 +0000
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-29 14:51 +0100
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-29 15:09 +0000
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-29 09:05 -0800
Re: UB in asm supercat@casperkitty.com - 2017-12-29 13:35 -0800
Re: UB in asm Robert Wessel <robertwessel2@yahoo.com> - 2017-12-29 15:38 -0600
Re: UB in asm supercat@casperkitty.com - 2017-12-29 14:15 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-29 18:07 -0500
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-30 13:12 +0100
Re: UB in asm Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-12-30 05:19 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-30 09:33 -0500
Re: UB in asm supercat <flatfinger@casperkitty.com> - 2017-12-30 09:50 -0800
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-30 21:47 +0100
Re: UB in asm supercat@casperkitty.com - 2017-12-30 13:26 -0800
Re: UB in asm Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-12-30 13:53 -0800
Re: UB in asm supercat@casperkitty.com - 2017-12-30 14:19 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-30 19:13 -0500
Re: UB in asm Reinhardt Behm <rbehm@hushmail.com> - 2017-12-29 15:42 +0800
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-29 20:33 +0000
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-29 18:27 -0500
Re: UB in asm Ian Collins <ian-news@hotmail.com> - 2017-12-30 12:49 +1300
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-29 23:56 +0000
Re: UB in asm supercat@casperkitty.com - 2017-12-29 16:59 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-29 22:45 -0500
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-30 12:49 +0000
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-30 15:01 -0500
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-30 20:42 +0000
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-30 14:11 -0800
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-30 22:25 +0000
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-30 19:02 -0500
Re: UB in asm already5chosen@yahoo.com - 2017-12-31 03:25 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-31 19:48 -0500
Re: UB in asm supercat@casperkitty.com - 2018-01-02 12:08 -0800
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-28 11:40 -0500
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-28 17:35 +0000
Re: UB in asm Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-28 18:19 +0000
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-28 14:31 -0500
Re: UB in asm jameskuyper@verizon.net - 2017-12-27 08:52 -0800
Re: UB in asm Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-27 17:51 +0000
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-27 18:34 +0000
Re: UB in asm Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-27 21:14 +0000
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-27 21:51 +0000
Re: UB in asm Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-28 02:09 +0000
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-28 12:21 +0100
Re: UB in asm asetofsymbols@gmail.com - 2017-12-28 00:14 -0800
Re: UB in asm supercat@casperkitty.com - 2017-12-27 08:57 -0800
Re: UB in asm Keith Thompson <kst-u@mib.org> - 2017-12-27 09:55 -0800
Re: UB in asm supercat@casperkitty.com - 2017-12-27 11:07 -0800
Re: UB in asm Geoff <geoff@invalid.invalid> - 2017-12-27 22:04 -0800
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-28 12:27 +0100
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-27 11:05 -0500
Re: UB in asm Ian Collins <ian-news@hotmail.com> - 2017-12-28 16:36 +1300
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-28 12:31 +0000
Re: UB in asm bartc <bc@freeuk.com> - 2017-12-28 12:35 +0000
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-28 15:05 +0100
Re: UB in asm Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-28 14:47 +0000
Re: UB in asm Richard Damon <Richard@Damon-Family.org> - 2017-12-28 11:45 -0500
Re: UB in asm supercat@casperkitty.com - 2017-12-28 09:16 -0800
Re: UB in asm supercat@casperkitty.com - 2017-12-28 11:00 -0800
Re: UB in asm Reinhardt Behm <rbehm@hushmail.com> - 2017-12-29 15:30 +0800
Re: UB in asm supercat@casperkitty.com - 2017-12-29 11:44 -0800
Re: UB in asm Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-12-28 15:25 -0800
Re: UB in asm Spiros Bousbouras <spibou@gmail.com> - 2017-12-29 08:14 +0000
Re: UB in asm Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-12-29 03:29 -0800
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-29 14:57 +0100
Re: UB in asm supercat@casperkitty.com - 2017-12-29 12:32 -0800
Re: UB in asm jameskuyper@verizon.net - 2017-12-28 10:55 -0800
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-27 16:19 +0100
Re: UB in asm supercat@casperkitty.com - 2017-12-27 09:10 -0800
Re: UB in asm supercat@casperkitty.com - 2017-12-26 11:54 -0800
Re: UB in asm David Brown <david.brown@hesbynett.no> - 2017-12-27 09:59 +0100
Re: UB in asm already5chosen@yahoo.com - 2017-12-24 07:03 -0800
Page 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-12-29 16:05 -0600 |
| Subject | Re: UB in asm |
| Message-ID | <07ed4d90t0hqug8gojhevk06qmh3qhodf3@4ax.com> |
| In reply to | #124912 |
On Fri, 29 Dec 2017 12:20:43 -0800 (PST), supercat@casperkitty.com
wrote:
>On Friday, December 29, 2017 at 3:59:12 AM UTC-6, David Brown wrote:
>> On 29/12/17 09:52, Spiros Bousbouras wrote:
>> > An option would be for a standard way (like a #pragma) to allow the
>> > programmer to choose between the following possibilities for signed integer
>> > arithmetic (for unsigned I'm guessing nothing can be changed for reasons of
>> > backwards compatibility) :
>> >
>> > * Wraparound
>> > * Saturation arithmetic
>> > * An application defined error handler function gets called if the result
>> > exceeds bounds.
>> > * Anything goes i.e. undefined behaviour.
>
>> > The problem is that for the first 3 options it imposes a performance penalty
>> > even when the programmer (but not the compiler) can prove that the operation
>> > will not exceed bounds.
>
>There are a number of additional possibilities:
>
> 1. Behave as though computation was performed on a larger type, but
> truncate the result back to the size of any defined object into
> which it is stored or converted.
A bit simplified, that's how Cobol does it, and Cobol allows an
exception-like attachment to the assignment to allow an overflow to be
caught. So there is precedent. So:
compute a = b*c+d*e
on size error
display "It's too big, Jim!".
will only overflow if the result will not fit in a. So
b/c/d/e=10000/20000/-19999/10001 would produce the expected result in
a (-9999), even if all the variables involved were sixteen bit integer
types. OTOH, if d were -1 instead, the "on size error" clause would
be triggered.
I've always thought that for a general purpose programming language,
that makes more sense than doing arithmetic in the types specified.
OTOH, the latter behavior seems appropriate to a low level language. C
(and C++) can't quite seem to decide if they want to be low level or
not, and they're certainly often used in situations where a
non-low-level language would be appropriate.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-29 14:48 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <00ed150d-7fad-4e22-9866-1d5cc7b829ae@googlegroups.com> |
| In reply to | #124922 |
On Friday, December 29, 2017 at 4:05:12 PM UTC-6, robert...@yahoo.com wrote: > I've always thought that for a general purpose programming language, > that makes more sense than doing arithmetic in the types specified. > OTOH, the latter behavior seems appropriate to a low level language. C > (and C++) can't quite seem to decide if they want to be low level or > not, and they're certainly often used in situations where a > non-low-level language would be appropriate. What you describe is how C originally did things--all numeric computations were done using either the one and only integer type suitable for computations (even when operating upon objects of type 'char') or the one and only floating-point type used for computations (even when the operands were of type 'float'). Adding "long" to the language while passing most integer values as "int" made things more complicated. IMHO, the language might have been better if conversions between "int" and "long" were required to be more explicit in cases where more than one behavior would make sense. Further, it would have been helpful for the Standard to specify a directive indicating a minimum width to which expressions must promote; compilers could reject programs whose needs they couldn't satisfy, but the existence of such a directive, along with algebraic ring types which are distinct from numeric types, would eliminate the need to have expressions' meanings vary based upon a system's integer size.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2017-12-29 23:05 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <beBfYArit4KiC5FMuFgl4K4diEpqH@bongo-ra.co> |
| In reply to | #124922 |
On Fri, 29 Dec 2017 16:05:01 -0600 Robert Wessel <robertwessel2@yahoo.com> wrote: > On Fri, 29 Dec 2017 12:20:43 -0800 (PST), supercat@casperkitty.com > wrote: > > >On Friday, December 29, 2017 at 3:59:12 AM UTC-6, David Brown wrote: > >> On 29/12/17 09:52, Spiros Bousbouras wrote: > >> > An option would be for a standard way (like a #pragma) to allow the > >> > programmer to choose between the following possibilities for signed integer > >> > arithmetic (for unsigned I'm guessing nothing can be changed for reasons of > >> > backwards compatibility) : > >> > > >> > * Wraparound > >> > * Saturation arithmetic > >> > * An application defined error handler function gets called if the result > >> > exceeds bounds. > >> > * Anything goes i.e. undefined behaviour. > > > >> > The problem is that for the first 3 options it imposes a performance penalty > >> > even when the programmer (but not the compiler) can prove that the operation > >> > will not exceed bounds. > > > >There are a number of additional possibilities: > > > > 1. Behave as though computation was performed on a larger type, but > > truncate the result back to the size of any defined object into > > which it is stored or converted. > > > A bit simplified, that's how Cobol does it, and Cobol allows an > exception-like attachment to the assignment to allow an overflow to be > caught. So there is precedent. So: > > compute a = b*c+d*e > on size error > display "It's too big, Jim!". > > will only overflow if the result will not fit in a. So > b/c/d/e=10000/20000/-19999/10001 would produce the expected result in > a (-9999), even if all the variables involved were sixteen bit integer > types. OTOH, if d were -1 instead, the "on size error" clause would > be triggered. So COBOL performs integer arithmetic using arbitracy precision ? If not then what would happen if it could not compute correctly b*c+d*e regardless of how many bits a itself can hold ? Anyway , I'm not sure this is the same as what supercat is suggesting. He said "truncate" which I took it to mean that in the end what (in your example) a would get would be unpredictable since you wouldn't know if truncation occurred. -- > bad idea for engineers to play lawyers. "Engineer" means "someone who takes dreams and makes them real". "Lawyer" means "someone who takes nightmares and makes them real". Sandy Wills https://www.ietf.org/mail-archive/web/ietf/current/msg21430.html
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-29 17:12 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <207632c5-6df8-4ae6-a057-5e333a30a4ac@googlegroups.com> |
| In reply to | #124929 |
On Friday, December 29, 2017 at 5:05:25 PM UTC-6, Spiros Bousbouras wrote: > So COBOL performs integer arithmetic using arbitracy precision ? If not > then what would happen if it could not compute correctly b*c+d*e > regardless of how many bits a itself can hold ? Anyway , I'm not sure > this is the same as what supercat is suggesting. He said "truncate" which > I took it to mean that in the end what (in your example) a would get > would be unpredictable since you wouldn't know if truncation occurred. From what I understand, COBOL generally guarantees that integer computations will either succeed or else signal an error. What I was proposing was to define a class of implementations which would behave as though they perform integer operations using mathematical integers and then, at their leisure, truncate the result to any convenient size which at least as big as the operands. Such a behavioral model would allow a compiler to replace (x+1 > y) with (x >= y) without regard for whether x might equal INT_MAX. If I were designing a language, I would say that all "numeric integer" computations should default to behaving as though they are performed with the largest signed type. In many cases, such behavior could be achieved without the generated code actually having to perform computations on the larger type. In places where such treatment would require extra code (e.g. evaluating int1+int2 > int3), having a compiler default to using the larger type may make code slower than would be ideal, but would yield correct behavior without surprises. If it's not necessary to handle values larger than int, having a syntax to specify "truncate if convenient" would allow the programmer to make that clear.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2017-12-29 22:09 -0500 |
| Subject | Re: UB in asm |
| Message-ID | <ArD1C.19337$b_.3721@fx23.iad> |
| In reply to | #124940 |
On 12/29/17 8:12 PM, supercat@casperkitty.com wrote: > On Friday, December 29, 2017 at 5:05:25 PM UTC-6, Spiros Bousbouras wrote: >> So COBOL performs integer arithmetic using arbitracy precision ? If not >> then what would happen if it could not compute correctly b*c+d*e >> regardless of how many bits a itself can hold ? Anyway , I'm not sure >> this is the same as what supercat is suggesting. He said "truncate" which >> I took it to mean that in the end what (in your example) a would get >> would be unpredictable since you wouldn't know if truncation occurred. > > From what I understand, COBOL generally guarantees that integer computations > will either succeed or else signal an error. > > What I was proposing was to define a class of implementations which would > behave as though they perform integer operations using mathematical integers > and then, at their leisure, truncate the result to any convenient size > which at least as big as the operands. > > Such a behavioral model would allow a compiler to replace (x+1 > y) with > (x >= y) without regard for whether x might equal INT_MAX. > > If I were designing a language, I would say that all "numeric integer" > computations should default to behaving as though they are performed with > the largest signed type. In many cases, such behavior could be achieved > without the generated code actually having to perform computations on the > larger type. In places where such treatment would require extra code (e.g. > evaluating int1+int2 > int3), having a compiler default to using the larger > type may make code slower than would be ideal, but would yield correct > behavior without surprises. If it's not necessary to handle values larger > than int, having a syntax to specify "truncate if convenient" would allow > the programmer to make that clear. > Forcing all calculations to even apparently be performed at the highest precision possible can add significant computational cost. The philosophy of C has always been lean to allowing the generation of efficient code when possible, and make the programmer identify when the slower methods would be needed. Note that int1 + int2 > int3, unless the implementation has a lot of information about values, will always require the slower calculation by your method, but if the programmer knows (and is frequently true) that the numbers are small enough that overflow won't happen, it isn't needed.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2017-12-29 21:56 -0500 |
| Subject | Re: UB in asm |
| Message-ID | <LfD1C.38074$Xx7.9854@fx16.iad> |
| In reply to | #124929 |
On 12/29/17 6:05 PM, Spiros Bousbouras wrote: > On Fri, 29 Dec 2017 16:05:01 -0600 > Robert Wessel <robertwessel2@yahoo.com> wrote: >> On Fri, 29 Dec 2017 12:20:43 -0800 (PST), supercat@casperkitty.com >> wrote: >> >>> On Friday, December 29, 2017 at 3:59:12 AM UTC-6, David Brown wrote: >>>> On 29/12/17 09:52, Spiros Bousbouras wrote: >>>>> An option would be for a standard way (like a #pragma) to allow the >>>>> programmer to choose between the following possibilities for signed integer >>>>> arithmetic (for unsigned I'm guessing nothing can be changed for reasons of >>>>> backwards compatibility) : >>>>> >>>>> * Wraparound >>>>> * Saturation arithmetic >>>>> * An application defined error handler function gets called if the result >>>>> exceeds bounds. >>>>> * Anything goes i.e. undefined behaviour. >>> >>>>> The problem is that for the first 3 options it imposes a performance penalty >>>>> even when the programmer (but not the compiler) can prove that the operation >>>>> will not exceed bounds. >>> >>> There are a number of additional possibilities: >>> >>> 1. Behave as though computation was performed on a larger type, but >>> truncate the result back to the size of any defined object into >>> which it is stored or converted. >> >> >> A bit simplified, that's how Cobol does it, and Cobol allows an >> exception-like attachment to the assignment to allow an overflow to be >> caught. So there is precedent. So: >> >> compute a = b*c+d*e >> on size error >> display "It's too big, Jim!". >> >> will only overflow if the result will not fit in a. So >> b/c/d/e=10000/20000/-19999/10001 would produce the expected result in >> a (-9999), even if all the variables involved were sixteen bit integer >> types. OTOH, if d were -1 instead, the "on size error" clause would >> be triggered. > > So COBOL performs integer arithmetic using arbitracy precision ? If not > then what would happen if it could not compute correctly b*c+d*e > regardless of how many bits a itself can hold ? Anyway , I'm not sure > this is the same as what supercat is suggesting. He said "truncate" which > I took it to mean that in the end what (in your example) a would get > would be unpredictable since you wouldn't know if truncation occurred. > It's been a long time since I wrote COBOL, but my understand was that COBOL had fixed sized numbers that it did its fixed point calculations in, and the ON SIZE ERROR clause would trigger on any intermediate overflow.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-12-30 00:58 -0600 |
| Subject | Re: UB in asm |
| Message-ID | <499e4dd0lpc958g1m3el2du1b0s8iuhdpf@4ax.com> |
| In reply to | #124929 |
On Fri, 29 Dec 2017 23:05:14 GMT, Spiros Bousbouras <spibou@gmail.com>
wrote:
>On Fri, 29 Dec 2017 16:05:01 -0600
>Robert Wessel <robertwessel2@yahoo.com> wrote:
>> On Fri, 29 Dec 2017 12:20:43 -0800 (PST), supercat@casperkitty.com
>> wrote:
>>
>> >On Friday, December 29, 2017 at 3:59:12 AM UTC-6, David Brown wrote:
>> >> On 29/12/17 09:52, Spiros Bousbouras wrote:
>> >> > An option would be for a standard way (like a #pragma) to allow the
>> >> > programmer to choose between the following possibilities for signed integer
>> >> > arithmetic (for unsigned I'm guessing nothing can be changed for reasons of
>> >> > backwards compatibility) :
>> >> >
>> >> > * Wraparound
>> >> > * Saturation arithmetic
>> >> > * An application defined error handler function gets called if the result
>> >> > exceeds bounds.
>> >> > * Anything goes i.e. undefined behaviour.
>> >
>> >> > The problem is that for the first 3 options it imposes a performance penalty
>> >> > even when the programmer (but not the compiler) can prove that the operation
>> >> > will not exceed bounds.
>> >
>> >There are a number of additional possibilities:
>> >
>> > 1. Behave as though computation was performed on a larger type, but
>> > truncate the result back to the size of any defined object into
>> > which it is stored or converted.
>>
>>
>> A bit simplified, that's how Cobol does it, and Cobol allows an
>> exception-like attachment to the assignment to allow an overflow to be
>> caught. So there is precedent. So:
>>
>> compute a = b*c+d*e
>> on size error
>> display "It's too big, Jim!".
>>
>> will only overflow if the result will not fit in a. So
>> b/c/d/e=10000/20000/-19999/10001 would produce the expected result in
>> a (-9999), even if all the variables involved were sixteen bit integer
>> types. OTOH, if d were -1 instead, the "on size error" clause would
>> be triggered.
>
>So COBOL performs integer arithmetic using arbitracy precision ? If not
>then what would happen if it could not compute correctly b*c+d*e
>regardless of how many bits a itself can hold ? Anyway , I'm not sure
>this is the same as what supercat is suggesting. He said "truncate" which
>I took it to mean that in the end what (in your example) a would get
>would be unpredictable since you wouldn't know if truncation occurred.
Well, I did say "a bit simplified"...
The short version is that it's arbitrary precision with limits.
Usually about 30-32 (decimal) digits are all that's guaranteed by most
implementations for intermediate results, after which you'll start
losing digits of precision.
The exact rules have evolved over time. The old, and still default,
"native" arithmetic has somewhat more ad-hoc rules, but in the current
specifications of "standard" (in three forms) the model for fixed
point arithmetic is defined similarly to operations on a large
floating point numbers containing integers. In the case of
"standard-binary" and "standard-decimal", the rules are built on top
of 128-bit IEEE binary and decimal floats doing operations on
integers, in the case of "standard" (and what's now the minimum for
"native"), the representation is more-or-less a float with 32-decimal
digit mantissa and a three decimal digit exponent).
So basically, if your intermediate results on fixed point numbers
never exceed the ~30 digit limit, you will get exact results, but some
implementations will provide more. Beyond that you may lose
precision, but you won't overflow (at least on semi-modern systems),
until your intermediates actually exceed about 10*999 ("standard", and
the current minimum for "native"), or the limits for a IEEE 128-bit
binary or decimal float ("standard-binary" or "standard-decimal").
Operations such as division and exponentiation have additional rules.
Intermediate results are not applicable to all arithmetic, and simple
operations ("add a to b", "multiply c by d"), simply generate exact
results (most of the time that's a distinction with no practical
difference, but it can have an impact on arithmetic with very long
numbers).
In the modern versions you can specify rules for intermediate
rounding, or forbid it, and get an exception if it occurs.
Note that decimal scaling is a separate thing, so if you multiply a
five digit field with three decimal places and a six digit field with
two decimal places, you get a multiplication of a five digit and six
digit integer resulting in a eleven digit number (and that's where the
above rules apply), and scaling the five decimal places happens as
needed at the assignment.
The "compute a = b*c + d*e" in my original example generates three
intermediate results (the results of the two multiplications, and the
result of the addition), and any scaling would occur at the
assignment.
If you add actual floating point numbers to the mix, the rules are a
bit different, but more-or-less at some point fixed point values
convert to float at some point when they're combined with FP values,
although scaling remains a somewhat separate issue.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-29 11:43 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <YSp1C.180853$wk7.132540@fx28.am4> |
| In reply to | #124882 |
On 29/12/2017 08:11, David Brown wrote: > On 28/12/17 20:45, bartc wrote: >> On 28/12/2017 16:56, Richard Damon wrote: >>> On 12/28/17 8:49 AM, bartc wrote: >> >>>> But C refuses to acknowledge that for signed ints. >> >>> The big issue for signed integers is that when the standard was first >>> forming, 2's complement wrapping arithmetic wasn't as universal as it >>> is now, >> I'm surprised. When was the standard first created? >> >> I got into computing from the mid-70s, and all the machines I remember >> using, or all the ones I've investigated, were two's complement. >> > > Yes, but you only used little systems (like Z80 processors). (That is > not criticism in any way - no one starts off programming million dollar > machines!) Big iron had a much greater variety of bit sizes, encodings, > number formats, etc. The first machine I used at college was a DEC PDP10, which I remember costing half a million pounds. Rather more than a million dollars at the time. I wrote quite a bit of assembly on it, including a compiler. PDP10 was two's complement. Another mainframe I used was called ICL 4/72, which I believe was an IBM 360 clone. Two's complement. I also used a DEC PDP11; two's complement. That's three of the machines on already5chosen's list of four. And that's before we come to all the microprocessors. Now I've been told the first C standard was over a decade later than this period in the late 70s. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-29 15:14 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p25il0$91a$1@dont-email.me> |
| In reply to | #124896 |
On 29/12/17 12:43, bartc wrote: > On 29/12/2017 08:11, David Brown wrote: >> On 28/12/17 20:45, bartc wrote: >>> On 28/12/2017 16:56, Richard Damon wrote: >>>> On 12/28/17 8:49 AM, bartc wrote: >>> >>>>> But C refuses to acknowledge that for signed ints. >>> >>>> The big issue for signed integers is that when the standard was first >>>> forming, 2's complement wrapping arithmetic wasn't as universal as it >>>> is now, >>> I'm surprised. When was the standard first created? >>> >>> I got into computing from the mid-70s, and all the machines I remember >>> using, or all the ones I've investigated, were two's complement. >>> >> >> Yes, but you only used little systems (like Z80 processors). (That is >> not criticism in any way - no one starts off programming million dollar >> machines!) Big iron had a much greater variety of bit sizes, encodings, >> number formats, etc. > > The first machine I used at college was a DEC PDP10, which I remember > costing half a million pounds. Rather more than a million dollars at the > time. I wrote quite a bit of assembly on it, including a compiler. OK, /students/ get to start of programming on million dollar machines :-) > > PDP10 was two's complement. > > Another mainframe I used was called ICL 4/72, which I believe was an IBM > 360 clone. Two's complement. I also used a DEC PDP11; two's complement. > > That's three of the machines on already5chosen's list of four. And > that's before we come to all the microprocessors. And there are other machines that had different formats. Apparently (according to Wikipedia) the Univac 1100/2200 series machines have been one's complement all the way from their introduction in 1962 to their latest models released in 2015 (where I believe the instruction set, including the one's complement arithmetic, is emulated on Xeons). > > Now I've been told the first C standard was over a decade later than > this period in the late 70s. > When C was first developed, two's complement was becoming dominant - but it was not the only game in town, and other systems were in use for a long time afterwards. I'd be surprised if there are many C89 compilers for non-two's complement machines, however, and astounded if there are any C99 compilers for such machines. So I would be in favour of dropping all mention of other signed integer formats (and also all mention of padding bits in the integer types) from future C standards. But I still don't want signed overflow to be defined behaviour.
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2017-12-29 14:11 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <qoed4dto8dtuiefv28hd639hjn5e57lq4b@4ax.com> |
| In reply to | #124896 |
On Fri, 29 Dec 2017 11:43:03 +0000, bartc <bc@freeuk.com> wrote: >Now I've been told the first C standard was over a decade later than >this period in the late 70s. The first C, as written by Dennis M. Ritchie (DMR) was first implemented on the PDP-7 (1964), a 2c machine, and ran the first Unix in 1972. It was a version of B with types. The next target was the PDP-11 (1970), also 2c and it was this C that was documented by DMR and Ken Thompson in the first edition of "The C Programming Language" (1978) referred to as "K&R C". It was not until 1988 that the ANSI X3J11 committee codified the ANSI X3.159-1989 "Standard". Prior to the publication of K&R C the only standard was the compiler itself and its supporting text documentation.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-30 02:27 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <87o9mh7xwz.fsf@bsb.me.uk> |
| In reply to | #124923 |
Geoff <geoff@invalid.invalid> writes: > On Fri, 29 Dec 2017 11:43:03 +0000, bartc <bc@freeuk.com> wrote: > >>Now I've been told the first C standard was over a decade later than >>this period in the late 70s. > > The first C, as written by Dennis M. Ritchie (DMR) was first > implemented on the PDP-7 (1964), a 2c machine, and ran the first Unix > in 1972. I don't think this is correct. C was properly born on the PDP-11. The PDP-7 Unix version was in assembler. There was a B implementation on the PDP-7, but "new B" was started around the time B was ported to the PDP-11. I don't think there was ever a PDP-7 C implementation. As for the PDP-7 being 1- or 2s complement, I pass. I think it was 1s complement but it did have a 2s complement add instruction. I'm not really sure what that even means! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2017-12-29 22:25 -0500 |
| Subject | Re: UB in asm |
| Message-ID | <rGD1C.82442$bJ2.51673@fx07.iad> |
| In reply to | #124943 |
On 12/29/17 9:27 PM, Ben Bacarisse wrote: > Geoff <geoff@invalid.invalid> writes: > >> On Fri, 29 Dec 2017 11:43:03 +0000, bartc <bc@freeuk.com> wrote: >> >>> Now I've been told the first C standard was over a decade later than >>> this period in the late 70s. >> >> The first C, as written by Dennis M. Ritchie (DMR) was first >> implemented on the PDP-7 (1964), a 2c machine, and ran the first Unix >> in 1972. > > I don't think this is correct. C was properly born on the PDP-11. The > PDP-7 Unix version was in assembler. There was a B implementation on > the PDP-7, but "new B" was started around the time B was ported to the > PDP-11. I don't think there was ever a PDP-7 C implementation. > > As for the PDP-7 being 1- or 2s complement, I pass. I think it was 1s > complement but it did have a 2s complement add instruction. I'm not > really sure what that even means! > I worked on a PDP-7. It had two add instructions, ADD which added in 1's complement and TAD which added in 2's complement. 1's complement was prefered, as there was a complement (1's complement negation) but I think you needed to do complement then an increment to do a 2's complement negation (to do a subtraction). The development environment I remember as preferring 1's complement. The multiply instruction assumed 1's complement values when you had the EAE moduule.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-28 14:55 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p22t4a$1s1$1@dont-email.me> |
| In reply to | #124814 |
On 28/12/17 13:15, bartc wrote:
> On 28/12/2017 09:58, David Brown wrote:
>> On 27/12/17 19:06, bartc wrote:
>
>> Your problem here is that you believe it is important to be able to
>> predict the behaviour of incorrect and meaningless programs.
>
> Written in ASM for x86, the behaviour is completely predictable.
ASM is not C.
>
> It seems that that is one program that it is impossible to port to C and
> get the same predictable results with any C compiler.
It is perfectly possible to port to C (assuming I have correctly guessed
what you want the code to do). You just have to write it correctly.
In this case, it is very easy - replace the line:
++a;
with
a = (uint32_t) a + 1;
As you know, unsigned integer addition has wraparound (modulo)
semantics. Conversion of the int32_t "a" to "uint32_t" is fully defined
by the standards in the way that you would expect. The 1 is promoted to
unsigned (assuming here that an "int" is not bigger than 32 bits, which
is true for most targets). The addition is performed with wrapping.
The conversion back to a signed integer type is implementation-defined -
gcc handles it in the way you would most likely expect on two's
complement machines:
<https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html>
>
> (Actually, you can, provided you don't use gcc-O2/O3. So you can't use
> gcc if you want a compatible C version, if you also want it fast. Which
> is funny because being fast might be the only reason people will use gcc.)
Of course you can do it - as I showed above. You can also use the
program as-is with gcc, with "-fwrapv" and whatever optimisations you
want, including -O2 and -O3.
What you cannot do is use the program you wrote as-is and expect it to
work correctly without additional limitations on the compiler. It is
not a matter of it failing on some compiler/flag combinations - it is a
matter of it only succeeding on some compiler/flag combinations. Your
selection of test compilers is mostly limited, special purpose or toy
compilers - there is no /a priori/ reason to believe that other quality
optimising compilers will be different from gcc here.
Oh, and as you know there are /many/ reasons I choose to use gcc - speed
is only one of them, and it is not the most important one. I can't
really speak for other people, but I expect the same applies to others.
>
>> A compiler is a program. Garbage in, garbage out. A C compiler that
>> gives consistent results for a program with integer overflow or other
>> undefined behaviour is no "simpler", "smarter", or "more helpful" than
>
> Here are the first 20 factorials calculated with a C program using
> signed int:
>
> 0! = 1
> 1! = 1
> 2! = 2
> 3! = 6
> 4! = 24
> 5! = 120
> 6! = 720
> 7! = 5040
> 8! = 40320
> 9! = 362880
> 10! = 3628800
> 11! = 39916800
> 12! = 479001600
> 13! = 1932053504
> 14! = 1278945280
> 15! = 2004310016
> 16! = 2004189184
> 17! = -288522240
> 18! = -898433024
> 19! = 109641728
> 20! = -2102132736
>
> It starts going wrong from 13! onwards. Here are the results when using
> unsigned int:
>
> 0! = 1
> 1! = 1
> 2! = 2
> 3! = 6
> 4! = 24
> 5! = 120
> 6! = 720
> 7! = 5040
> 8! = 40320
> 9! = 362880
> 10! = 3628800
> 11! = 39916800
> 12! = 479001600
> 13! = 1932053504
> 14! = 1278945280
> 15! = 2004310016
> 16! = 2004189184
> 17! = 4006445056
> 18! = 3396534272
> 19! = 109641728
> 20! = 2192834560
>
> It's STILL going wrong from 13! onwards. Fat lot of difference using
> unsigned, with its well-defined overflow, has made! (13! requires 33
> bits unsigned to represent, or 34 bits signed.)
>
Using "unsigned" instead of "signed" does not make incorrect code
correct - any more than giving a definition to signed integer overflow
would do so. Why would you think so?
> So you don't magically avoid GIGO simply by avoiding signed overflow.
>
You avoid GIGO (in this case) by avoiding /overflow/ - the signedness
has nothing to do with it.
> This is a programming issue pure and simple. Throwing UB into the works
> (which could have meant strange behaviour on the first lot of output)
> does not help.
No one claimed undefined behaviour helps fix this broken code. But
certainly we can be sure that having /defined/ behaviour for signed
overflow will not fix it. Having /undefined/ behaviour for signed
overflow can give the compiler a chance of spotting a problem and
warning about it, which can be very helpful. (gcc does not spot an
error here, but it did on your previous example with signed integer
overflow.)
Here is a result of my testing:
$ cat f.c
#include <stdio.h>
#include <stdint.h>
int main(void) {
int f = 1;
for (int i = 1; i < 20; i++) {
f = f * i;
printf("%i! = %i\n", i, f);
}
}
$ gcc -o x f.c -O3 -Wall -Wextra -fsanitize=undefined
1! = 1
2! = 2
3! = 6
4! = 24
5! = 120
6! = 720
7! = 5040
8! = 40320
9! = 362880
10! = 3628800
11! = 39916800
12! = 479001600
f.c:7:5: runtime error: signed integer overflow: 479001600 * 13 cannot
be represented in type 'int'
13! = 1932053504
14! = 1278945280
15! = 2004310016
16! = 2004189184
17! = -288522240
18! = -898433024
19! = 109641728
Note that if I add "-fwrapv" to give signed integer overflow a defined
behaviour (the way you like), no runtime error is given and you need to
check manually for the bug.
That is one of the two reasons I /want/ signed overflow to be undefined
- it makes it easier to find faults in the code.
>
>> I think most of us get on just fine. We write code that makes sense,
>> and it works as expected. Baring occasional situations like timers with
>> limited lengths, signed integer overflow means a bug in the code
>
> Fine, let us have a bug in the code. AUIU, having it cause UB if
> detected by the compiler which then follows its own agenda does not fix
> the bug.
If the compiler detects a fault in the code (as it did in your first
example, at least with later versions of gcc), then it does not fix the
bug - it helps /you/ fix the bug. If the fault is not detected, you are
no worse off with undefined behaviour than with defined but incorrect
behaviour.
>
>>> This is a low-level language: fixed-width integer ops can overflow.
>>
>> No, they don't.
>
> I said fixed-width, so yes they can. Using larger width doesn't work.
No, they don't overflow. Write your code correctly, and there are no
overflows. If you have overflows, your code is wrong. (As always, this
is excluding the few legitimate cases of overflow - and in C you use
unsigned types in those situations.)
Correct code does not have arithmetic overflows - no matter what the
width of the types.
>
> What width would you use here, where each variable is already 64 bits,
> to ensure the result will not overflow:
>
> a * b * c * d * e
>
I would write code that fits the reality of the problem at hand. Either
we know that these variables always hold values whose product (and
partial products along the way) will not overflow, or you need to write
different code. Multiplying them all together like that and hoping for
the best is not programming.
A real-world situation might be when these values represent scaled
integers. In such cases, the answer is you do it /carefully/, with
appropriate scalings at the right points, ensuring that your code makes
sense at each step.
>
>> If I want to work with values that might be bigger than an int, I use a
>> type that is bigger than an int - and thus get correct answers. It
>> really is that simple.
>
> No it isn't, as I showed above. You've just moved the problem elsewhere.
>
See above.
>
>
>> What kind of insanity would make you think it is /sensible/ to take 2
>> billion apples, add another 2 billion apples, and end up with minus 295
>> million apples? It is /stupid/. It is /wrong/. It is /meaningless/.
>> It is an utterly pointless definition.
>
> But 3 billion apples plus 3 billion equalling 1.7 billion isn't stupid
> and meaningless when using unsigned?
As I have said many times, addition with overflow - except in special
circumstances - is meaningless whether it is signed or unsigned. How
many times must I say it?
>
> Or 1 apple minus 2 apples equalling 4294967295 applies isn't stupid and
> meaningless when using unsigned?
>
> You can get crazy arithmetic results with both. But only code invoking
> signed overflow gets blown out of the water.
>
In C, unsigned overflow has defined behaviour, signed overflow does not.
In neither case will it make an incorrect program correct, or turn
meaningless results into meaningful ones.
> ing C code, I am not in the business of writing hardware.
>> I don't care about which gates are used on the cpu. I don't even care
>> which instructions are used in the assembly. I /do/ care that my code
>> makes sense - and in almost all cases, if my signed integer arithmetic
>> overflows then the code is wrong regardless of whether the wrong answer
>> is predictable or not.
>
> If the code is wrong then it's wrong. But why wouldn't a compiler just
> compile the code as you intended?
The definition of C - from the C standards, plus any
implementation-specific behaviour (including any optional ones from
flags such as "-fwrapv") - provides the language in which you tell the
compiler what you intend. If you write code that does not have defined
behaviour, the compiler does not know what you intend!
When you write code with undefined behaviour, you are not writing
meaningful code. The compiler /trusts/ you ($DEITY knows why, in your
particular case). It assumes that there are no code paths that will
lead to the meaningless result, or that you don't care what happens if
the meaningless code is reached.
What the compiler certainly does not do is make guesses as to what it
thinks the programmer might have meant - even if it seems obvious to the
programmer.
> I expect to get the same output with
> the test on any compiler with any options on x86 and any other machine
> that implements arithmetic the same way.
>
I don't expect that - because the code was not valid C.
> On one of those mysterious machines that do arithmetic differently, I
> might expect different results. C is supposed to be 'close to the
> metal', no?
Yes - but you have to write in C.
>
>> C requires thought and understanding. Perhaps that does not suit you.
>
> C could have been so much better. Not requiring extra thought and
> understanding beyond what is already needed when programming in a
> low-level language. It just makes a hard job much harder.
>
I agree that C could have been better, and could be improved. But I
disagree with you on pretty much every point where /you/ think it could
be better. Regarding undefined overflow behaviour, I would prefer to
have /more/ undefined behaviour - having unsigned integer types with
overflow undefined in order to provide more optimisations and (more
importantly) more static error checking. I'd still want types with
defined overflow behaviour for their occasional use - for backwards
compatibility, such unsigned types would have to be additional new types.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-28 08:46 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <ln8tdmer6x.fsf@kst-u.example.com> |
| In reply to | #124819 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> As I have said many times, addition with overflow - except in special
> circumstances - is meaningless whether it is signed or unsigned. How
> many times must I say it?
[...]
Are you under the impression that there is a defined answer to
that question? Do you think that bartc will acknowledge the point
after the Nth time we explain it to him, for *any* value of N?
The evidence suggests otherwise.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-28 17:50 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p237bv$d4v$1@dont-email.me> |
| In reply to | #124832 |
On 28/12/17 17:46, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> As I have said many times, addition with overflow - except in special >> circumstances - is meaningless whether it is signed or unsigned. How >> many times must I say it? > [...] > > Are you under the impression that there is a defined answer to > that question? Do you think that bartc will acknowledge the point > after the Nth time we explain it to him, for *any* value of N? > > The evidence suggests otherwise. > It is /possible/ that he will catch on to this one - I have only said it a handful of times so far. So I haven't given up on this particular point yet. He'll have forgotten it again by the next thread, however.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-28 14:30 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <87bmiic4bt.fsf@bsb.me.uk> |
| In reply to | #124814 |
bartc <bc@freeuk.com> writes:
> On 28/12/2017 09:58, David Brown wrote:
>> On 27/12/17 19:06, bartc wrote:
>
>> Your problem here is that you believe it is important to be able to
>> predict the behaviour of incorrect and meaningless programs.
>
> Written in ASM for x86, the behaviour is completely predictable.
... and non-portable.
> It seems that that is one program that it is impossible to port to C
> and get the same predictable results with any C compiler.
Don't be silly, you just have to write well-defined C. There are dozens
of way to do that but the obvious one is to say what you want to happen
when 'a' would overflow:
#include <stdio.h>
#include <stdint.h>
int main(void)
{
int32_t a = INT32_MAX-5;
for (int i = 1; i <= 10; ++i) {
printf("%2d %+d",i, a);
if (a == INT32_MIN)
printf(" INT32_MIN");
else if (a == INT32_MAX) {
printf(" INT32_MAX");
a = INT32_MIN;
}
else ++a;
printf("\n");
}
}
>> A compiler is a program. Garbage in, garbage out. A C compiler that
>> gives consistent results for a program with integer overflow or other
>> undefined behaviour is no "simpler", "smarter", or "more helpful" than
>
> Here are the first 20 factorials calculated with a C program using
> signed int:
No. This is the output from a program whose behaviour is not defined by
C. In a some sense it is not a C program -- not a well-defined one at
least.
> It starts going wrong from 13! onwards. Here are the results when
> using unsigned int:
>
> 0! = 1
> 1! = 1
> 2! = 2
> 3! = 6
> 4! = 24
> 5! = 120
> 6! = 720
> 7! = 5040
> 8! = 40320
> 9! = 362880
> 10! = 3628800
> 11! = 39916800
> 12! = 479001600
> 13! = 1932053504
> 14! = 1278945280
> 15! = 2004310016
> 16! = 2004189184
> 17! = 4006445056
> 18! = 3396534272
> 19! = 109641728
> 20! = 2192834560
>
> It's STILL going wrong from 13! onwards.
I used to caution students against this sort of language. Own your
mistakes! "It" is not suddenly "going wrong" -- you wrote the wrong
program. The output is (probably) exactly as you requested.
> Fat lot of difference using unsigned, with its well-defined overflow,
> has made! (13! requires 33 bits unsigned to represent, or 34 bits
> signed.)
>
> So you don't magically avoid GIGO simply by avoiding signed overflow.
Did anyone say that? If so, I missed it.
> This is a programming issue pure and simple.
Absolutely. You need to know what you mean when you write a + b. For
unsigned types, you got exactly what you asked for.
> C could have been so much better.
Sure, but that's a truism -- it applies to every programming language,
especially the long-lived ones.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2017-12-28 11:29 -0500 |
| Subject | Re: UB in asm |
| Message-ID | <RZ81C.117373$4Z6.73624@fx41.iad> |
| In reply to | #124821 |
On 12/28/17 9:30 AM, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
>
>> On 28/12/2017 09:58, David Brown wrote:
>>> On 27/12/17 19:06, bartc wrote:
>>
>>> Your problem here is that you believe it is important to be able to
>>> predict the behaviour of incorrect and meaningless programs.
>>
>> Written in ASM for x86, the behaviour is completely predictable.
>
> ... and non-portable.
>
>> It seems that that is one program that it is impossible to port to C
>> and get the same predictable results with any C compiler.
>
> Don't be silly, you just have to write well-defined C. There are dozens
> of way to do that but the obvious one is to say what you want to happen
> when 'a' would overflow:
>
> #include <stdio.h>
> #include <stdint.h>
>
> int main(void)
> {
> int32_t a = INT32_MAX-5;
> for (int i = 1; i <= 10; ++i) {
> printf("%2d %+d",i, a);
> if (a == INT32_MIN)
> printf(" INT32_MIN");
> else if (a == INT32_MAX) {
This should be
if (a == INT32_MAX) {
(not else if) so the above case still does the increment.
> printf(" INT32_MAX");
> a = INT32_MIN;
> }
> else ++a;
> printf("\n");
> }
> }
>
>>> A compiler is a program. Garbage in, garbage out. A C compiler that
>>> gives consistent results for a program with integer overflow or other
>>> undefined behaviour is no "simpler", "smarter", or "more helpful" than
>>
>> Here are the first 20 factorials calculated with a C program using
>> signed int:
>
> No. This is the output from a program whose behaviour is not defined by
> C. In a some sense it is not a C program -- not a well-defined one at
> least.
>
>> It starts going wrong from 13! onwards. Here are the results when
>> using unsigned int:
>>
>> 0! = 1
>> 1! = 1
>> 2! = 2
>> 3! = 6
>> 4! = 24
>> 5! = 120
>> 6! = 720
>> 7! = 5040
>> 8! = 40320
>> 9! = 362880
>> 10! = 3628800
>> 11! = 39916800
>> 12! = 479001600
>> 13! = 1932053504
>> 14! = 1278945280
>> 15! = 2004310016
>> 16! = 2004189184
>> 17! = 4006445056
>> 18! = 3396534272
>> 19! = 109641728
>> 20! = 2192834560
>>
>> It's STILL going wrong from 13! onwards.
>
> I used to caution students against this sort of language. Own your
> mistakes! "It" is not suddenly "going wrong" -- you wrote the wrong
> program. The output is (probably) exactly as you requested.
This shows that we have a issue with our problem statement, namely that
20! can't be expressed with this sized integer. Likely the idea solution
would be to test before doing the multiply to see if it will overflow
and then print an early termination message.
>
>> Fat lot of difference using unsigned, with its well-defined overflow,
>> has made! (13! requires 33 bits unsigned to represent, or 34 bits
>> signed.)
>>
>> So you don't magically avoid GIGO simply by avoiding signed overflow.
>
> Did anyone say that? If so, I missed it.
>
>> This is a programming issue pure and simple.
>
> Absolutely. You need to know what you mean when you write a + b. For
> unsigned types, you got exactly what you asked for.
>
>> C could have been so much better.
>
> Sure, but that's a truism -- it applies to every programming language,
> especially the long-lived ones.
>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-28 17:46 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p2374t$bkp$1@dont-email.me> |
| In reply to | #124828 |
On 28/12/17 17:29, Richard Damon wrote:
> On 12/28/17 9:30 AM, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>>
>>> On 28/12/2017 09:58, David Brown wrote:
>>>> On 27/12/17 19:06, bartc wrote:
>>>
>>>> Your problem here is that you believe it is important to be able to
>>>> predict the behaviour of incorrect and meaningless programs.
>>>
>>> Written in ASM for x86, the behaviour is completely predictable.
>>
>> ... and non-portable.
>>
>>> It seems that that is one program that it is impossible to port to C
>>> and get the same predictable results with any C compiler.
>>
>> Don't be silly, you just have to write well-defined C. There are dozens
>> of way to do that but the obvious one is to say what you want to happen
>> when 'a' would overflow:
>>
>> #include <stdio.h>
>> #include <stdint.h>
>> int main(void)
>> {
>> int32_t a = INT32_MAX-5;
>> for (int i = 1; i <= 10; ++i) {
>> printf("%2d %+d",i, a);
>> if (a == INT32_MIN)
>> printf(" INT32_MIN");
>> else if (a == INT32_MAX) {
> This should be
> if (a == INT32_MAX) {
> (not else if) so the above case still does the increment.
>> printf(" INT32_MAX");
>> a = INT32_MIN;
>> }
>> else ++a;
Or it could be:
int main(void)
{
int32_t a = INT32_MAX-5;
for (int i = 1; i <= 10; ++i) {
printf("%2d %+d",i, a);
if (a == INT32_MIN) {
printf(" INT32_MIN");
a++;
} else if (a == INT32_MAX) {
printf(" INT32_MAX");
a = INT32_MIN;
} else {
a++:
}
printf("\n");
}
}
I am a great believer in using brackets to make it as hard as possible
to mistakes when reading or writing conditionals.
Keeping the structure of the original (such as Bart's preference for
last century's style of variable declarations), you could have:
int main(void)
{
int32_t a;
int i;
a = INT32_MAX - 5;
for (i = 1; i <= 10; i++) {
printf("%2d %+d", i, a);
if (a == INT32_MIN) printf(" INT32_MIN");
if (a == INT32_MAX) printf(" INT32_MAX");
printf("\n");
if (a == INT32_MAX) {
a = INT32_MIN; // Wrap on overflow
} else {
++a;
}
}
}
Or use:
a = (uint32_t) a + 1u;
for code that is simpler, and portable to all practical systems (that
support int32_t).
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2017-12-28 12:17 -0500 |
| Subject | Re: UB in asm |
| Message-ID | <WG91C.48011$d5.38808@fx14.iad> |
| In reply to | #124833 |
On 12/28/17 11:46 AM, David Brown wrote: > > Or use: > > a = (uint32_t) a + 1u; > > for code that is simpler, and portable to all practical systems (that > support int32_t). > The one problem with this is that the conversion of an unsigned number greater that INT_MAX to a signed integer still invokes undefined behavior, so an aggressively optimizing compiler might still assume that a can't equal INT_MIN.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-28 09:25 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <lnzi62datg.fsf@kst-u.example.com> |
| In reply to | #124841 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 12/28/17 11:46 AM, David Brown wrote:
>> Or use:
>>
>> a = (uint32_t) a + 1u;
>>
>> for code that is simpler, and portable to all practical systems (that
>> support int32_t).
>
> The one problem with this is that the conversion of an unsigned number
> greater that INT_MAX to a signed integer still invokes undefined
> behavior, so an aggressively optimizing compiler might still assume that
> a can't equal INT_MIN.
No, such a conversion yields an implementation-defined result (or raises
an implementation-defined signal).
Raising an implementation-defined signal could, I suppose, lead to
undefined behavior, but I don't know of any compiler that takes
advantage of that permission (added in C99 IIRC).
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web