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 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2017-12-29 15:46 +0800 |
| Subject | Re: UB in asm |
| Message-ID | <p24rt9$vn1$3@dont-email.me> |
| In reply to | #124859 |
AT Friday 29 December 2017 04:13, bartc wrote: > On 28/12/2017 19:44, David Brown wrote: >> On 28/12/17 18:04, bartc wrote: > > >> I don't want to have to go to all that trouble. > >> > > > > "All that trouble" ? You really are one impressive troll. > > Rewriting a code generator to pamper to a language (specifically, one > compiler) /is/ a lot of trouble. Especially when it renders the output > unreadable. Then you should have thought about this before starting it. -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-29 10:34 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p2527t$2u2$1@dont-email.me> |
| In reply to | #124859 |
On 28/12/17 21:13, bartc wrote:
> On 28/12/2017 19:44, David Brown wrote:
>> On 28/12/17 18:04, bartc wrote:
>
>>> I don't want to have to go to all that trouble.
>>>
>>
>> "All that trouble" ? You really are one impressive troll.
>
> Rewriting a code generator to pamper to a language (specifically, one
> compiler) /is/ a lot of trouble. Especially when it renders the output
> unreadable.
>
> I understand that to you, nothing is ever to much trouble. But we're not
> all whizzkids.
You are forever telling us how wonderful your compiler is, how
beautifully clear and simple its design, and how quickly you can modify
it for new features. And yet when asked to make a change that would let
it generate correct code, it is somehow an impossibly large undertaking?
And are you honestly telling me that adding the following snippet would
involve re-writing your code generator?
#ifdef __GNUC__
#pragma GCC optimize ("-fwrapv")
#pragma GCC optimize ("-fno-strict-aliasing")
#endif
You have snippet references to this simple fix twice. Clearly you are
not interested in generating correct code or making things easier for
yourself or your users (if there are any).
>
>> I also note that you snipped the suggestion of a few lines to force gcc
>> into -fwrapv -fno-strict-aliasing mode. Would that be too much trouble
>> too?
>
> Seriously, I don't understand gcc options; they're a minefield.
There are lots of options in gcc - it is a massive compiler suite. And
some of them are quite advanced. But they are all documented, in an
organised manner on reference pages that are easy to find.
More importantly, you don't even need to look up these options - I have
/told/ you want to use. You have repeatedly been told appropriate
options for appropriate circumstances (warning options, options for
conforming modes, optimisation options, and options for changing the C
dialect to one that suits your translator better).
>
> But I also want to generate C that is not dependent on any one compiler,
> and want to avoid adding things which are only specific to gcc. The
> question we should be asking is why is it always gcc that is the problem?
gcc is not the problem - your code is the problem. It just so happens
that gcc is the only compiler that you have used that optimises your
broken code in a way that you don't like. I expect clang will also have
the same effect, if you used that. And perhaps also MSVC, icc, Open64,
and many other compilers.
We have given you many clear ideas about how to fix your code - you
don't seem to get the point, and would rather moan about what you think
C should be, than face the reality of what C /is/. Apparently
generating correct C code is too much trouble for you - you'd rather
generate approximate code that works with toy tools.
So the obvious alternative is to have a way to make better compilers act
the way you want them - as good tools let the user influence how they
work. The snippet I gave you will work for gcc and - as a bonus - I
believe it will work for clang. If you want to make sure that your
generated code works with MSVC, then I am reasonably confident that
there are equivalent pragmas there - I just have no idea what they might
be, because I don't happen to use that compiler. I am sure that MSVC
options and pragmas are a minefield to you too, but I am equally sure
that someone could give you helpful advice here so you don't need to
read too much.
The snippet here does not make your code dependent on gcc - it merely
changes the semantics of the language gcc accepts to make it a better
match for your current almost-C generator.
>
>> You don't have to care what happens when there is undefined behaviour
>> in your code - you have to care that you don't rely on undefined
>> behaviour. There's a difference.
>
> What I want is that if I get an unexpected arithmetic overflow in my
> code, of whatever kind, then I get a wrong result in a calculation.
> That's all. And sometimes it will be expected.
Then you have picked the wrong language - C does not give you that.
>
> No other consequences to consider other than what my code will
> subsequently do with such wrong values. But that is entirely up to me
> and my program; I don't want to have to peruse a C language reference or
> a half a dozen compiler manuals for each of my C compilers to find out
> what /could/ happen.
You don't have to read /anything/ here, which is good - because /no/
source will tell you what happens when you have signed overflow. That
is what "undefined" means - you can't look up the definition anywhere.
>
> That doesn't preclude some tools from being able to trap such conditions
> for debugging purposes.
Indeed there are many such debugging tools.
>
>> No, the fuss starts when /you/ try to generate C code without knowing
>> what you are doing and what C code means.
>
> When I generate intermediate code, it's because I need a low-level,
> ubiquitous language that will let me represent my programs in a
> mainstream language, that can be used to bootstrap them on machine that
> lacks a compiler for my language, that can be compiled for a range of
> platforms I don't support, or that can make use of the more advanced
> code generators of some compilers.
Great - then if you want to use C, learn how C works. Stop pretending C
is a different language than it really is.
>
> I also need an intermediate language that doesn't get in the way and
> lets me do my job painlessly.
>
> Unfortunately such a language doesn't exist. The nearest that will fit
> the bill is C.
>
> But C comes with a whole bunch of problems that I don't want to have to
> deal with. I believe I may have mentioned one or two of them.
The problems you have with C are mostly in your mind.
However, you have decided that C is the nearest language available.
Fair enough - I think you are right there. But it does not have exactly
the same semantics as your own language in certain areas, such as signed
integer overflow.
You now have two options. You can choose to generate C code that gives
you the semantics you want, even though it might not have such a simple
direct correspondence with the source code. Or you can pretend that C
is something different, whine on a newsgroup about how nasty those
standards authors are and how compiler writers conspire against you
personally, and generate simple but incorrect C code.
It's your choice, but I know which one /I/ would pick in such circumstances.
>
>>> Both these promises are undermined when it is necessary to go via C
>>> source code.
>>>
>>
>> Only if you don't understand C - or rather, only if you refuse to
>> learn C.
>
> I understand all right. C is perfect.
So you don't understand. No one has said that.
> It should not be changed.
So you don't understand. The key point is not whether or not C /should/
change, but the simple fact that it is not /going/ to change. And even
if it /did/ change, that would be for a future C standard and future C
compilers - of no relevance to C programming /now/.
> Every
> decision that was ever taken, including refusing to recognised signed
> overflow, was absolutely the right one.
Far from every decision in the design of C was the right one, IMHO. And
I expect everyone with C experience will agree - while disagreeing about
exactly which design decisions were wrong.
And there were plenty of design decisions that were right at the time
they were made, but would be wrong for a new language designed now.
The undefined behaviour for signed overflow is, IMHO, a good decision.
It was a good decision at the time, and it is a good decision now -
although the reasons for it being good may have changed a bit over time.
> Everyone here will defend such
> decisions no matter what.
<https://www.youtube.com/watch?v=dtDUmD9MYNg>
(The Monty Python Witch Trial scene, for those that don't want to click
on the link. It is the same logic as Bart uses, but much funnier.)
>
> Except... if it was the other way around and C had defined signed
> overflow, and unsigned overflow was undefined, then everyone would be
> defending that instead!
Everyone would certainly be /using/ that - and like the actual rules of
C overflow, some would agree and some would disagree. But apart from
you and perhaps Supercat with his screwed ideas about what C used to be,
I don't expect people would be denying the reality of the situation.
>
> Has no one got any actual opinions of their own?
>
I recommend you /read/ the posts here. Then you will find plenty of
opinions.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-29 12:05 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <Bbq1C.132005$Jg1.19344@fx33.am4> |
| In reply to | #124885 |
On 29/12/2017 09:34, David Brown wrote:
> On 28/12/17 21:13, bartc wrote:
>> Rewriting a code generator to pamper to a language (specifically, one
>> compiler) /is/ a lot of trouble. Especially when it renders the output
>> unreadable.
> And are you honestly telling me that adding the following snippet would
> involve re-writing your code generator?
>
> #ifdef __GNUC__
> #pragma GCC optimize ("-fwrapv")
> #pragma GCC optimize ("-fno-strict-aliasing")
> #endif
>
> You have snippet references to this simple fix twice. Clearly you are
> not interested in generating correct code or making things easier for
> yourself or your users (if there are any).
Will this fix UB when using signed int overflow in gcc?
Will this fix UB when using signed int overflow in any other compiler?
(I tried -fwrapv and it game me a 4% speedup on one test using gcc. I
thought you said that making signed overflow be undefined gave more
opportunities to optimise? This seems to show the opposite.)
> I recommend you /read/ the posts here. Then you will find plenty of
> opinions.
Contrary to what the C standard says?
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-29 14:51 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p25h9g$vtp$1@dont-email.me> |
| In reply to | #124898 |
On 29/12/17 13:05, bartc wrote:
> On 29/12/2017 09:34, David Brown wrote:
>> On 28/12/17 21:13, bartc wrote:
>
>>> Rewriting a code generator to pamper to a language (specifically, one
>>> compiler) /is/ a lot of trouble. Especially when it renders the output
>>> unreadable.
>
>> And are you honestly telling me that adding the following snippet would
>> involve re-writing your code generator?
>>
>> #ifdef __GNUC__
>> #pragma GCC optimize ("-fwrapv")
>> #pragma GCC optimize ("-fno-strict-aliasing")
>> #endif
>>
>> You have snippet references to this simple fix twice. Clearly you are
>> not interested in generating correct code or making things easier for
>> yourself or your users (if there are any).
>
> Will this fix UB when using signed int overflow in gcc?
I assume you mean "will it make signed int overflow have defined
behaviour as two's complement wraparound" ? Yes, it will. "-fwrapv"
gives signed integers wrapping semantics on overflow.
(Since UB is a good thing IMHO, there is nothing to "fix".)
>
> Will this fix UB when using signed int overflow in any other compiler?
A quick test on godbolt shows it does not work on clang. clang does
support gcc's "-fwrapv" flag, but not that gcc pragma syntax. Other
compilers will not define __GNUC__, so are unaffected by this snippet -
you will have to figure out relevant pragmas or settings for them.
>
> (I tried -fwrapv and it game me a 4% speedup on one test using gcc. I
> thought you said that making signed overflow be undefined gave more
> opportunities to optimise? This seems to show the opposite.)
No, your single test case showed the opposite - and I am guessing that
was a test case for which wraparound was useful. You are taking a
single case and generalising from it - this seems to be a common flaw in
your thinking as you do it regularly. In many more cases, -fwrapv
removes optimisation opportunities. Often this is as the result of
other optimisations such as function inlining, inter-procedural
optimisations, and constant propagation - thus you won't see it so much
in very simple test functions.
But for a counter-example, consider this:
int test(int x) {
int y = 0;
for (int i = 0; i <= x; i++) {
y++;
}
return y;
}
With gcc -O2, the generated assembly is:
test:
lea eax, [rdi+1]
test edi, edi
mov edx, 0
cmovs eax, edx
ret
i.e., if x is less than 0, it returns 0. If not, it returns x + 1.
With gcc -O2 -fwrapv, you now get:
test:
xor eax, eax
test edi, edi
js .L4
.L3:
add eax, 1
cmp edi, eax
jge .L3
ret
.L4:
ret
There is a test for x less than 0 again. But otherwise it counts in a
loop - it cannot prove that loop can be simplified in the same way. In
particular, if x == INT_MAX, then the loop never exits. A smart enough
compiler /could/ treat the code as:
int test(int x) {
if (x < 0) return 0;
if (x == INT_MAX) {
while (true) { ; }
}
return x + 1;
}
gcc is not smart enough to do this. I guess there has been little
effort in optimisations that are only relevant when -fwrapv is active.
Here is a conundrum - C11 6.8.5p6 says that an iteration statement that
performs no I/O operations, no volatile accesses, and no atomic
operations, can be assumed to terminate - and an empty loop like this
can be removed. If the compiler were to do that, what should it return
in this case?
gcc - like many compilers - considers an unconditionally infinite loop
like this to be an intentional never ending loop, regardless of the
loop's content.
>
>> I recommend you /read/ the posts here. Then you will find plenty of
>> opinions.
>
> Contrary to what the C standard says?
>
Of course not (excluding posters that have not read, or do not
understand, the relevant parts of the standards). The contents of the C
standards are a matter of fact, not opinion.
You will find at least some people who think "it would have been better
if the standards made signed overflow implementation-dependent
behaviour" or "it would have been helpful if the standards said signed
overflow has two's complement wrapping when the implementation uses
two's complement signed integers". That is an opinion on the standard.
You will not find anyone who says "the standards say signed overflow is
implementation-dependent behaviour" or "the standards say signed
overflow has two's complement wrapping when the implementation uses
two's complement signed integers" - because the standards don't say
that. /That/ would be a statement contradicting the C standards.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-29 15:09 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <NUs1C.91706$q8.24489@fx07.am4> |
| In reply to | #124900 |
On 29/12/2017 13:51, David Brown wrote:
> On 29/12/17 13:05, bartc wrote:
>> (I tried -fwrapv and it game me a 4% speedup on one test using gcc. I
>> thought you said that making signed overflow be undefined gave more
>> opportunities to optimise? This seems to show the opposite.)
>
> No, your single test case showed the opposite - and I am guessing that
> was a test case for which wraparound was useful. You are taking a
> single case and generalising from it - this seems to be a common flaw in
> your thinking as you do it regularly. In many more cases, -fwrapv
> removes optimisation opportunities. Often this is as the result of
> other optimisations such as function inlining, inter-procedural
> optimisations, and constant propagation - thus you won't see it so much
> in very simple test functions.
It was an 18Kloc program
(https://github.com/bartg/langs/blob/master/pcc64.c).
However, I get different results when the code is in one monolithic
file, compared with having it in 20 separate modules. Summary is:
Monolithic: 3.19 seconds without -ftrapv
3.26 with -ftrapv
Multi-module: 3.59 without -ftrapv
3.43 with -ftrapv
The monolithic version is faster anyway (for this test).
--------------------------------------------------
(To run the test yourself, compile the above program with -m64 to an
executable 'pcc'. Download this binary byte-code program:
https://github.com/bartg/langs/blob/master/jpeg.pc
(Slightly different program from the Windows-specific original which
displayed the results graphically. This one is OS-neutral.)
Run using:
pcc jpeg file.jpg
It will convert file.jpg to file.ppm. The specific input I used was:
https://github.com/bartg/langs/blob/master/card2.jpg
(a 2Mpixel test card). I can't however supply the multi-module version
as it's too much work.
For interest, compiling the original non-C source of pcc (on multiple
modules) with my own compiler gives a time of 5.1 seconds. Accelerated
however (using a .asm module not available in the C version) it's 1.4
seconds.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-29 09:05 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <lna7y1cvn2.fsf@kst-u.example.com> |
| In reply to | #124900 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> int test(int x) {
> if (x < 0) return 0;
> if (x == INT_MAX) {
> while (true) { ; }
> }
> return x + 1;
> }
>
> gcc is not smart enough to do this. I guess there has been little
> effort in optimisations that are only relevant when -fwrapv is active.
>
> Here is a conundrum - C11 6.8.5p6 says that an iteration statement that
> performs no I/O operations, no volatile accesses, and no atomic
> operations, can be assumed to terminate - and an empty loop like this
> can be removed. If the compiler were to do that, what should it return
> in this case?
6.8.5p6 doesn't apply in this case. It applies only to an iteration
statement whose controlling expression is not a constant expression.
Here's the full text:
An iteration statement whose controlling expression is not a constant
expression, that performs no input/output operations, does not access
volatile objects, and performs no synchronization or atomic operations
in its body, controlling expression, or (in the case of a for statement)
its expression-3, may be assumed by the implementation to terminate.
with two footnotes:
An omitted controlling expression is replaced by a nonzero constant,
which is a constant expression.
and
This is intended to allow compiler transformations such as removal
of empty loops even when termination cannot be proven.
If you write an explicit infinite loop using something like while (1) or
for (;;), it will be treated as an infinite loop.
In my opinion (I've mentioned this before), this paragraph is badly
worded. It says that such a loop "may be assumed" to terminate. It
should, IMHO, be expressed in terms of the permitted behavior of the
program.
--
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 | 2017-12-29 13:35 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <41c6745a-2f15-46a0-b834-9b7ffb957fc9@googlegroups.com> |
| In reply to | #124906 |
On Friday, December 29, 2017 at 11:05:50 AM UTC-6, Keith Thompson wrote:
> Here's the full text:
>
> An iteration statement whose controlling expression is not a constant
> expression, that performs no input/output operations, does not access
> volatile objects, and performs no synchronization or atomic operations
> in its body, controlling expression, or (in the case of a for statement)
> its expression-3, may be assumed by the implementation to terminate.
>
> with two footnotes:
>
> An omitted controlling expression is replaced by a nonzero constant,
> which is a constant expression.
>
> and
>
> This is intended to allow compiler transformations such as removal
> of empty loops even when termination cannot be proven.
>
> If you write an explicit infinite loop using something like while (1) or
> for (;;), it will be treated as an infinite loop.
>
> In my opinion (I've mentioned this before), this paragraph is badly
> worded. It says that such a loop "may be assumed" to terminate. It
> should, IMHO, be expressed in terms of the permitted behavior of the
> program.
It is badly worded. In the real world, an invitation to "assume X" is an
indication that the person offering the invitation is willing to take
responsibility for the consequences of actions which would be reasonable
if X were true, if X is false and that *causes* the actions to have
undesirable consequences. It does not imply that if X isn't true, the
recipient of the invitation would be entitled to do anything and
everything whatsoever.
I think it would have been better to say:
1. that evaluation of a loop's terminating condition need not be
regarded as a sequencing barrier to code which follows the loop
but does not have any data dependencies upon objects that are
changed within the loop.
2. for purposes of this rule, the result of an operator has a data
dependency upon any evaluated operands, even in cases where all
possible values for one operand would yield the same value for
the other.
Upholding the latter requirement may require that a compiler's intermediate
code support the concept of "observe a value purely for purposes of
sequencing, but don't otherwise force its actual computation", but that
shouldn't be too bad.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-12-29 15:38 -0600 |
| Subject | Re: UB in asm |
| Message-ID | <6dcd4ddjvhp9f7mcandpl0ss14tp1r2rje@4ax.com> |
| In reply to | #124906 |
On Fri, 29 Dec 2017 09:05:21 -0800, Keith Thompson <kst-u@mib.org>
wrote:
>David Brown <david.brown@hesbynett.no> writes:
>[...]
>> int test(int x) {
>> if (x < 0) return 0;
>> if (x == INT_MAX) {
>> while (true) { ; }
>> }
>> return x + 1;
>> }
>>
>> gcc is not smart enough to do this. I guess there has been little
>> effort in optimisations that are only relevant when -fwrapv is active.
>>
>> Here is a conundrum - C11 6.8.5p6 says that an iteration statement that
>> performs no I/O operations, no volatile accesses, and no atomic
>> operations, can be assumed to terminate - and an empty loop like this
>> can be removed. If the compiler were to do that, what should it return
>> in this case?
>
>6.8.5p6 doesn't apply in this case. It applies only to an iteration
>statement whose controlling expression is not a constant expression.
>
>Here's the full text:
>
> An iteration statement whose controlling expression is not a constant
> expression, that performs no input/output operations, does not access
> volatile objects, and performs no synchronization or atomic operations
> in its body, controlling expression, or (in the case of a for statement)
> its expression-3, may be assumed by the implementation to terminate.
>
>with two footnotes:
>
> An omitted controlling expression is replaced by a nonzero constant,
> which is a constant expression.
>
>and
>
> This is intended to allow compiler transformations such as removal
> of empty loops even when termination cannot be proven.
>
>If you write an explicit infinite loop using something like while (1) or
>for (;;), it will be treated as an infinite loop.
>
>In my opinion (I've mentioned this before), this paragraph is badly
>worded. It says that such a loop "may be assumed" to terminate. It
>should, IMHO, be expressed in terms of the permitted behavior of the
>program.
I'm a bit puzzled over what the effect of a non-empty loop like that
would be. Consider:
int x, y;
void f(int something)
{
x=1;
y=7;
while (something > 7)
{
x=2;
y++;
}
}
The paragraph in question appears to allow the assumption that the
loop terminates, does the function exit with x being 1 or 2? Depending
on the value of the parameter? And what about the value of y?
A semi-reasonable case could be made for x being set to 1 or 2 based
on the parameter's relationship to 7 (a straight-forward hoisting of
the (conditional) assignment out of the loop would be perfectly
reasonable, and have the same result), but not for y.
I'm also having a hard time seeing in what cases this helps with an
optimization, other than in a case of a completely empty loop
(possibly after hoisting an assignment like the one out of the loop).
The conditions specified seem rather too loose, something along the
lines of allowing it on a loop where more than one iteration has no
different an effect than a single iteration would seem to make more
sense.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-29 14:15 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <bb065b5e-39b4-4152-aa06-a08f1fb8301c@googlegroups.com> |
| In reply to | #124919 |
On Friday, December 29, 2017 at 3:38:37 PM UTC-6, robert...@yahoo.com wrote:
> On Fri, 29 Dec 2017 09:05:21 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
> >Here's the full text:
> >
> > An iteration statement whose controlling expression is not a constant
> > expression, that performs no input/output operations, does not access
> > volatile objects, and performs no synchronization or atomic operations
> > in its body, controlling expression, or (in the case of a for statement)
> > its expression-3, may be assumed by the implementation to terminate.
> >
> >with two footnotes:
> >
> > An omitted controlling expression is replaced by a nonzero constant,
> > which is a constant expression.
> >
> >and
> >
> > This is intended to allow compiler transformations such as removal
> > of empty loops even when termination cannot be proven.
> >
> I'm a bit puzzled over what the effect of a non-empty loop like that
> would be. Consider:
>
> int x, y;
>
> void f(int something)
> {
> x=1;
> y=7;
> while (something > 7)
> {
> x=2;
> y++;
> }
> }
>
>
> The paragraph in question appears to allow the assumption that the
> loop terminates, does the function exit with x being 1 or 2? Depending
> on the value of the parameter? And what about the value of y?
>
> A semi-reasonable case could be made for x being set to 1 or 2 based
> on the parameter's relationship to 7 (a straight-forward hoisting of
> the (conditional) assignment out of the loop would be perfectly
> reasonable, and have the same result), but not for y.
If y were changed to an unsigned type (no reason to add integer overflow
issues to the mix), I would suggest that any code which would try to
observe the value of y should not be allowed to execute if something was/is
greater than 7. The purpose of the rule is, from what I can tell, to
allow compilers to run code which **should be independent of anything that
happens within a loop** to be run either before it, after it, or in
parallel with it, at the compiler's discretion. If the rule were better
written, it would say that the loop's terminating condition should not,
*in and of itself*, imply a causal dependency between code within the
loop and code that follows. I don't think the rule was intended to waive
any other causal relationships, nor to imply that a compiler given:
void foo(long long x)
{
do {
x = long_slow_function_no_side_effects(x); }
while( x != 43);
printf("The result was ");
printf("%lld\n", x);
}
should simply output 'The result was 43' (since the loop couldn't exit if
x weren't 43). The first printf does not make any use of anything that
is computed within the loop, so starting it before the computation may
be helpful. The second, however, shouldn't output anything unless it is
*actually* reachable with x==43.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2017-12-29 18:07 -0500 |
| Subject | Re: UB in asm |
| Message-ID | <fVz1C.24977$Y21.9223@fx08.iad> |
| In reply to | #124919 |
On 12/29/17 4:38 PM, Robert Wessel wrote:
> On Fri, 29 Dec 2017 09:05:21 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
>
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> int test(int x) {
>>> if (x < 0) return 0;
>>> if (x == INT_MAX) {
>>> while (true) { ; }
>>> }
>>> return x + 1;
>>> }
>>>
>>> gcc is not smart enough to do this. I guess there has been little
>>> effort in optimisations that are only relevant when -fwrapv is active.
>>>
>>> Here is a conundrum - C11 6.8.5p6 says that an iteration statement that
>>> performs no I/O operations, no volatile accesses, and no atomic
>>> operations, can be assumed to terminate - and an empty loop like this
>>> can be removed. If the compiler were to do that, what should it return
>>> in this case?
>>
>> 6.8.5p6 doesn't apply in this case. It applies only to an iteration
>> statement whose controlling expression is not a constant expression.
>>
>> Here's the full text:
>>
>> An iteration statement whose controlling expression is not a constant
>> expression, that performs no input/output operations, does not access
>> volatile objects, and performs no synchronization or atomic operations
>> in its body, controlling expression, or (in the case of a for statement)
>> its expression-3, may be assumed by the implementation to terminate.
>>
>> with two footnotes:
>>
>> An omitted controlling expression is replaced by a nonzero constant,
>> which is a constant expression.
>>
>> and
>>
>> This is intended to allow compiler transformations such as removal
>> of empty loops even when termination cannot be proven.
>>
>> If you write an explicit infinite loop using something like while (1) or
>> for (;;), it will be treated as an infinite loop.
>>
>> In my opinion (I've mentioned this before), this paragraph is badly
>> worded. It says that such a loop "may be assumed" to terminate. It
>> should, IMHO, be expressed in terms of the permitted behavior of the
>> program.
>
>
> I'm a bit puzzled over what the effect of a non-empty loop like that
> would be. Consider:
>
> int x, y;
>
> void f(int something)
> {
> x=1;
> y=7;
> while (something > 7)
> {
> x=2;
> y++;
> }
> }
>
>
> The paragraph in question appears to allow the assumption that the
> loop terminates, does the function exit with x being 1 or 2? Depending
> on the value of the parameter? And what about the value of y?
>
> A semi-reasonable case could be made for x being set to 1 or 2 based
> on the parameter's relationship to 7 (a straight-forward hoisting of
> the (conditional) assignment out of the loop would be perfectly
> reasonable, and have the same result), but not for y.
>
> I'm also having a hard time seeing in what cases this helps with an
> optimization, other than in a case of a completely empty loop
> (possibly after hoisting an assignment like the one out of the loop).
>
> The conditions specified seem rather too loose, something along the
> lines of allowing it on a loop where more than one iteration has no
> different an effect than a single iteration would seem to make more
> sense.
>
If the loop has observable effects, then the clause still requires all
those observable effect to happen. For the above loop, x would only need
to be set to 2 once ((if something > 7), but even with the assumption
that the loop terminates, that by itself doesn't define what value y
would have.
If the implementation could determine that no observable behavior after
the call to something depends on the value of y, then it could just have
f return after possibly setting x based on something. By myy
understanding, if any observable behavior depended on the value of y,
that behavior could not occur if something was > 7.
The primary use of that clause is the removal of loops that have no
effect on the rest of the program, and no directly observable effects.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-30 13:12 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p27vqq$ofs$1@dont-email.me> |
| In reply to | #124906 |
On 29/12/17 18:05, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> int test(int x) {
>> if (x < 0) return 0;
>> if (x == INT_MAX) {
>> while (true) { ; }
>> }
>> return x + 1;
>> }
>>
>> gcc is not smart enough to do this. I guess there has been little
>> effort in optimisations that are only relevant when -fwrapv is active.
>>
>> Here is a conundrum - C11 6.8.5p6 says that an iteration statement that
>> performs no I/O operations, no volatile accesses, and no atomic
>> operations, can be assumed to terminate - and an empty loop like this
>> can be removed. If the compiler were to do that, what should it return
>> in this case?
>
> 6.8.5p6 doesn't apply in this case. It applies only to an iteration
> statement whose controlling expression is not a constant expression.
>
Good point. Thanks.
> Here's the full text:
>
> An iteration statement whose controlling expression is not a constant
> expression, that performs no input/output operations, does not access
> volatile objects, and performs no synchronization or atomic operations
> in its body, controlling expression, or (in the case of a for statement)
> its expression-3, may be assumed by the implementation to terminate.
>
> with two footnotes:
>
> An omitted controlling expression is replaced by a nonzero constant,
> which is a constant expression.
>
> and
>
> This is intended to allow compiler transformations such as removal
> of empty loops even when termination cannot be proven.
>
> If you write an explicit infinite loop using something like while (1) or
> for (;;), it will be treated as an infinite loop.
>
> In my opinion (I've mentioned this before), this paragraph is badly
> worded. It says that such a loop "may be assumed" to terminate. It
> should, IMHO, be expressed in terms of the permitted behavior of the
> program.
>
I am not sure how it should be worded - but it has always struck me as a
slightly odd and out-of-place rule.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-12-30 05:19 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <f00e21b2-8987-43fd-9e72-988a2e50e2d0@googlegroups.com> |
| In reply to | #124959 |
On Saturday, December 30, 2017 at 12:12:26 PM UTC, David Brown wrote:
> On 29/12/17 18:05, Keith Thompson wrote:
>
> > In my opinion (I've mentioned this before), this paragraph is badly
> > worded. It says that such a loop "may be assumed" to terminate. It
> > should, IMHO, be expressed in terms of the permitted behavior of the
> > program.
> >
>
> I am not sure how it should be worded - but it has always struck me as a
> slightly odd and out-of-place rule.
>
we've got this
int x = 4;
while( ! isprime(x) )
{
x += 2;
if(x > 10000)
x = 4;
}
printf("loop ended\n");
Now in fact this loop will never terminate. But it's too hard for the
compiler to determine that, because to do if for the general case
it needs to solve the halting problem.
The compiler is therefore allowed to optimise to
printf("loop ended\n");
That's incorrect, it's the opposite of what the programmer probably wants,
but it's a necessary rule to enable aggressive optimisations without
actually emulating loop logic to see if it terminates.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2017-12-30 09:33 -0500 |
| Subject | Re: UB in asm |
| Message-ID | <jtN1C.36615$la6.30655@fx24.iad> |
| In reply to | #124963 |
On 12/30/17 8:19 AM, Malcolm McLean wrote:
> On Saturday, December 30, 2017 at 12:12:26 PM UTC, David Brown wrote:
>> On 29/12/17 18:05, Keith Thompson wrote:
>>
>>> In my opinion (I've mentioned this before), this paragraph is badly
>>> worded. It says that such a loop "may be assumed" to terminate. It
>>> should, IMHO, be expressed in terms of the permitted behavior of the
>>> program.
>>>
>>
>> I am not sure how it should be worded - but it has always struck me as a
>> slightly odd and out-of-place rule.
>>
> we've got this
>
> int x = 4;
> while( ! isprime(x) )
> {
> x += 2;
> if(x > 10000)
> x = 4;
> }
> printf("loop ended\n");
>
> Now in fact this loop will never terminate. But it's too hard for the
> compiler to determine that, because to do if for the general case
> it needs to solve the halting problem.
>
> The compiler is therefore allowed to optimise to
>
> printf("loop ended\n");
>
> That's incorrect, it's the opposite of what the programmer probably wants,
> but it's a necessary rule to enable aggressive optimisations without
> actually emulating loop logic to see if it terminates.
>
But only if the implementation can proof to itself that isprime(x)
creates no observable behavior, this is easiest if it can see the
definition of isprime(x) in the translation unit.
[toc] | [prev] | [next] | [standalone]
| From | supercat <flatfinger@casperkitty.com> |
|---|---|
| Date | 2017-12-30 09:50 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <8157e16c-5023-4ace-98db-70c62b7505aa@googlegroups.com> |
| In reply to | #124963 |
On Saturday, December 30, 2017 at 7:20:06 AM UTC-6, Malcolm McLean wrote:
> That's incorrect, it's the opposite of what the programmer probably wants,
> but it's a necessary rule to enable aggressive optimisations without
> actually emulating loop logic to see if it terminates.
Actually, I don't think it's even necessary that the loop logic be opaque.
Consider the code:
#include <math.h>
double test(uint32_t a, uint32_t b, uint32_t *p)
{
double sum;
for (uint32_t i=1; i<=a; i++)
sum+=sin(i);
for (uint32_t j=1; j<=b; j++)
*p++ = j;
return sum;
}
A compiler could easily identify the cases where the first loop would or
would not terminate, but that would require testing whether a is equal
to 0xFFFFFFFF--a test which wouldn't offer any benefit in meaningful cases.
If in fact the first loop does terminate, performance might be improved
by running it in parallel with the second (especially since the first is
FPU dominant and the second is memory-dominant. That would alter program
behavior, however, if a equals 0xFFFFFFFF and dp is an invalid pointer.
Should a compiler be required to confirm that 'a' is not equal to 0xFFFFFFFF
before it performs any writes via *p?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-30 21:47 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p28u1q$j8e$1@dont-email.me> |
| In reply to | #124963 |
On 30/12/17 14:19, Malcolm McLean wrote:
> On Saturday, December 30, 2017 at 12:12:26 PM UTC, David Brown wrote:
>> On 29/12/17 18:05, Keith Thompson wrote:
>>
>>> In my opinion (I've mentioned this before), this paragraph is badly
>>> worded. It says that such a loop "may be assumed" to terminate. It
>>> should, IMHO, be expressed in terms of the permitted behavior of the
>>> program.
>>>
>>
>> I am not sure how it should be worded - but it has always struck me as a
>> slightly odd and out-of-place rule.
>>
> we've got this
>
> int x = 4;
> while( ! isprime(x) )
> {
> x += 2;
> if(x > 10000)
> x = 4;
> }
> printf("loop ended\n");
>
> Now in fact this loop will never terminate. But it's too hard for the
> compiler to determine that, because to do if for the general case
> it needs to solve the halting problem.
>
> The compiler is therefore allowed to optimise to
>
> printf("loop ended\n");
No, the compiler can't do that optimisation unless it knows the
definition of "isprime" and knows it has no side-effects. It can only
optimise the loop away if it can see that "isprime" has no extra
effects, and that it will always return false for all x from 4 upwards
in steps of 2 until INT_MAX (after which it does not matter), but that
it is not a constant expression. Then it could reasonably remove the loop.
I don't expect such transformations to be practical in any real compiler.
>
> That's incorrect, it's the opposite of what the programmer probably wants,
> but it's a necessary rule to enable aggressive optimisations without
> actually emulating loop logic to see if it terminates.
>
The point of the rule is that an unending loop that does not actually do
anything is meaningless code, except for something that is clearly
written as a "wait forever" loop (i.e., with a constant controlling
expression). No one can guess what the programmer "probably wants" -
what he wrote is nonsensical.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-30 13:26 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <a136f2e8-6c97-4410-b9cf-2feaf33ddd02@googlegroups.com> |
| In reply to | #124977 |
On Saturday, December 30, 2017 at 2:48:05 PM UTC-6, David Brown wrote:
> No, the compiler can't do that optimisation unless it knows the
> definition of "isprime" and knows it has no side-effects. It can only
> optimise the loop away if it can see that "isprime" has no extra
> effects, and that it will always return false for all x from 4 upwards
> in steps of 2 until INT_MAX (after which it does not matter), but that
> it is not a constant expression. Then it could reasonably remove the loop.
>
> I don't expect such transformations to be practical in any real compiler.
How about:
double test(uint32_t delta, uint32_t *p, uint32_t n)
{
double d = 0.0;
uint32_t i=0xC0000000;
do
{
d *= 0.9999999999;
d += 1.0/i;
i+=delta;
} while(i);
for (uint32_t i=0; i<n; i++)
p[i] = i;
return d;
}
Under C99, behavior of test(0x80000000, 0, 100); would have been defined
as sitting forever in the first "for" loop, since code would not be able
to write to *p unless or until that loop completed. On the other hand,
performance on some systems be improved by running the two loops in
parallel; doing so would only affect behavior in the unlikely event that
the first loop ran forever and the second would invoke critical UB if
executed.
Note that in the above code it would not be hard to determine what values
of "delta" would result in the loop running endlessly (0 or 0x80000000).
What's unclear is whether it would actually be beneficial to have a compiler
allow for the possibility that the function might be invoked with one of
those values along with an invalid pointer for "b". In some application
fields, it probably would, but it's not clear that there aren't some fields
where it would be more useful to let compilers skip the check.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-12-30 13:53 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <52889069-28aa-497e-aded-9aa0bf2aa3e8@googlegroups.com> |
| In reply to | #124977 |
On Saturday, December 30, 2017 at 8:48:05 PM UTC, David Brown wrote:
> On 30/12/17 14:19, Malcolm McLean wrote:
> > On Saturday, December 30, 2017 at 12:12:26 PM UTC, David Brown wrote:
> >> On 29/12/17 18:05, Keith Thompson wrote:
> >>
> >>> In my opinion (I've mentioned this before), this paragraph is badly
> >>> worded. It says that such a loop "may be assumed" to terminate. It
> >>> should, IMHO, be expressed in terms of the permitted behavior of the
> >>> program.
> >>>
> >>
> >> I am not sure how it should be worded - but it has always struck me as a
> >> slightly odd and out-of-place rule.
> >>
> > we've got this
> >
> > int x = 4;
> > while( ! isprime(x) )
> > {
> > x += 2;
> > if(x > 10000)
> > x = 4;
> > }
> > printf("loop ended\n");
> >
> > Now in fact this loop will never terminate. But it's too hard for the
> > compiler to determine that, because to do if for the general case
> > it needs to solve the halting problem.
> >
> > The compiler is therefore allowed to optimise to
> >
> > printf("loop ended\n");
>
>
> No, the compiler can't do that optimisation unless it knows the
> definition of "isprime" and knows it has no side-effects. It can only
> optimise the loop away if it can see that "isprime" has no extra
> effects, and that it will always return false for all x from 4 upwards
> in steps of 2 until INT_MAX (after which it does not matter), but that
> it is not a constant expression. Then it could reasonably remove the
> loop.
>
> I don't expect such transformations to be practical in any real compiler.
>
Maybe I should have provided isprime(). Of course it's intended as a
pure function.
Since x isn't used, the loop does nothing, and can be optimised
away to nothing. Or the printf() could be moved to before loop entry
because there are no intervening IO statements.
You don't need a sophisticated analysis to make those optimisations,
thanks to the halting problem ignored rule.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-30 14:19 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <8faf98f4-dd0b-48ec-8995-1e0dd38eafc1@googlegroups.com> |
| In reply to | #124980 |
On Saturday, December 30, 2017 at 3:53:32 PM UTC-6, Malcolm McLean wrote: > You don't need a sophisticated analysis to make those optimisations, > thanks to the halting problem ignored rule. Do you agree with my assessment that the rule as written is needlessly broad (versus simply saying that the presence of code within a loop that cannot be shown to terminate does not imply, *in and of itself*, that it must be sequenced before what follows? If one writes a program to search until it finds a solution to a problem or it is manually killed, it would be less than helpful to have a compiler infer that since a loop can't terminate unless x==23, it may therefore be presumed to terminate with x==23 (regardless of whether there's actually any way by which x could be set to 23). While a programmer could add a dummy write of an otherwise unused volatile variable to prevent a compiler from performing such optimizations, allowing a compiler run multiple pieces of code in parallel when there are no dependencies between them is useful. Requiring that programmers add meaningless volatile accesses to block such optimizations would undermine the whole purpose of allowing them in the first place.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2017-12-30 19:13 -0500 |
| Subject | Re: UB in asm |
| Message-ID | <TYV1C.29260$RV5.4553@fx11.iad> |
| In reply to | #124982 |
On 12/30/17 5:19 PM, supercat@casperkitty.com wrote: > On Saturday, December 30, 2017 at 3:53:32 PM UTC-6, Malcolm McLean wrote: >> You don't need a sophisticated analysis to make those optimisations, >> thanks to the halting problem ignored rule. > > Do you agree with my assessment that the rule as written is needlessly > broad (versus simply saying that the presence of code within a loop > that cannot be shown to terminate does not imply, *in and of itself*, that > it must be sequenced before what follows? > > If one writes a program to search until it finds a solution to a problem > or it is manually killed, it would be less than helpful to have a compiler > infer that since a loop can't terminate unless x==23, it may therefore be > presumed to terminate with x==23 (regardless of whether there's actually > any way by which x could be set to 23). While a programmer could add a > dummy write of an otherwise unused volatile variable to prevent a compiler > from performing such optimizations, allowing a compiler run multiple pieces > of code in parallel when there are no dependencies between them is useful. > Requiring that programmers add meaningless volatile accesses to block such > optimizations would undermine the whole purpose of allowing them in the > first place. > As long as the loop generates something that affects observable behavior, there are practical limits to what the compiler can do with the assumption that all loops with variable conditions will terminate. Presumably, if you are searching for a solution, you are going to do something with that solution, and using that solution will require the loop to actually be run. Yes, just printing something like "I found it" would be allowed to be optimized earlier, assuming the loop had no directly observable behavior, but if the line include some part of the answer being searched for, it couldn't be (unless the compiler was smart enough to figure out that part of your solution).
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2017-12-29 15:42 +0800 |
| Subject | Re: UB in asm |
| Message-ID | <p24rln$vn1$1@dont-email.me> |
| In reply to | #124837 |
AT Friday 29 December 2017 01:04, bartc wrote: > On 28/12/2017 16:11, David Brown wrote: >> On 28/12/17 15:57, bartc wrote: > >> 2. It /does/ /not/ /matter/ what the generated C code looks like. You >> can quite happily translate your "++a" into "INC_INT(a)" and have a >> macro for it. Or you can translate it inline to "a = (uint32_t) a + 1". >> Or whatever. It does not matter in the slightest. The need for >> "pretty" generated C code is all in your head. > > I don't want to have to go to all that trouble. > > If using C source as the target of a compiler turns out to be harder and > more fiddly than using ASM, then there is something wrong. Did it ever come to your mind that if it is so "fiddly" for you and not others, there might be a reason for this? Other organize their code in a way, that overflows do not happen. They regard this as an error. If you are not able to write error free (in the above sense) code you should better keep your fingers off the keyboard. >> You live in your own bizarre little world of fear and hatred of a >> programming language, with your own personal ideas of what it should be >> and how it should be used. How can you be so blinkered? > > My posts in the subthread started after reading this: > > James Kuyper: > > A key point to consider is that the behavior of a+b is undefined if it > > results in overflow. That means that the C standard imposes no > > requirements on the behavior of your program. Among an infinite number > > of other possibilities: > > Followed by a complicated list of the said possibilities that I'm not > interested in having to keep in mind. > > How about this possibility: > > 0. Just do the a+b addition even if it overflows. > > That's a lot easier to remember, and will not affect well-written code > that will not have overflow. > > I suggest a poll at this point to see who would be in favour of James' > possibilities 1. to 5., and who would prefer my possibility 0. > >> Most people probably don't care, because overflow is rare >> in the real world - they don't give a *beep* what happens when >> incrementing a value beyond 2 billion because their code does not do >> that. > > I don't usually care about it either. But in C I /have/ to care about it > because apparently anything like this in a program is the equivalent of > red Kryptonite to Superman - anything could happen including a lot of > weird stuff. > > (In my byte-code interpreter, overflows of 64-bit integer arithmetic are > not checked. Possibilities included reporting as an error (possibly > trapped via an exception mechanism), or to represent the result as a > big-integer value. > > I chose not to check because it is simpler, more efficient, and more > predictable (if I wanted to type-infer the result of A+B for example, if > I already knew the types of A and B). > > Also, because sometimes the interpreter code has to be represented as C > source, that doesn't make it easy or efficient to do overflow checking. > That any 64-bit signed int operation - on operands which come from the > user-program being executed so I've no idea what they are - could result > in UB in the C code is an extra headache. Or an extra bonus according to > most opinions here.) > >> Other than that, I can't make any serious judgement from a snippet like >> that. > > I'm not asking for judgement. It's just very ordinary, workmanlike code > to get stuff done without any fuss. > > The fuss starts however when it goes through C. > >> It is just code in a structured, statically typed procedural >> language. The syntax details are not particularly exciting here - it >> does not stand out from a dozen or more existing languages. > > The key thing is that the language doesn't say that signed int overflow > results in undefined behaviour. Another thing about it is that > implementations will usually do what the code says. > > Both these promises are undermined when it is necessary to go via C > source code. > -- Reinhardt
[toc] | [prev] | [next] | [standalone]
Page 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web