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 12 of 13 — ← Prev page 1 … 10 11 [12] 13 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-27 17:51 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <87shbwcb4s.fsf@bsb.me.uk> |
| In reply to | #124745 |
bartc <bc@freeuk.com> writes: > On 27/12/2017 14:49, jameskuyper@verizon.net wrote: >> Nope - C has NEVER been that language. You should use an assembler if you wish >> to have that much control over the generated code. > > Someone wants to be simply be able to write A+B instead of using ASM > instructions, and you're telling me there is no such language? I don't know of one but that does not mean it does not exist. How would it work? Would you want the types of A and B to determine which add instruction to use? Using what rules? > I'm pretty sure C didn't start off like that. Did you mean to say that you think C /did/ start off like that -- as a way to get an ADD instruction of some sort when writing A+B? If you did mean that, then what is your evidence? I don't really think that is what you mean, but I can't work out what you might have wanted to say. Obviously C did not start out like it is now. > At what point did it become so impossible? How you imagine people manage? The problem has alwars been that is not what you want it to be but there is nothing better that you know of so you feel motivated to complain about it a lot. > Fortunately however, other C compilers exist which aren't quite as > overbearing. For now. Do they guarantee never to introduce optimisations that you won't like? If not, you are writing code that might break with no warning at some time in the future. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-27 18:34 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <vIR0C.135657$6P.94830@fx13.am4> |
| In reply to | #124765 |
On 27/12/2017 17:51, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: > >> On 27/12/2017 14:49, jameskuyper@verizon.net wrote: > >>> Nope - C has NEVER been that language. You should use an assembler if you wish >>> to have that much control over the generated code. >> >> Someone wants to be simply be able to write A+B instead of using ASM >> instructions, and you're telling me there is no such language? > > I don't know of one but that does not mean it does not exist. How would > it work? Would you want the types of A and B to determine which add > instruction to use? Using what rules? I've written actual compilers for five targets (PDP10, Z80, three generations of x86). (And developed some on paper for others but I never got around to using the hardware. But they would have worked the same way.) In all cases, you write A+B in the language rather than having to write the sequence of machine instructions that would do the same job. (They will vary according to type and width.) Overflow for integer arithmetic was never considered. Whatever bit pattern the machine ended up with, that's what you got. If overflow shouldn't have happened, then you detect this during normal testing, and made adjustments (use a wider type, different logic, report bad input etc). You don't want a language using it as an excuse to do weird stuff. And in fact, most C compilers I can test today will do exactly the same: Pelles C, lccwin, DMC, Tiny C, Mcc. As will gcc using -O0. (MVSC and clang I can't test.) It is the simplest and most obvious thing to do. No one needs to learn about UB unless it really is UB (eg. access past end of an array), and then it will be obvious without the language having to spell it out. > >> I'm pretty sure C didn't start off like that. > > Did you mean to say that you think C /did/ start off like that -- as a > way to get an ADD instruction of some sort when writing A+B? If you did > mean that, then what is your evidence? Are you suggesting one of their primary aims in creating the language was to incorporate UB as much as possible rather than to just make it easier to write an OS than using assembly? Since none of us really know, which is most probable? >> At what point did it become so impossible? > > How you imagine people manage? The problem has alwars been that is not > what you want it to be but there is nothing better that you know of so > you feel motivated to complain about it a lot. I gave an example of a program where every compiler gave the result that anyone would expect. Except gcc using -O3, and even then only if the initialisation was visible. gcc is giving weird results, yet everyone is standing up for gcc and for the language and for ub, as though that result was desirable. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-27 21:14 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <87608rdgao.fsf@bsb.me.uk> |
| In reply to | #124770 |
bartc <bc@freeuk.com> writes: > On 27/12/2017 17:51, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: >> >>> On 27/12/2017 14:49, jameskuyper@verizon.net wrote: >> >>>> Nope - C has NEVER been that language. You should use an assembler if you wish >>>> to have that much control over the generated code. >>> >>> Someone wants to be simply be able to write A+B instead of using ASM >>> instructions, and you're telling me there is no such language? >> >> I don't know of one but that does not mean it does not exist. How would >> it work? Would you want the types of A and B to determine which add >> instruction to use? Using what rules? > > I've written actual compilers for five targets (PDP10, Z80, three > generations of x86). (And developed some on paper for others but I > never got around to using the hardware. But they would have worked the > same way.) > > In all cases, you write A+B in the language rather than having to > write the sequence of machine instructions that would do the same > job. (They will vary according to type and width.) > > Overflow for integer arithmetic was never considered. Whatever bit > pattern the machine ended up with, that's what you got. > > If overflow shouldn't have happened, then you detect this during > normal testing, and made adjustments (use a wider type, different > logic, report bad input etc). You don't want a language using it as an > excuse to do weird stuff. I can't read any of this as an answer to my two questions. I've got a feeling we are just talking past each other -- and that's pointless. I don't know of a language that allows you to avoid writing assembler when you want control over what instructions are generated. You appeared to think this would be a good idea (because, I think, you once though C was that language) but you are not answering my questions about how that would work. For example, if A is and integer and B a floating-point number, what instructions should be generated? > And in fact, most C compilers I can test today will do exactly the > same: Pelles C, lccwin, DMC, Tiny C, Mcc. As will gcc using -O0. (MVSC > and clang I can't test.) > > It is the simplest and most obvious thing to do. No one needs to learn > about UB unless it really is UB (eg. access past end of an array), and > then it will be obvious without the language having to spell it out. It really is UB because it's really undefined by the language specification. UB does not mean "really bad" it only means that C does not say anything about the permitted behaviour. Let me try and help out. I don't think you want C to define the behaviour of + like Java does. You probably want integer overflow to be implementation defined and for there to be only a few of options -- silent wrapping, signaling and saturating maybe. If that is not what you want, I'm at a loss. Personally, I'd like a lot less UB and a lot more very flexible implementation-defined behaviour. I don't want C to become Java (so I don't want all sort of things to be rigidly defined) but there are many cases where I think the nuclear option of UB is undesirable. *But I would not argue for that here* because I don't think I know enough to make the case at all well. I don't know about even half the machines C is implemented on (or might be implemented on in the future) and I have very little idea about what optimisations such changes would be ruling out. >>> I'm pretty sure C didn't start off like that. >> >> Did you mean to say that you think C /did/ start off like that -- as a >> way to get an ADD instruction of some sort when writing A+B? If you did >> mean that, then what is your evidence? > > Are you suggesting one of their primary aims in creating the language > was to incorporate UB as much as possible rather than to just make it > easier to write an OS than using assembly? No, why would you say that? More to the point, why did you not answer my questions? I was asking for clarification. To answer with what seems like an absurd rhetorical question of your own is not helpful. > Since none of us really know, which is most probable? Which what? You seem to have set up a false dichotomy of your own invention. My evidence for what I believe C was intended to be comes from the writings of D M Richie. He's written a lot about C and programming languages in general. >>> At what point did it become so impossible? >> >> How you imagine people manage? The problem has alwars been that is not >> what you want it to be but there is nothing better that you know of so >> you feel motivated to complain about it a lot. > > I gave an example of a program where every compiler gave the result > that anyone would expect. Another un-answered question. If C has become impossible, how do people manage? > Except gcc using -O3, and even then only if the initialisation was > visible. > > gcc is giving weird results, yet everyone is standing up for gcc and > for the language and for ub, as though that result was desirable. At the risk of you ignoring yet another question, can you cite a post of mine where I defend gcc as though the result was desirable? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-27 21:51 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <mBU0C.135777$6P.1482@fx13.am4> |
| In reply to | #124783 |
On 27/12/2017 21:14, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: >> In all cases, you write A+B in the language rather than having to >> write the sequence of machine instructions that would do the same >> job. (They will vary according to type and width.) >> >> Overflow for integer arithmetic was never considered. Whatever bit >> pattern the machine ended up with, that's what you got. > I can't read any of this as an answer to my two questions. I've got a > feeling we are just talking past each other -- and that's pointless. > > I don't know of a language that allows you to avoid writing assembler > when you want control over what instructions are generated. I first give the example of A+B being a synonym for load A/add B when James Kuyper was going on about all the possible things that could happen when A+B was undefined. That is, a lot of things that are little to do with the routine task of adding two values. So if one option was to have to write load A/add B, then the preferred alternative is to have a simple language that lets you write A+B TO DO THE SAME JOB. But you don't want to drag in all the UB stuff you get in C that means you have are forced to consider all those alternatives. Going the other way from A+B to native code is not so useful to consider because there are lots of mappings. They vary for easy-to-understand reasons, such as varying or mixed types, widths, and the capabilities of the target. Or some simple, but /again/ reasonable optimisation is applied. What you don't bargain for is for some advanced, know-it-all compiler to throw out A+B completely and give you something you don't want instead. > It really is UB because it's really undefined by the language > specification. UB does not mean "really bad" it only means that C does > not say anything about the permitted behaviour. What was going on in my example where 'if (a==INT32_MIN)' gave a false result with gcc-O3 even though the value of a was INT32_MIN? No one knows. This why, when I benchmark small programs, I avoid going beyond gcc-O1 as no one knows what gcc is up to. I just don't trust it. > Let me try and help out. I don't think you want C to define the > behaviour of + like Java does. You probably want integer overflow to > be implementation defined and for there to be only a few of options -- > silent wrapping, signaling and saturating maybe. The main option will be silent wrapping. Because that is what typical hardware does, and what suits a low-level language more because it's also the most efficient and most basic thing it can do. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-28 02:09 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <87o9mjbo20.fsf@bsb.me.uk> |
| In reply to | #124788 |
bartc <bc@freeuk.com> writes: > On 27/12/2017 21:14, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: > >>> In all cases, you write A+B in the language rather than having to >>> write the sequence of machine instructions that would do the same >>> job. (They will vary according to type and width.) >>> >>> Overflow for integer arithmetic was never considered. Whatever bit >>> pattern the machine ended up with, that's what you got. > >> I can't read any of this as an answer to my two questions. I've got a >> feeling we are just talking past each other -- and that's pointless. >> >> I don't know of a language that allows you to avoid writing assembler >> when you want control over what instructions are generated. > What you don't bargain for is for some advanced, know-it-all compiler > to throw out A+B completely and give you something you don't want > instead. I don't recognise the problem you appear to be describing. As far as I can tell, in the example you gave, the addition is not thrown out. Are you getting worried about fantasy problems? >> It really is UB because it's really undefined by the language >> specification. UB does not mean "really bad" it only means that C does >> not say anything about the permitted behaviour. > > What was going on in my example where 'if (a==INT32_MIN)' gave a false > result with gcc-O3 even though the value of a was INT32_MIN? I don't think the test gave a false result. I imagine the test was removed. > No one knows. This why, when I benchmark small programs, I avoid going > beyond gcc-O1 as no one knows what gcc is up to. I just don't trust > it. That's wise. You can't trust it to honour your assumptions about what C programs should do. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-28 12:21 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p22k39$2rd$1@dont-email.me> |
| In reply to | #124788 |
On 27/12/17 22:51, bartc wrote: > On 27/12/2017 21:14, Ben Bacarisse wrote: <snip> > >> It really is UB because it's really undefined by the language >> specification. UB does not mean "really bad" it only means that C does >> not say anything about the permitted behaviour. > > What was going on in my example where 'if (a==INT32_MIN)' gave a false > result with gcc-O3 even though the value of a was INT32_MIN? > > No one knows. This why, when I benchmark small programs, I avoid going > beyond gcc-O1 as no one knows what gcc is up to. I just don't trust it. I can't answer for anyone else, but /I/ know what is going on here. The compiler is optimising based on the code you have given it. With undefined behaviour, you can end up with contradictory information. In this case, the compiler knew that "a" could not possibly be equal to INT32_MIN, and thus did what programmers usually want - generated more efficient code based on that knowledge. By coincidence, but /not/ by design of the C code, the value of "a" happened to reach INT32_MIN as a result of the undefined behaviour. You don't understand this because you won't let yourself understand it - you think it is fundamentally wrong in some way, and try to deny its existence or claim that everybody else is confused, wrong, or conspiring to make your life difficult. (Compare and contrast this attitude with people who would have preferred signed overflow to be implementation defined or fully defined in the standards - but still understand that it is not defined.) If you don't trust gcc here, then I've got news for you - it is not just at -O3 that this happens. gcc optimises on the assumption that signed integers don't overflow even at -O1 - and in some cases, it could well do so at -O0. No doubt the idea that a compiler might do some optimisation at -O0 will bring new floods of tears. And the same applies to clang, MSVC, icc, and any other serious compiler. Details of exactly what optimisations are done with what source code and with which flags will, of course, vary. > >> Let me try and help out. I don't think you want C to define the >> behaviour of + like Java does. You probably want integer overflow to >> be implementation defined and for there to be only a few of options -- >> silent wrapping, signaling and saturating maybe. > > The main option will be silent wrapping. Because that is what typical > hardware does, and what suits a low-level language more because it's > also the most efficient and most basic thing it can do. > Ignoring the possibility of integer overflow is more basic and more efficient, and suits C just fine.
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2017-12-28 00:14 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <8ef17630-0664-4ce5-acae-4080e024e2e9@googlegroups.com> |
| In reply to | #124783 |
All the problem of C about overflow on numbers can be find a solution if it is implemented in the language a fixed float type with digit() function for controlling how is big the float part approximation of this type, all the system has use; and the integer part is limited from memory the sys has; as Axiom seems to me made; and nothing else changed... As APL, integer and unsigned type could be the one float has float point part =0 (I'm not sure of this part). But I think that using array and operation on each integer this can be done even in 8bit CPU. The problem other that detect overflow is give result to bignum operations
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-27 08:57 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <0bb07a27-b613-4904-bb9e-2da44681296a@googlegroups.com> |
| In reply to | #124741 |
On Wednesday, December 27, 2017 at 8:49:45 AM UTC-6, james...@verizon.net wrote: > On Wednesday, December 27, 2017 at 9:30:52 AM UTC-5, Bart wrote: > > This is pretty scary. Are we still talking about the same low level > > language where A+B, applied to an R-sized integer, is just a convenient > > synonym for: > > > > load R, [A] > > add R, [B] > > > > ? > > Nope - C has NEVER been that language. The authors of the Rationale explicitly stated that they did not wish to preclude the use of the language as a "high-level assembler", and observed that one of C's strengths was its ability to support non-portable constructs. Further, one of Ritchie's objectives was to make it easy to port code written in B--a language which was only suitable for machines which used wrapping integer arithmetic, pointers that would behave linearly within any particular object, etc., but would behave like a straightforward low-level translator when used on such machines. If one were to recognize a category of implementations which strengthen the as-if rule to specify that a program must behave in a fashion consistent with its executing each step (statement or sub-expression), *individully* in sequence, in the absence of what Annex L would call "critical UB", or indicate in Implementation-Defined fashion an inability to continue doing so, that would on most platforms offer many many behavioral guarantees beyond those which the Standard would otherwise require.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-27 09:55 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <lnwp18dpj2.fsf@kst-u.example.com> |
| In reply to | #124757 |
supercat@casperkitty.com writes:
> On Wednesday, December 27, 2017 at 8:49:45 AM UTC-6, james...@verizon.net wrote:
>> On Wednesday, December 27, 2017 at 9:30:52 AM UTC-5, Bart wrote:
>> > This is pretty scary. Are we still talking about the same low level
>> > language where A+B, applied to an R-sized integer, is just a convenient
>> > synonym for:
>> >
>> > load R, [A]
>> > add R, [B]
>> >
>> > ?
>>
>> Nope - C has NEVER been that language.
>
> The authors of the Rationale explicitly stated that they did not wish to
> preclude the use of the language as a "high-level assembler", and observed
> that one of C's strengths was its ability to support non-portable constructs.
The context from the C99 Rationale:
C code can be non-portable. Although it strove to give
programmers the opportunity to write truly portable programs,
the C89 Committee did not want to force programmers into
writing portably, to preclude the use of C as a “high-level
assembler”: the ability to write machine-specific code is
one of the strengths of C. It is this principle which largely
motivates drawing the distinction between strictly conforming
program and conforming program.
My summary: Code that treats C as a "high-level assembler" is
non-portable.
> Further, one of Ritchie's objectives was to make it easy to port code
> written in B--a language which was only suitable for machines which used
> wrapping integer arithmetic, pointers that would behave linearly within
> any particular object, etc., but would behave like a straightforward
> low-level translator when used on such machines.
Citation needed. I just checked the B reference manual
https://www.bell-labs.com/usr/dmr/www/bref.pdf
and there's no mention of wrapping integer arithmetic.
[...]
--
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-27 11:07 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <b7ca73da-d5bb-4d4c-9769-c149325957e7@googlegroups.com> |
| In reply to | #124766 |
On Wednesday, December 27, 2017 at 11:55:24 AM UTC-6, Keith Thompson wrote: > The context from the C99 Rationale: > > C code can be non-portable. Although it strove to give > programmers the opportunity to write truly portable programs, > the C89 Committee did not want to force programmers into > writing portably, to preclude the use of C as a “high-level > assembler”: the ability to write machine-specific code is > one of the strengths of C. It is this principle which largely > motivates drawing the distinction between strictly conforming > program and conforming program. > > My summary: Code that treats C as a "high-level assembler" is > non-portable. If one wants to target a library toward four platforms, each of which has three build systems, and one wants to make five programs that use that library available to everyone using any one of those platforms and build systems, how many different things should one need to build and test? Sixty (3x4x5)? Or twelve (one config file for each build system, one set of library sources for each platform, and one set of source files for each application)? Code which targets a Motorola 68000-based platform with a CS8900 chip located at address 0xD00300 should not be expected to work on other kinds of platform, but there's no reason such code shouldn't be usable with general-purpose implementations targeting all such platforms. > > Further, one of Ritchie's objectives was to make it easy to port code > > written in B--a language which was only suitable for machines which used > > wrapping integer arithmetic, pointers that would behave linearly within > > any particular object, etc., but would behave like a straightforward > > low-level translator when used on such machines. > > Citation needed. I just checked the B reference manual > https://www.bell-labs.com/usr/dmr/www/bref.pdf > and there's no mention of wrapping integer arithmetic. Systems programming essentially requires the ability to read and write storage locations that contain all possible combinations of bits, and B requires that addresses and integers be treated interchangeably. Even something as simple as a hex import/export would be rather impractical without having a type that can hold all possible bit patterns (e.g. unsigned char in C) and a type that supports power-of-two modular arithmetic (e.g. unsigned int in C). Given that B has neither such type, I would suggest that it would be unsuitable for its stated purpose on platforms where its integer type didn't have both abilities.
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2017-12-27 22:04 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <l3194d99f4f9dl4thfbovddavffdld9pj8@4ax.com> |
| In reply to | #124741 |
On Wed, 27 Dec 2017 06:49:28 -0800 (PST), jameskuyper@verizon.net wrote: >On Wednesday, December 27, 2017 at 9:30:52 AM UTC-5, Bart wrote: >> On 27/12/2017 13:50, James R. Kuyper wrote: >> >> > 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: >> > >> > 1. The implementation could implement saturation arithmetic (even if the >> > hardware uses some other approach to overflow handling), so that c will >> > end up with either the value INT_MAX or INT_MIN. As a result, your first >> > if() condition can never be true, so your program will never execute >> > either printf() call. The compiler might notice this fact, and as a >> > result it can optimize your code by removing the entire if-statement. >> > >> > 2. If an implementation provides ordinary 2's complement handling of >> > overflow, the if() condition can only be met if the addition had >> > undefined behavior, so an implementation is still entitled to optimize >> > your code by removing the entire if-statement. >> > >> > 3. If your code calls foo() with arguments that would cause the addition >> > to overflow, and if the compiler is capable of figuring out that this is >> > unavoidably the case (which would require, among other things, that the >> > definition of foo() be visible to the compiler), it can use that fact to >> > justify removing not only call to foo(), but also every statement >> > preceding the call to foo() if that statement would, inevitably, be >> > followed by an overflowing call to foo(). >> > >> > 4. Wherever I mention above the possibility of removing some code, an >> > implementation is also allowed to replace that code with anything it >> > wants, such as displaying a pop-up at run time saying "You failed to >> > prevent integer overflow.". >> >> This is pretty scary. Are we still talking about the same low level >> language where A+B, applied to an R-sized integer, is just a convenient >> synonym for: >> >> load R, [A] >> add R, [B] >> >> ? > >Nope - C has NEVER been that language. You should use an assembler if you wish >to have that much control over the generated code. Using C means trusting the compiler to know the details of how the target platform works (which means that you don't have to know those details), and to use that knowledge to generate code that you might never have expect it to generate, to produce precisely the same observable behavior that you requested, possibly executing faster than the assembly code you might have written by hand. If you don't trust your C compiler to do that, don't use C - use something else you do trust - and stop complaining about C not being the language you want it to be. > >When you write code with undefined behavior, the behavior you're requesting the compiler to generate is "Surprise me! I don't care what this code does when executed.". If that doesn't accurately describe what you want the code to do, it's your responsibility to avoid writing such code. I find this rather interesting: gcc -o main *.c -O3 main.c: In function ‘main’: main.c:20:2: warning: iteration 5 invokes undefined behavior [-Waggressive-loop-optimizations] ++a; ^~~ main.c:13:1: note: within this loop for (i = 1; i <= 10; ++i) ^~~ $main 1 +2147483642 2 +2147483643 3 +2147483644 4 +2147483645 5 +2147483646 6 +2147483647 INT32_MAX 7 -2147483648 8 -2147483647 9 -2147483646 10 -2147483645 GNU C11 (GCC) version 7.1.1 20170622 (Red Hat 7.1.1-3) (x86_64-redhat-linux) It emits the warning even on -O2. But an earlier GCC on Debian silently accepts: gcc version 4.3.2 (Debian 4.3.2-1.1) $ gcc test.c -O3 $ ./a.out 1 +2147483642 2 +2147483643 3 +2147483644 4 +2147483645 5 +2147483646 6 +2147483647 INT32_MAX 7 -2147483648 8 -2147483647 9 -2147483646 10 -2147483645
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-28 12:27 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p22keq$4vn$1@dont-email.me> |
| In reply to | #124803 |
On 28/12/17 07:04, Geoff wrote: > On Wed, 27 Dec 2017 06:49:28 -0800 (PST), jameskuyper@verizon.net > wrote: > >> On Wednesday, December 27, 2017 at 9:30:52 AM UTC-5, Bart wrote: >>> On 27/12/2017 13:50, James R. Kuyper wrote: >>> >>>> 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: >>>> >>>> 1. The implementation could implement saturation arithmetic (even if the >>>> hardware uses some other approach to overflow handling), so that c will >>>> end up with either the value INT_MAX or INT_MIN. As a result, your first >>>> if() condition can never be true, so your program will never execute >>>> either printf() call. The compiler might notice this fact, and as a >>>> result it can optimize your code by removing the entire if-statement. >>>> >>>> 2. If an implementation provides ordinary 2's complement handling of >>>> overflow, the if() condition can only be met if the addition had >>>> undefined behavior, so an implementation is still entitled to optimize >>>> your code by removing the entire if-statement. >>>> >>>> 3. If your code calls foo() with arguments that would cause the addition >>>> to overflow, and if the compiler is capable of figuring out that this is >>>> unavoidably the case (which would require, among other things, that the >>>> definition of foo() be visible to the compiler), it can use that fact to >>>> justify removing not only call to foo(), but also every statement >>>> preceding the call to foo() if that statement would, inevitably, be >>>> followed by an overflowing call to foo(). >>>> >>>> 4. Wherever I mention above the possibility of removing some code, an >>>> implementation is also allowed to replace that code with anything it >>>> wants, such as displaying a pop-up at run time saying "You failed to >>>> prevent integer overflow.". >>> >>> This is pretty scary. Are we still talking about the same low level >>> language where A+B, applied to an R-sized integer, is just a convenient >>> synonym for: >>> >>> load R, [A] >>> add R, [B] >>> >>> ? >> >> Nope - C has NEVER been that language. You should use an assembler if you wish >> to have that much control over the generated code. Using C means trusting the compiler to know the details of how the target platform works (which means that you don't have to know those details), and to use that knowledge to generate code that you might never have expect it to generate, to produce precisely the same observable behavior that you requested, possibly executing faster than the assembly code you might have written by hand. If you don't trust your C compiler to do that, don't use C - use something else you do trust - and stop complaining about C not being the language you want it to be. >> >> When you write code with undefined behavior, the behavior you're requesting the compiler to generate is "Surprise me! I don't care what this code does when executed.". If that doesn't accurately describe what you want the code to do, it's your responsibility to avoid writing such code. > > I find this rather interesting: > > gcc -o main *.c -O3 > main.c: In function ‘main’: > main.c:20:2: warning: iteration 5 invokes undefined behavior > [-Waggressive-loop-optimizations] > ++a; > ^~~ > main.c:13:1: note: within this loop > for (i = 1; i <= 10; ++i) > ^~~ > $main > 1 +2147483642 > 2 +2147483643 > 3 +2147483644 > 4 +2147483645 > 5 +2147483646 > 6 +2147483647 INT32_MAX > 7 -2147483648 > 8 -2147483647 > 9 -2147483646 > 10 -2147483645 > > > GNU C11 (GCC) version 7.1.1 20170622 (Red Hat 7.1.1-3) > (x86_64-redhat-linux) > > It emits the warning even on -O2. > > > But an earlier GCC on Debian silently accepts: > > gcc version 4.3.2 (Debian 4.3.2-1.1) > $ gcc test.c -O3 > $ ./a.out > > 1 +2147483642 > 2 +2147483643 > 3 +2147483644 > 4 +2147483645 > 5 +2147483646 > 6 +2147483647 INT32_MAX > 7 -2147483648 > 8 -2147483647 > 9 -2147483646 > 10 -2147483645 > gcc's warnings have been steadily improving. It is difficult to give good warnings in many cases - in particular, it can be hard to distinguish between cases where code is removed like this due to errors in the source code, and cases where it is removed because it simply turns out to be unnecessary when the compiler takes more information into account. gcc used to have a "-Wunreachable-code" warning that would have been triggered in this case - but that warning was removed later because it caused so many false positives from the knock-on effect of more optimisations.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2017-12-27 11:05 -0500 |
| Subject | Re: UB in asm |
| Message-ID | <%wP0C.11007$lH5.965@fx31.iad> |
| In reply to | #124740 |
On 12/27/17 9:30 AM, bartc wrote:
> On 27/12/2017 13:50, James R. Kuyper wrote:
>
>> 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:
>>
>> 1. The implementation could implement saturation arithmetic (even if
>> the hardware uses some other approach to overflow handling), so that c
>> will end up with either the value INT_MAX or INT_MIN. As a result,
>> your first if() condition can never be true, so your program will
>> never execute either printf() call. The compiler might notice this
>> fact, and as a result it can optimize your code by removing the entire
>> if-statement.
>>
>> 2. If an implementation provides ordinary 2's complement handling of
>> overflow, the if() condition can only be met if the addition had
>> undefined behavior, so an implementation is still entitled to optimize
>> your code by removing the entire if-statement.
>>
>> 3. If your code calls foo() with arguments that would cause the
>> addition to overflow, and if the compiler is capable of figuring out
>> that this is unavoidably the case (which would require, among other
>> things, that the definition of foo() be visible to the compiler), it
>> can use that fact to justify removing not only call to foo(), but also
>> every statement preceding the call to foo() if that statement would,
>> inevitably, be followed by an overflowing call to foo().
>>
>> 4. Wherever I mention above the possibility of removing some code, an
>> implementation is also allowed to replace that code with anything it
>> wants, such as displaying a pop-up at run time saying "You failed to
>> prevent integer overflow.".
>
> This is pretty scary. Are we still talking about the same low level
> language where A+B, applied to an R-sized integer, is just a convenient
> synonym for:
>
> load R, [A]
> add R, [B]
>
> ?
>
> In which case none of those things are going to happen.
>
> Whether the programmer expects any overflow to occur or not, what they
> do expect is the same behaviour across compilers, across compiler
> options, and even across machines if the ones of interest treat addition
> in the same way. (Namely, using twos complement and with wraparound
> behaviour on overflow. In any case, usually the same addition
> instruction does both signed and unsigned.)
>
> The exception should be where the programmer explicitly tells the
> compiler to do something different. But that will then be highly
> non-portable if the same code is expected to be compiled by other people
> with different tools and different options.
>
> Here's a case in point:
>
> //--------------------------------------------------
> #include <stdio.h>
> #include <stdint.h>
> #include <limits.h>
>
> 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");
> ++a;
> }
>
> }
> //--------------------------------------------------
>
> I expect the output to be this:
>
> 1 +2147483642
> 2 +2147483643
> 3 +2147483644
> 4 +2147483645
> 5 +2147483646
> 6 +2147483647 INT32_MAX
> 7 -2147483648 INT32_MIN
> 8 -2147483647
> 9 -2147483646
> 10 -2147483645
>
> And in fact I get it on all compilers ...
>
> ... except, funnily enough, on gcc when I use -O3, when it gives this:
>
> 1 +2147483642
> 2 +2147483643
> 3 +2147483644
> 4 +2147483645
> 5 +2147483646
> 6 +2147483647 INT32_MAX
> 7 -2147483648
> 8 -2147483647
> 9 -2147483646
> 10 -2147483645
>
> (That is, comparing A againt INT32_MIN fails when A is supposed to be
> INT32_MIN.)
>
> The same when adding a big heap of options to gcc (obviously, not quite
> enough).
>
> But I've just remembered I'm not allowed to say anything bad about gcc
> in this group, because there is never anything wrong with it, it's only
> bart who doesn't understand how to use it and doesn't understand the
> language.
>
> Whenever it unhelpfully gives weird results like this at odds with any
> other compiler, it's perfectly alright because it's using UB to be able
> to do anything it likes.
>
If you want gcc to be close to the processor, DON'T turn on high level
of optimization (or perhaps add additional options to turn off
optimizations based on the undefined behavior that your code uses). My
guess is that with O3 gcc has unrolled the loop (something your straight
asm model wouldn't do), and then noticed that a is only incremented and
thus without overflow it can't be equal to INT32_MIN.
Perhaps you have something that gcc's can be very aggressive in
optimizing based on what the standard defines as undefined behavior, and
your expectation is that the compiler shouldn't be 'that smart' and just
do what the machine naturally does. The team that develops gcc has
decided that what users really want is the best results for people who
do avoid behavior defined as Undefined Behavior by the Standard (and the
general user community doesn't seem to mind that choice). To their
credit, they do tend to provide an option to be 'less smart' and not
optimize on that piece of UB. One key to do that in gcc is not enable
higher levels of optimization, but ultimately, you do need to understand
what the standard defines as undefined behavior, and the gcc options you
need to use to make that defined the way you want.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-12-28 16:36 +1300 |
| Subject | Re: UB in asm |
| Message-ID | <faj768Ft041U1@mid.individual.net> |
| In reply to | #124740 |
On 12/28/2017 03:30 AM, bartc wrote:
>
> Whether the programmer expects any overflow to occur or not, what they
> do expect is the same behaviour across compilers, across compiler
> options, and even across machines if the ones of interest treat addition
> in the same way. (Namely, using twos complement and with wraparound
> behaviour on overflow. In any case, usually the same addition
> instruction does both signed and unsigned.)
>
> The exception should be where the programmer explicitly tells the
> compiler to do something different. But that will then be highly
> non-portable if the same code is expected to be compiled by other people
> with different tools and different options.
>
> Here's a case in point:
>
> //--------------------------------------------------
> #include <stdio.h>
> #include <stdint.h>
> #include <limits.h>
>
> 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");
> ++a;
> }
>
> }
> //--------------------------------------------------
<snip>
> .... except, funnily enough, on gcc when I use -O3, when it gives this:
>
> 1 +2147483642
> 2 +2147483643
> 3 +2147483644
> 4 +2147483645
> 5 +2147483646
> 6 +2147483647 INT32_MAX
> 7 -2147483648
> 8 -2147483647
> 9 -2147483646
> 10 -2147483645
Did you look at the warnings?
gcc -std=c11 -O3 x.c
x.c: In function ‘main’:
x.c:19:5: warning: iteration 5 invokes undefined behavior
[-Waggressive-loop-optimizations]
++a;
^~~
x.c:12:3: note: within this loop
for (i = 1; i <= 10; ++i)
^~~
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-28 12:31 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <Mu51C.233096$4O3.107661@fx15.am4> |
| In reply to | #124802 |
On 28/12/2017 03:36, Ian Collins wrote: > On 12/28/2017 03:30 AM, bartc wrote: > Did you look at the warnings? > > gcc -std=c11 -O3 x.c > x.c: In function ‘main’: > x.c:19:5: warning: iteration 5 invokes undefined behavior > [-Waggressive-loop-optimizations] > ++a; > ^~~ > x.c:12:3: note: within this loop > for (i = 1; i <= 10; ++i) > ^~~ It's not undefined behaviour with -O0 or -O1? It doesn't appear to be with any other compiler I tried, whatever optimisation was chosen. I've also tried godbolt.org, and using MSVC with /O2 /W4 shows nothing. Neither does icc 18 using -O3. But I can't run the code to see what it does. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-28 12:35 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <iy51C.90130$2X3.4069@fx32.am4> |
| In reply to | #124815 |
On 28/12/2017 12:31, bartc wrote: > On 28/12/2017 03:36, Ian Collins wrote: >> On 12/28/2017 03:30 AM, bartc wrote: > >> Did you look at the warnings? >> >> gcc -std=c11 -O3 x.c >> x.c: In function ‘main’: >> x.c:19:5: warning: iteration 5 invokes undefined behavior >> [-Waggressive-loop-optimizations] >> ++a; >> ^~~ >> x.c:12:3: note: within this loop >> for (i = 1; i <= 10; ++i) >> ^~~ > > It's not undefined behaviour with -O0 or -O1? > > It doesn't appear to be with any other compiler I tried, whatever > optimisation was chosen. > > I've also tried godbolt.org, and using MSVC with /O2 /W4 shows nothing. > Neither does icc 18 using -O3. But I can't run the code to see what it > does. Neither does clang with -O3. But as I said I can't run the results of these big compilers so I don't know what results they will give. And this is the problem.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-28 15:05 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p22tn7$56o$1@dont-email.me> |
| In reply to | #124815 |
On 28/12/17 13:31, bartc wrote: > On 28/12/2017 03:36, Ian Collins wrote: >> On 12/28/2017 03:30 AM, bartc wrote: > >> Did you look at the warnings? >> >> gcc -std=c11 -O3 x.c >> x.c: In function ‘main’: >> x.c:19:5: warning: iteration 5 invokes undefined behavior >> [-Waggressive-loop-optimizations] >> ++a; >> ^~~ >> x.c:12:3: note: within this loop >> for (i = 1; i <= 10; ++i) >> ^~~ > > It's not undefined behaviour with -O0 or -O1? It is undefined behaviour at /all/ levels of optimisation, on /all/ compilers - unless the compiler specifically documents a behaviour for signed overflow. But spotting this undefined behaviour requires quite sophisticated code analysis. gcc doesn't make the effort (in this case) until -O2 or higher. Other compilers may or may not do such analysis. > > It doesn't appear to be with any other compiler I tried, whatever > optimisation was chosen. > > I've also tried godbolt.org, and using MSVC with /O2 /W4 shows nothing. > Neither does icc 18 using -O3. But I can't run the code to see what it > does. >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-28 14:47 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <87zi62ap03.fsf@bsb.me.uk> |
| In reply to | #124815 |
bartc <bc@freeuk.com> writes: > On 28/12/2017 03:36, Ian Collins wrote: >> On 12/28/2017 03:30 AM, bartc wrote: > >> Did you look at the warnings? >> >> gcc -std=c11 -O3 x.c >> x.c: In function ‘main’: >> x.c:19:5: warning: iteration 5 invokes undefined behavior [-Waggressive-loop-optimizations] >> ++a; >> ^~~ >> x.c:12:3: note: within this loop >> for (i = 1; i <= 10; ++i) >> ^~~ > > It's not undefined behaviour with -O0 or -O1? > > It doesn't appear to be with any other compiler I tried, whatever > optimisation was chosen. At this point I'd ask a student showing this kind of misunderstanding to explain "undefined behaviour" to me. By this time it would be clear that my attempts at explaining the concept had not been successful, and the best way forward was to find out what impression the students had about the notion so I could tell what had gone wrong. That strategy does not work well on Usenet. Mind you, I am not entirely sure you /do/ misunderstand it. It could be that you are simply misrepresenting it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2017-12-28 11:45 -0500 |
| Subject | Re: UB in asm |
| Message-ID | <Lc91C.27274$BH4.16935@fx02.iad> |
| In reply to | #124824 |
On 12/28/17 9:47 AM, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: > >> On 28/12/2017 03:36, Ian Collins wrote: >>> On 12/28/2017 03:30 AM, bartc wrote: >> >>> Did you look at the warnings? >>> >>> gcc -std=c11 -O3 x.c >>> x.c: In function ‘main’: >>> x.c:19:5: warning: iteration 5 invokes undefined behavior [-Waggressive-loop-optimizations] >>> ++a; >>> ^~~ >>> x.c:12:3: note: within this loop >>> for (i = 1; i <= 10; ++i) >>> ^~~ >> >> It's not undefined behaviour with -O0 or -O1? >> >> It doesn't appear to be with any other compiler I tried, whatever >> optimisation was chosen. > > At this point I'd ask a student showing this kind of misunderstanding to > explain "undefined behaviour" to me. By this time it would be clear > that my attempts at explaining the concept had not been successful, and > the best way forward was to find out what impression the students had > about the notion so I could tell what had gone wrong. > > That strategy does not work well on Usenet. Mind you, I am not entirely > sure you /do/ misunderstand it. It could be that you are simply > misrepresenting it. > The one thing that needs to be pointed out is that one possible result of Undefined Behavior is exactly what was expected. That doesn't make it not Undefined Behavior, just makes it harder to find. The other thing about Undefined Behavior is that just because the C Standard calls something Undefined, doesn't automatically mean it is bad, (maybe just not portable), as the Implementation might provide a definition of behavior in that case, possibly based on some additional standard that it conforms to, or perhaps just a promise it makes itself, perhaps as controlled by an option.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-28 09:16 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <25d8192a-4f1c-4bec-9694-3cbff55f918e@googlegroups.com> |
| In reply to | #124831 |
On Thursday, December 28, 2017 at 10:45:41 AM UTC-6, Richard Damon wrote:
> The other thing about Undefined Behavior is that just because the C
> Standard calls something Undefined, doesn't automatically mean it is
> bad, (maybe just not portable), as the Implementation might provide a
> definition of behavior in that case, possibly based on some additional
> standard that it conforms to, or perhaps just a promise it makes itself,
> perhaps as controlled by an option.
Unfortunately, compiler documentation is often really sloppy about what an
implementation does or does not define. Unless things have changed, for
example, gcc's documentation specifies that -fno-strict-aliasing disables
certain optimizations, but doesn't actually specify what behavioral
guarantees would stem from that. Unless I'm missing something, that would
imply that one of the following is true, though I don't know which one.
1. A documented renunciation of certain optimizations would implicitly
define behaviors that would not otherwise be defined.
2. There is no option in gcc to make it define the behaviors necessary
to make it compatible with programs that would exploit aliasing.
Which of the above is correct?
[toc] | [prev] | [next] | [standalone]
Page 12 of 13 — ← Prev page 1 … 10 11 [12] 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web