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 1 of 13 [1] 2 3 … 13 Next page →
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2017-12-24 07:54 +0000 |
| Subject | Re: What every compiler writer should know about programmersWhat every compiler writer should know about programmers |
| Message-ID | <p1nmfh$4v9$1@news.xmission.com> |
In article <3c2ca45f-f33f-45ca-9f64-abf82f246588@googlegroups.com>, <supercat@casperkitty.com> wrote: >On Saturday, June 10, 2017 at 12:08:54 PM UTC-5, J. Clarke wrote: >> Which starts off with "Compiler writers are sometimes surprisingly clueless >> about programming" and that's as far as I got before I lost interest. > >There is substantial evidence that some compiler writers are far more >interested in whether the Standard would allow a compiler to behave in >some fashion, than in whether such behavior would make a compiler less >for many purposes than one that behaved more like other compilers. Or, more likely, those compiler writers have been reading this newsgroup. (Which is much more concerned with finding and yapping about "UB", than in actually talking about useful programming...) -- "You can safely assume that you have created God in your own image when it turns out that God hates all the same people you do." -- Anne Lamott
[toc] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-24 12:34 +0000 |
| Message-ID | <Q9N%B.75769$oi6.71523@fx40.am4> |
| In reply to | #124638 |
On 24/12/2017 07:54, Kenny McCormack wrote: > In article <3c2ca45f-f33f-45ca-9f64-abf82f246588@googlegroups.com>, > <supercat@casperkitty.com> wrote: >> On Saturday, June 10, 2017 at 12:08:54 PM UTC-5, J. Clarke wrote: >>> Which starts off with "Compiler writers are sometimes surprisingly clueless >>> about programming" and that's as far as I got before I lost interest. >> >> There is substantial evidence that some compiler writers are far more >> interested in whether the Standard would allow a compiler to behave in >> some fashion, than in whether such behavior would make a compiler less >> for many purposes than one that behaved more like other compilers. I can't find the first few articles in the thread. But it appears to be about this PDF: http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf Which starts off like this: "Abstract. In recent years C compiler writers have taken the attitude that tested and working production (i.e., conforming according to the C standard) C programs are buggy if they contain undefined behaviour, and they feel free to compile these programs (except benchmarks) in a way that they no longer work. ..." > > Or, more likely, those compiler writers have been reading this newsgroup. > > (Which is much more concerned with finding and yapping about "UB", than in > actually talking about useful programming...) I guess it makes people superior if they can talk at length about undefined behaviour, conforming and non-conforming programs, as I guess most normal programmers don't have a clue. It's also a useful excuse when someone complains about behaviour of their favourite compiler: Oh, you've invoked it in non-conforming mode, what do you expect? When I write ASM code I don't need to worry about undefined behaviour, or whether it conforms or non-conforms. But it's suddenly a very big deal if writing C instead. Hang on, isn't writing C supposed to make all that easier? -- bartc -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2017-12-24 12:44 +0000 |
| Message-ID | <p1o7el$7fr$1@news.albasani.net> |
| In reply to | #124643 |
On 2017-12-24, bartc <bc@freeuk.com> wrote: > > When I write ASM code I don't need to worry about undefined behaviour, > or whether it conforms or non-conforms. But it's suddenly a very big > deal if writing C instead. Hang on, isn't writing C supposed to make all > that easier? Yes. Anyway, strict aliasing is real pain. And not having to use unions to map memory in different way ;) > > -- > bartc > > -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-12-24 15:26 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p1odeh$f2h$1@dont-email.me> |
| In reply to | #124643 |
On 24/12/2017 13:34, bartc wrote:
> When I write ASM code I don't need to worry about undefined behaviour,
Several x86 opcodes have UB for some inputs.
For example, BSF and BSR ("If the content source operand is 0, the content
of the destination operand is undefined.")
Calling BSWAP on a 16-bit register.
F2XM1, FYL2XP1 on -ERANGE.
OF flag on rotate > 1 bit
Shift greater than operand size
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-24 14:58 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <AgP%B.88960$uS5.19755@fx45.am4> |
| In reply to | #124647 |
On 24/12/2017 14:26, Noob wrote:
> On 24/12/2017 13:34, bartc wrote:
>
>> When I write ASM code I don't need to worry about undefined behaviour,
>
> Several x86 opcodes have UB for some inputs.
>
> For example, BSF and BSR ("If the content source operand is 0, the content
> of the destination operand is undefined.")
So the result is undefined, that's all?
> Calling BSWAP on a 16-bit register.
> F2XM1, FYL2XP1 on -ERANGE.
> OF flag on rotate > 1 bit
> Shift greater than operand size
But I don't need to worry here:
lea rcx, [str01]
lea rdx, [str02]
call printf
about whether the address loaded into rdx has type char* or char(*)[],
or whether it will cause UB.
I don't need to worry that a block of instructions I've painstakingly
written will be elided because the compiler thinks it knows better.
Or whether a compiler will insert a block of instructions I don't want.
And talking about x86, I expect this to work:
mov eax, 0x7FFF'FFFF
add eax, 1
and for eax to end up as 0x8000'0000. Apparently that is UB in C when
the type is int32_t which I understand means the compiler is free to do
anything at all. (This ASM fragment will work for signed or unsigned
integers.)
If this value represented a signed number and I didn't intend an
overflow resulting in wraparound, then that's a logic error in my
program which is up to me to deal with.
--
bart.
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2017-12-24 21:59 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p1p4fk$74e$1@news.albasani.net> |
| In reply to | #124649 |
On 24.12.2017 15:58, bartc wrote:
>> Several x86 opcodes have UB for some inputs.
>>
>> For example, BSF and BSR ("If the content source operand is 0, the
>> content
>> of the destination operand is undefined.")
>
> So the result is undefined, that's all?
Just like with any UB in a C program: That's all.
> Or whether a compiler will insert a block of instructions I don't want.
>
> And talking about x86, I expect this to work:
>
> mov eax, 0x7FFF'FFFF
> add eax, 1
Since you have clearly demonstrated that ASM is the superior language,
great. Simply write ASM programs from now on and switch to an ASM
newsgroup. Problem solved.
You're welcome,
Johannes
--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-24 13:35 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <ln608vhkqp.fsf@kst-u.example.com> |
| In reply to | #124653 |
Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
> On 24.12.2017 15:58, bartc wrote:
>>> Several x86 opcodes have UB for some inputs.
>>>
>>> For example, BSF and BSR ("If the content source operand is 0, the
>>> content of the destination operand is undefined.")
>>
>> So the result is undefined, that's all?
>
> Just like with any UB in a C program: That's all.
No, if I understand the description of the x86 instructions correctly,
there's a big difference.
BSF and BSR are "Bit Scan Forward" and "Bit Scan Reverse", respectively.
BSF scans the source operand for the least significant 1 bit and stores
its index in the destination. If there is no 1 bit in the source
operand value, the ZF flag is set and the value stored in the
destination is undefined. As far as I can tell, no other side effects
are permitted to occur (assuming the source is valid). The destination
will contain *some* bit pattern; it's just not specified what that bit
pattern will be.
In C, "undefined behavior" means that the standard places no
requirements on the behavior, not just that some value is undefined.
For example, signed integer overflow might wrap around, it might
saturate, it might terminate your program, or it might melt your CPU
(the latter is unlikely but is permitted by the standard).
--
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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-12-24 16:10 -0600 |
| Subject | Re: UB in asm |
| Message-ID | <o3904dh32gas748oai2knv7e9qh7qnj52g@4ax.com> |
| In reply to | #124657 |
On Sun, 24 Dec 2017 13:35:58 -0800, Keith Thompson <kst-u@mib.org>
wrote:
>Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
>> On 24.12.2017 15:58, bartc wrote:
>>>> Several x86 opcodes have UB for some inputs.
>>>>
>>>> For example, BSF and BSR ("If the content source operand is 0, the
>>>> content of the destination operand is undefined.")
>>>
>>> So the result is undefined, that's all?
>>
>> Just like with any UB in a C program: That's all.
>
>No, if I understand the description of the x86 instructions correctly,
>there's a big difference.
>
>BSF and BSR are "Bit Scan Forward" and "Bit Scan Reverse", respectively.
>BSF scans the source operand for the least significant 1 bit and stores
>its index in the destination. If there is no 1 bit in the source
>operand value, the ZF flag is set and the value stored in the
>destination is undefined. As far as I can tell, no other side effects
>are permitted to occur (assuming the source is valid). The destination
>will contain *some* bit pattern; it's just not specified what that bit
>pattern will be.
That's correct, for all user mode instructions, the scope of undefined
behavior is fairly well bounded, limited to just the particular values
set in various outputs (including registers and flags), as far as I
can recall. In a few cases there may be some question as to which of
several possible exceptions is reported in certain cases.
Assuming modern-ish x86 - there was considerable slop in ye olden
days.
That is not, however, true of all system (privileged) instructions.
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2018-01-02 12:06 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p2fp47$125$1@news.albasani.net> |
| In reply to | #124657 |
On 24.12.2017 22:35, Keith Thompson wrote:
> Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
>> On 24.12.2017 15:58, bartc wrote:
>>>> Several x86 opcodes have UB for some inputs.
>>>>
>>>> For example, BSF and BSR ("If the content source operand is 0, the
>>>> content of the destination operand is undefined.")
>>>
>>> So the result is undefined, that's all?
>>
>> Just like with any UB in a C program: That's all.
>
> No, if I understand the description of the x86 instructions correctly,
> there's a big difference.
>
> BSF and BSR are "Bit Scan Forward" and "Bit Scan Reverse", respectively.
> BSF scans the source operand for the least significant 1 bit and stores
> its index in the destination. If there is no 1 bit in the source
> operand value, the ZF flag is set and the value stored in the
> destination is undefined. As far as I can tell, no other side effects
> are permitted to occur (assuming the source is valid). The destination
> will contain *some* bit pattern; it's just not specified what that bit
> pattern will be.
That might be true for the specifics of BSF or BSR.
But all bets are off when you're encoding instructions that the manual
doesn't even specify. You might well encounter a HCF instruction there,
doing exactly...
> or it might melt your CPU
> (the latter is unlikely but is permitted by the standard).
...this.
Cheers,
Johannes
--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-01-02 08:03 -0500 |
| Subject | Re: UB in asm |
| Message-ID | <QqL2C.23766$fC.853@fx43.iad> |
| In reply to | #125042 |
On 1/2/18 6:06 AM, Johannes Bauer wrote: > But all bets are off when you're encoding instructions that the manual > doesn't even specify. You might well encounter a HCF instruction there, > doing exactly... > >> or it might melt your CPU >> (the latter is unlikely but is permitted by the standard). > ...this. > I remember hearing of such a machine. There was an illegal instruction bit combination that would lock up the CPU module and create a bus conflict, that would overload the power supply, and if you left them machine in that state for a long time, it was possible to burn out the power supply, with a small possibility of actually catching things on fire. Someone did create a macro called HCF for this instruction encoding.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-01-02 08:53 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <a6d0868c-42e4-47de-94ba-43428938d445@googlegroups.com> |
| In reply to | #125044 |
On Tuesday, January 2, 2018 at 7:03:56 AM UTC-6, Richard Damon wrote: > I remember hearing of such a machine. There was an illegal instruction > bit combination that would lock up the CPU module and create a bus > conflict, that would overload the power supply, and if you left them > machine in that state for a long time, it was possible to burn out the > power supply, with a small possibility of actually catching things on fire. The 6502 had a significant number of instruction encodings which would lock up the CPU to the point that nothing other than a reset would restore operation. The CPU uses a set of one-hot latches to keep track of the current operation step; one of them indictates "start of instruction". That latch gets set on reset, or whenever the CPU is in the last state associated with the currently-executing instruction. Since interrupts can only be processed when the CPU is in the "start of instruction" state, the CPU will hang when the state falls off the end.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-01-02 09:33 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <lnzi5w9ne7.fsf@kst-u.example.com> |
| In reply to | #125044 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 1/2/18 6:06 AM, Johannes Bauer wrote:
>> But all bets are off when you're encoding instructions that the manual
>> doesn't even specify. You might well encounter a HCF instruction there,
>> doing exactly...
>>
>>> or it might melt your CPU
>>> (the latter is unlikely but is permitted by the standard).
>> ...this.
>
> I remember hearing of such a machine. There was an illegal instruction
> bit combination that would lock up the CPU module and create a bus
> conflict, that would overload the power supply, and if you left them
> machine in that state for a long time, it was possible to burn out the
> power supply, with a small possibility of actually catching things on fire.
>
> Someone did create a macro called HCF for this instruction encoding.
The case I heard about was that on systems with core memory (magnetic
rings threaded on wires), accessing a memory location in a very tight
loop could cause the core to overheat, resulting in a literal core
meltdown. This wasn't an undefined instruction but a memory access
pattern that the hardware couldn't handle. (Note that this is something
I heard about; I can't vouch for its accuracy.)
--
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 | 2018-01-02 09:53 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <93575d00-88e1-4080-a3a6-ab5cd6e1e67a@googlegroups.com> |
| In reply to | #125068 |
On Tuesday, January 2, 2018 at 11:33:15 AM UTC-6, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: > > On 1/2/18 6:06 AM, Johannes Bauer wrote: > >> But all bets are off when you're encoding instructions that the manual > >> doesn't even specify. You might well encounter a HCF instruction there, > >> doing exactly... > >> > >>> or it might melt your CPU > >>> (the latter is unlikely but is permitted by the standard). > >> ...this. > > > > I remember hearing of such a machine. There was an illegal instruction > > bit combination that would lock up the CPU module and create a bus > > conflict, that would overload the power supply, and if you left them > > machine in that state for a long time, it was possible to burn out the > > power supply, with a small possibility of actually catching things on fire. > > > > Someone did create a macro called HCF for this instruction encoding. > > The case I heard about was that on systems with core memory (magnetic > rings threaded on wires), accessing a memory location in a very tight > loop could cause the core to overheat, resulting in a literal core > meltdown. This wasn't an undefined instruction but a memory access > pattern that the hardware couldn't handle. (Note that this is something > I heard about; I can't vouch for its accuracy.) On many real systems a few years ago, accessing memory in certain particular patterns could cause data corruption in regions that weren't accessed (an issue called "row hammer"). This could be used for some kinds of "shotgun" or denial-of-service security exploits. In most cases there would be no way for a non-privileged application to control what portions of the storage would get corrupted, but a malicious application could try to cause some random corruption and hope for effects that would serve the malefactor's purposes.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-01-02 19:31 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <16R2C.62879$_G5.38182@fx25.iad> |
| In reply to | #125068 |
Keith Thompson <kst-u@mib.org> writes: >Richard Damon <Richard@Damon-Family.org> writes: >> On 1/2/18 6:06 AM, Johannes Bauer wrote: >>> But all bets are off when you're encoding instructions that the manual >>> doesn't even specify. You might well encounter a HCF instruction there, >>> doing exactly... >>> >>>> or it might melt your CPU >>>> (the latter is unlikely but is permitted by the standard). >>> ...this. >> >> I remember hearing of such a machine. There was an illegal instruction >> bit combination that would lock up the CPU module and create a bus >> conflict, that would overload the power supply, and if you left them >> machine in that state for a long time, it was possible to burn out the >> power supply, with a small possibility of actually catching things on fire. >> >> Someone did create a macro called HCF for this instruction encoding. > >The case I heard about was that on systems with core memory (magnetic >rings threaded on wires), accessing a memory location in a very tight >loop could cause the core to overheat, resulting in a literal core >meltdown. This wasn't an undefined instruction but a memory access >pattern that the hardware couldn't handle. (Note that this is something >I heard about; I can't vouch for its accuracy.) We had contracted with Arima to make a bunch of Opteron server boxes. The first few started failing after powering off remotely using IPMI - turns out the BIOS was putting the cores in a tight loop, turning off the fans and _not_ removing power from the CPU's. Instant toast.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-01-02 09:26 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <ln4lo4b29f.fsf@kst-u.example.com> |
| In reply to | #125042 |
Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
> On 24.12.2017 22:35, Keith Thompson wrote:
>> Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
>>> On 24.12.2017 15:58, bartc wrote:
>>>>> Several x86 opcodes have UB for some inputs.
>>>>>
>>>>> For example, BSF and BSR ("If the content source operand is 0, the
>>>>> content of the destination operand is undefined.")
>>>>
>>>> So the result is undefined, that's all?
>>>
>>> Just like with any UB in a C program: That's all.
>>
>> No, if I understand the description of the x86 instructions correctly,
>> there's a big difference.
>>
>> BSF and BSR are "Bit Scan Forward" and "Bit Scan Reverse", respectively.
>> BSF scans the source operand for the least significant 1 bit and stores
>> its index in the destination. If there is no 1 bit in the source
>> operand value, the ZF flag is set and the value stored in the
>> destination is undefined. As far as I can tell, no other side effects
>> are permitted to occur (assuming the source is valid). The destination
>> will contain *some* bit pattern; it's just not specified what that bit
>> pattern will be.
>
> That might be true for the specifics of BSF or BSR.
So BSF and BSR don't have undefined behavior in the sense that C defines
the term.
> But all bets are off when you're encoding instructions that the manual
> doesn't even specify. You might well encounter a HCF instruction there,
> doing exactly...
>
>> or it might melt your CPU
>> (the latter is unlikely but is permitted by the standard).
(You snipped the part where I said I was talking about C undefined
behavior, not about any CPU instructions.)
If there are CPU instructions that actually have undefined behavior in
that sense, I suggest that's a bug in the CPU or in its description.
Are there any such instructions on x86? If not, what's your point?
--
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 | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2018-01-04 10:56 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p2kto6$li2$1@news.albasani.net> |
| In reply to | #125067 |
On 02.01.2018 18:26, Keith Thompson wrote: >>> No, if I understand the description of the x86 instructions correctly, >>> there's a big difference. >>> >>> BSF and BSR are "Bit Scan Forward" and "Bit Scan Reverse", respectively. >>> BSF scans the source operand for the least significant 1 bit and stores >>> its index in the destination. If there is no 1 bit in the source >>> operand value, the ZF flag is set and the value stored in the >>> destination is undefined. As far as I can tell, no other side effects >>> are permitted to occur (assuming the source is valid). The destination >>> will contain *some* bit pattern; it's just not specified what that bit >>> pattern will be. >> >> That might be true for the specifics of BSF or BSR. > > So BSF and BSR don't have undefined behavior in the sense that C defines > the term. Isn't "something undefined happens with register X" a perfect subset of "anything may happen"? > (You snipped the part where I said I was talking about C undefined > behavior, not about any CPU instructions.) > > If there are CPU instructions that actually have undefined behavior in > that sense, I suggest that's a bug in the CPU or in its description. Some might be bugs. The upcoming CPU "preemtive execution" bug is a great example for that kind. Others might not be. For example, undefined encodings which do different things on x86 and its clones. Also, there's plenty of undefined instructions or prefix matches which the manual says nothing about except that its result is undefined. > Are there any such instructions on x86? If not, what's your point? The world is not all x86 and even if the OP referred specifically to x86, I was thinking about CPUs in a broader sense. Cheers, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2018-01-04 05:19 -0500 |
| Subject | Re: UB in asm |
| Message-ID | <p2kv3o$jcp$1@dont-email.me> |
| In reply to | #125083 |
On 01/04/2018 04:56 AM, Johannes Bauer wrote: > On 02.01.2018 18:26, Keith Thompson wrote: > >>>> No, if I understand the description of the x86 instructions correctly, >>>> there's a big difference. >>>> >>>> BSF and BSR are "Bit Scan Forward" and "Bit Scan Reverse", respectively. >>>> BSF scans the source operand for the least significant 1 bit and stores >>>> its index in the destination. If there is no 1 bit in the source >>>> operand value, the ZF flag is set and the value stored in the >>>> destination is undefined. As far as I can tell, no other side effects >>>> are permitted to occur (assuming the source is valid). The destination >>>> will contain *some* bit pattern; it's just not specified what that bit >>>> pattern will be. >>> >>> That might be true for the specifics of BSF or BSR. >> >> So BSF and BSR don't have undefined behavior in the sense that C defines >> the term. > > Isn't "something undefined happens with register X" a perfect subset of > "anything may happen"? Yes. and UB is "no restrictions". Something whose effects are restricted to giving register X an unspecified value has restrictions. Someone documenting the behavior of this instruction could use the C phrase "unspecified value", which is both perfectly correct and far more specific. >> (You snipped the part where I said I was talking about C undefined >> behavior, not about any CPU instructions.) >> >> If there are CPU instructions that actually have undefined behavior in >> that sense, I suggest that's a bug in the CPU or in its description. > > Some might be bugs. The upcoming CPU "preemtive execution" bug is a > great example for that kind. Others might not be. For example, undefined > encodings which do different things on x86 and its clones. > > Also, there's plenty of undefined instructions or prefix matches which > the manual says nothing about except that its result is undefined. > >> Are there any such instructions on x86? If not, what's your point? > > The world is not all x86 and even if the OP referred specifically to > x86, I was thinking about CPUs in a broader sense. I'd expect very few CPUs, possibly none, for which C's "undefined behavior" would be be a good model to use for describing what happens when you misuse their instruction set (anything for which UB would be a correct description HAS to count as abuse). In most cases, probably all, there are severe restrictions on what happens when you misuse an instruction.
[toc] | [prev] | [next] | [standalone]
| From | aph@littlepinkcloud.invalid |
|---|---|
| Date | 2018-01-04 05:38 -0600 |
| Subject | Re: UB in asm |
| Message-ID | <JeCdnTymip3Sj9PHnZ2dnUU7-fHNnZ2d@supernews.com> |
| In reply to | #125084 |
James Kuyper <jameskuyper@verizon.net> wrote: > I'd expect very few CPUs, possibly none, for which C's "undefined > behavior" would be be a good model to use for describing what > happens when you misuse their instruction set (anything for which UB > would be a correct description HAS to count as abuse). On ARMv8, concurrent modification and execution of instructions is undefined. It "can lead to the resulting instruction performing any behavior that can be achieved by executing any sequence of instructions ... " at the same privilege level, with some exceptions. In other words, it can do pretty much anything a program is allowed to do. That looks like UB to me. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2018-01-04 07:05 -0500 |
| Subject | Re: UB in asm |
| Message-ID | <p2l59t$ro9$1@dont-email.me> |
| In reply to | #125087 |
On 01/04/2018 06:38 AM, aph@littlepinkcloud.invalid wrote: > James Kuyper <jameskuyper@verizon.net> wrote: > >> I'd expect very few CPUs, possibly none, for which C's "undefined >> behavior" would be be a good model to use for describing what >> happens when you misuse their instruction set (anything for which UB >> would be a correct description HAS to count as abuse). > > On ARMv8, concurrent modification and execution of instructions is > undefined. It "can lead to the resulting instruction performing any > behavior that can be achieved by executing any sequence of > instructions ... " at the same privilege level, with some exceptions. > In other words, it can do pretty much anything a program is allowed to > do. That looks like UB to me. To me, too. I didn't anticipate that it would even be possible to execute and modify an instruction at the same time. I can (vaguely - I'm not even remotely qualified to design such things) imagine why the consequences of doing so would be that bad.
[toc] | [prev] | [next] | [standalone]
| From | aph@littlepinkcloud.invalid |
|---|---|
| Date | 2018-01-04 06:46 -0600 |
| Subject | Re: UB in asm |
| Message-ID | <kYCdnRr93eK-v9PHnZ2dnUU7-XnNnZ2d@supernews.com> |
| In reply to | #125089 |
James Kuyper <jameskuyper@verizon.net> wrote: > On 01/04/2018 06:38 AM, aph@littlepinkcloud.invalid wrote: >> James Kuyper <jameskuyper@verizon.net> wrote: >> >>> I'd expect very few CPUs, possibly none, for which C's "undefined >>> behavior" would be be a good model to use for describing what >>> happens when you misuse their instruction set (anything for which UB >>> would be a correct description HAS to count as abuse). >> >> On ARMv8, concurrent modification and execution of instructions is >> undefined. It "can lead to the resulting instruction performing any >> behavior that can be achieved by executing any sequence of >> instructions ... " at the same privilege level, with some exceptions. >> In other words, it can do pretty much anything a program is allowed to >> do. That looks like UB to me. > > To me, too. I didn't anticipate that it would even be possible to > execute and modify an instruction at the same time. That's easy when you've got multiple cores. > I can (vaguely - I'm not even remotely qualified to design such > things) imagine why the consequences of doing so would be that bad. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 1 of 13 [1] 2 3 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web