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 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-28 17:08 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <87k1x6aigx.fsf@bsb.me.uk> |
| In reply to | #124828 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 12/28/17 9:30 AM, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>>
>>> On 28/12/2017 09:58, David Brown wrote:
>>>> On 27/12/17 19:06, bartc wrote:
>>>
>>>> Your problem here is that you believe it is important to be able to
>>>> predict the behaviour of incorrect and meaningless programs.
>>>
>>> Written in ASM for x86, the behaviour is completely predictable.
>>
>> ... and non-portable.
>>
>>> It seems that that is one program that it is impossible to port to C
>>> and get the same predictable results with any C compiler.
>>
>> Don't be silly, you just have to write well-defined C. There are dozens
>> of way to do that but the obvious one is to say what you want to happen
>> when 'a' would overflow:
>>
>> #include <stdio.h>
>> #include <stdint.h>
>> int main(void)
>> {
>> int32_t a = INT32_MAX-5;
>> for (int i = 1; i <= 10; ++i) {
>> printf("%2d %+d",i, a);
>> if (a == INT32_MIN)
>> printf(" INT32_MIN");
>> else if (a == INT32_MAX) {
> This should be
> if (a == INT32_MAX) {
> (not else if) so the above case still does the increment.
Thanks. For some mysterious reason I put that else in only in the post.
It's not there in the program I tested. Oh well...
<text removed>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-28 14:57 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <UC71C.107024$9X4.101376@fx02.am4> |
| In reply to | #124807 |
On 28/12/2017 09:58, David Brown wrote:
> On 27/12/17 19:06, bartc wrote:
>> On 27/12/2017 16:05, David Brown wrote:
>>> On 27/12/17 16:25, bartc wrote:
>>
>>>> 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?
>>>
>>> No, he told you /C/ was not that language. James said nothing about any
>>> other languages here.
>>
>> What, another low-level language in between ASM and C? I don't believe
>> there is one, not mainstream.
>>
>
> No one mentioned any particular language. And a language that
> interprets "a + b" as a simple cpu addition instruction does not need to
> be low level, nor does it have to be "between ASM and C" in any sense.
You will know a true low-level language when you see one. C doesn't
really count any more, if it ever has.
> A programming language design can pick the behaviour it wants for its
> operations.
My own language is in this category where it allows an easy-to-write
syntax to make it easier than writing ASM.
There is also the usual abstraction, where Load/Add in ASM may be
written A+B in the language, but A+B in the language may map to
different sequences in ASM depending on what types A and B are.
But it is not mainstream.
The advantage of it is that it doesn't have of those complications that
C seems to be lumbered with. The result of A+B is always going to be
whatever result the machine ends up with.
However, there is a slight problem with that: if I generate native code
directly, the results are predictable.
It's when I generate C as intermediate code that problems can arise. If
If I write that test loop in my language (see below), then the
programmer shouldn't need to think about UB, as it doesn't exist.
But if converted to C and compiled with gcc-O3, it won't work properly.
To make it work, I would have to take every instance of signed int ops
in the generated code, and add whatever is needed to make it work
without UB.
The problem here is "++a" being translated to "++a;". That would need to
be changed to "++(*(uint32*)&a);". You can imagine what the generated C
is going to look like as virtually every operation works with signed ints.
And suppose I do do all that: I'm then effectively using a version of C
where signed ints use the overflow semantics I want. And it would work.
Why, then, can't C just work like that anyway?
--------------------------------------
import clib
proc start=
int a,i
a:=a.maxvalue-5
for i to 10 do
printf("%2d %+10d",i,a)
if a=a.minvalue then print " INT_MIN" fi
if a=a.maxvalue then print " INT_MAX" fi
println
++a
od
end
--------------------------------------
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-28 16:09 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <87tvwaal6d.fsf@bsb.me.uk> |
| In reply to | #124825 |
bartc <bc@freeuk.com> writes:
> It's when I generate C as intermediate code that problems can arise.
>
> But if converted to C and compiled with gcc-O3, it won't work
> properly.
You could fix it.
> The problem here is "++a" being translated to "++a;". That would need
> to be changed to "++(*(uint32*)&a);".
That's not how I'd do it. If I were implementing a low-level language
via C, I'd consider making almost everything (of each size) a union so I
could simply re-interpret the bits as needed:
++a.u;
if (a.s < 0) ...
etc.
> You can imagine what the
> generated C is going to look like as virtually every operation works
> with signed ints.
To some extent you seem to have made a rod for your own back. Why do
you care what the C looks like? That's a strange objective.
> And suppose I do do all that: I'm then effectively using a version of
> C where signed ints use the overflow semantics I want. And it would
> work. Why, then, can't C just work like that anyway?
Because C is not just for you.
> --------------------------------------
> import clib
>
> proc start=
> int a,i
>
> a:=a.maxvalue-5
>
> for i to 10 do
> printf("%2d %+10d",i,a)
> if a=a.minvalue then print " INT_MIN" fi
> if a=a.maxvalue then print " INT_MAX" fi
> println
> ++a
> od
> end
> --------------------------------------
#include <stdio.h>
#include <limits.h>
typedef union {
signed int s;
unsigned int u;
} Int;
int main(void)
{
Int a, i;
a.s = INT_MAX - 5;
for (i.s = 1; i.s <= 10; i.u++) {
printf("%2d %+10d", i.s, a.s);
if (a.s == INT_MIN) printf(" INT_MIN");
if (a.s == INT_MAX) printf(" INT_MAX");
puts("");
++a.u;
}
}
I think this conveys, in C, exactly what your source code means.
I think you are making very heavy weather of something that is not a
problem to most people. Obviously it's not all going to be this easy,
but I don't know your source language so I can't help you find where the
real problems will be.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-28 17:11 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p2353a$s1c$1@dont-email.me> |
| In reply to | #124825 |
On 28/12/17 15:57, bartc wrote:
> On 28/12/2017 09:58, David Brown wrote:
>> On 27/12/17 19:06, bartc wrote:
>>> On 27/12/2017 16:05, David Brown wrote:
>>>> On 27/12/17 16:25, bartc wrote:
>>>
>>>>> 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?
>>>>
>>>> No, he told you /C/ was not that language. James said nothing about
>>>> any
>>>> other languages here.
>>>
>>> What, another low-level language in between ASM and C? I don't believe
>>> there is one, not mainstream.
>>>
>>
>> No one mentioned any particular language. And a language that
>> interprets "a + b" as a simple cpu addition instruction does not need to
>> be low level, nor does it have to be "between ASM and C" in any sense.
>
> You will know a true low-level language when you see one. C doesn't
> really count any more, if it ever has.
I have decades of experience with assembly as well as C. I know C is a
low-level language. I also know it is not assembly. I get the code I
want from C, because I know how to write C and I know how to use my
compilers. If you don't know a language, and don't know the tools, it's
not surprising you have trouble.
>
>> A programming language design can pick the behaviour it wants for its
>> operations.
>
> My own language is in this category where it allows an easy-to-write
> syntax to make it easier than writing ASM.
I have seen the snippets of your language that you have posted. It
seems okay, but not as powerful or flexible as C. If it fits your
needs, then use it - and drop your pretence of programming in C. I am
sure you will feel better.
>
> There is also the usual abstraction, where Load/Add in ASM may be
> written A+B in the language, but A+B in the language may map to
> different sequences in ASM depending on what types A and B are.
>
> But it is not mainstream.
No, clearly it is not.
>
> The advantage of it is that it doesn't have of those complications that
> C seems to be lumbered with. The result of A+B is always going to be
> whatever result the machine ends up with.
That may be an advantage to /you/ - it is not an advantage to /me/. If
you ever choose to raise your gaze from beyond your own navel, you might
gain some insight into the C language, its compilers, and its users.
>
> However, there is a slight problem with that: if I generate native code
> directly, the results are predictable.
>
> It's when I generate C as intermediate code that problems can arise. If
> If I write that test loop in my language (see below), then the
> programmer shouldn't need to think about UB, as it doesn't exist.
>
> But if converted to C and compiled with gcc-O3, it won't work properly.
> To make it work, I would have to take every instance of signed int ops
> in the generated code, and add whatever is needed to make it work
> without UB.
If you tried /reading/ what people write in this group, or in other C
resources, you would learn how to use C properly. Then you could
generate C code that is correct, and go back to programming in your own
language.
>
> The problem here is "++a" being translated to "++a;". That would need to
> be changed to "++(*(uint32*)&a);". You can imagine what the generated C
> is going to look like as virtually every operation works with signed ints.
You really do enjoy making up shite, don't you?
1. You need to use unsigned integer types, or cast to unsigned types at
the right places, if you want wraparound behaviour from standard C. You
don't need to use pointer casts.
2. It /does/ /not/ /matter/ what the generated C code looks like. You
can quite happily translate your "++a" into "INC_INT(a)" and have a
macro for it. Or you can translate it inline to "a = (uint32_t) a + 1".
Or whatever. It does not matter in the slightest. The need for
"pretty" generated C code is all in your head.
3. You could solve all your problems, real or imaginary, by sticking
this at the head of your generated C files:
#ifdef __GNUC__
#pragma GCC optimize ("-fwrapv")
#pragma GCC optimize ("-fno-strict-aliasing")
#endif
>
> And suppose I do do all that: I'm then effectively using a version of C
> where signed ints use the overflow semantics I want. And it would work.
> Why, then, can't C just work like that anyway?
Other people do not /want/ C to work like that!
You live in your own bizarre little world of fear and hatred of a
programming language, with your own personal ideas of what it should be
and how it should be used. How can you be so blinkered? How is it that
you can write hundreds of posts here, and apparently read hundreds of
replies, and still not get it? Most C programmers have no problem with
the way C and C compilers handle overflows. Some don't like it, but can
live fine with it - others /do/ like it and are happy with that choice
of tradeoffs. Most people probably don't care, because overflow is rare
in the real world - they don't give a *beep* what happens when
incrementing a value beyond 2 billion because their code does not do that.
>
> --------------------------------------
> import clib
>
> proc start=
> int a,i
>
> a:=a.maxvalue-5
>
> for i to 10 do
> printf("%2d %+10d",i,a)
> if a=a.minvalue then print " INT_MIN" fi
> if a=a.maxvalue then print " INT_MAX" fi
> println
> ++a
> od
> end
> --------------------------------------
>
It looks okay - but nothing special. I don't like "fi" and "od", but
that is personal preference and perhaps lack of practice - I'm sure I
could get used to it. The mix of "printf" and "print" is a bit jarring,
as is the mix of function call syntax, and the mix of block delimiters
with line-oriented syntax.
I do like the easy access to the maximum value for a type "a.maxvalue" -
if this is something that is consistent, and there is a similar syntax
for a variety of useful information about any type or variable. A
syntax like Ada's "attribute" syntax would be a nice feature in any
language.
Other than that, I can't make any serious judgement from a snippet like
that. It is just code in a structured, statically typed procedural
language. The syntax details are not particularly exciting here - it
does not stand out from a dozen or more existing languages.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-28 17:04 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <2u91C.109845$5Z7.61290@fx29.am4> |
| In reply to | #124827 |
On 28/12/2017 16:11, David Brown wrote: > On 28/12/17 15:57, bartc wrote: > 2. It /does/ /not/ /matter/ what the generated C code looks like. You > can quite happily translate your "++a" into "INC_INT(a)" and have a > macro for it. Or you can translate it inline to "a = (uint32_t) a + 1". > Or whatever. It does not matter in the slightest. The need for > "pretty" generated C code is all in your head. I don't want to have to go to all that trouble. If using C source as the target of a compiler turns out to be harder and more fiddly than using ASM, then there is something wrong. > You live in your own bizarre little world of fear and hatred of a > programming language, with your own personal ideas of what it should be > and how it should be used. How can you be so blinkered? My posts in the subthread started after reading this: James Kuyper: > A key point to consider is that the behavior of a+b is undefined if it > results in overflow. That means that the C standard imposes no > requirements on the behavior of your program. Among an infinite number > of other possibilities: Followed by a complicated list of the said possibilities that I'm not interested in having to keep in mind. How about this possibility: 0. Just do the a+b addition even if it overflows. That's a lot easier to remember, and will not affect well-written code that will not have overflow. I suggest a poll at this point to see who would be in favour of James' possibilities 1. to 5., and who would prefer my possibility 0. > Most people probably don't care, because overflow is rare > in the real world - they don't give a *beep* what happens when > incrementing a value beyond 2 billion because their code does not do that. I don't usually care about it either. But in C I /have/ to care about it because apparently anything like this in a program is the equivalent of red Kryptonite to Superman - anything could happen including a lot of weird stuff. (In my byte-code interpreter, overflows of 64-bit integer arithmetic are not checked. Possibilities included reporting as an error (possibly trapped via an exception mechanism), or to represent the result as a big-integer value. I chose not to check because it is simpler, more efficient, and more predictable (if I wanted to type-infer the result of A+B for example, if I already knew the types of A and B). Also, because sometimes the interpreter code has to be represented as C source, that doesn't make it easy or efficient to do overflow checking. That any 64-bit signed int operation - on operands which come from the user-program being executed so I've no idea what they are - could result in UB in the C code is an extra headache. Or an extra bonus according to most opinions here.) > Other than that, I can't make any serious judgement from a snippet like > that. I'm not asking for judgement. It's just very ordinary, workmanlike code to get stuff done without any fuss. The fuss starts however when it goes through C. > It is just code in a structured, statically typed procedural > language. The syntax details are not particularly exciting here - it > does not stand out from a dozen or more existing languages. The key thing is that the language doesn't say that signed int overflow results in undefined behaviour. Another thing about it is that implementations will usually do what the code says. Both these promises are undermined when it is necessary to go via C source code. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-28 09:16 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <ln4loaeprp.fsf@kst-u.example.com> |
| In reply to | #124837 |
bartc <bc@freeuk.com> writes:
> On 28/12/2017 16:11, David Brown wrote:
>> On 28/12/17 15:57, bartc wrote:
>> 2. It /does/ /not/ /matter/ what the generated C code looks like. You
>> can quite happily translate your "++a" into "INC_INT(a)" and have a
>> macro for it. Or you can translate it inline to "a = (uint32_t) a + 1".
>> Or whatever. It does not matter in the slightest. The need for
>> "pretty" generated C code is all in your head.
>
> I don't want to have to go to all that trouble.
That is why you fail.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-28 20:44 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p23hi3$s1a$1@dont-email.me> |
| In reply to | #124837 |
On 28/12/17 18:04, bartc wrote: > On 28/12/2017 16:11, David Brown wrote: >> On 28/12/17 15:57, bartc wrote: > >> 2. It /does/ /not/ /matter/ what the generated C code looks like. You >> can quite happily translate your "++a" into "INC_INT(a)" and have a >> macro for it. Or you can translate it inline to "a = (uint32_t) a + 1". >> Or whatever. It does not matter in the slightest. The need for >> "pretty" generated C code is all in your head. > > I don't want to have to go to all that trouble. > "All that trouble" ? You really are one impressive troll. I also note that you snipped the suggestion of a few lines to force gcc into -fwrapv -fno-strict-aliasing mode. Would that be too much trouble too? > If using C source as the target of a compiler turns out to be harder and > more fiddly than using ASM, then there is something wrong. > >> You live in your own bizarre little world of fear and hatred of a >> programming language, with your own personal ideas of what it should be >> and how it should be used. How can you be so blinkered? > > My posts in the subthread started after reading this: > > James Kuyper: > > A key point to consider is that the behavior of a+b is undefined if it > > results in overflow. That means that the C standard imposes no > > requirements on the behavior of your program. Among an infinite number > > of other possibilities: > > Followed by a complicated list of the said possibilities that I'm not > interested in having to keep in mind. You don't have to keep any of them in mind. Just don't overflow your integers. > > How about this possibility: > > 0. Just do the a+b addition even if it overflows. A compiler can do that too. gcc does, if you ask it. > > That's a lot easier to remember, and will not affect well-written code > that will not have overflow. > > I suggest a poll at this point to see who would be in favour of James' > possibilities 1. to 5., and who would prefer my possibility 0. I don't want any particular answer here - I want the compiler to assume it doesn't happen and optimise accordingly. Ideally, I also want the compiler to tell me if it knows UB is definitely going to occur. So your poll is already pointless. > >> Most people probably don't care, because overflow is rare >> in the real world - they don't give a *beep* what happens when >> incrementing a value beyond 2 billion because their code does not do >> that. > > I don't usually care about it either. But in C I /have/ to care about it > because apparently anything like this in a program is the equivalent of > red Kryptonite to Superman - anything could happen including a lot of > weird stuff. You don't have to care what happens when there is undefined behaviour in your code - you have to care that you don't rely on undefined behaviour. There's a difference. > > (In my byte-code interpreter, overflows of 64-bit integer arithmetic are > not checked. Possibilities included reporting as an error (possibly > trapped via an exception mechanism), or to represent the result as a > big-integer value. > > I chose not to check because it is simpler, more efficient, and more > predictable (if I wanted to type-infer the result of A+B for example, if > I already knew the types of A and B). > > Also, because sometimes the interpreter code has to be represented as C > source, that doesn't make it easy or efficient to do overflow checking. > That any 64-bit signed int operation - on operands which come from the > user-program being executed so I've no idea what they are - could result > in UB in the C code is an extra headache. Or an extra bonus according to > most opinions here.) > >> Other than that, I can't make any serious judgement from a snippet like >> that. > > I'm not asking for judgement. It's just very ordinary, workmanlike code > to get stuff done without any fuss. > > The fuss starts however when it goes through C. No, the fuss starts when /you/ try to generate C code without knowing what you are doing and what C code means. So you write half-done code and then get your knickers in a twist when either a compiler or a competent C programmer points out your error. > >> It is just code in a structured, statically typed procedural >> language. The syntax details are not particularly exciting here - it >> does not stand out from a dozen or more existing languages. > > The key thing is that the language doesn't say that signed int overflow > results in undefined behaviour. Another thing about it is that > implementations will usually do what the code says. > > Both these promises are undermined when it is necessary to go via C > source code. > Only if you don't understand C - or rather, only if you refuse to learn C.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-28 20:13 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <Yfc1C.278683$gi3.167776@fx19.am4> |
| In reply to | #124856 |
On 28/12/2017 19:44, David Brown wrote: > On 28/12/17 18:04, bartc wrote: >> I don't want to have to go to all that trouble. >> > > "All that trouble" ? You really are one impressive troll. Rewriting a code generator to pamper to a language (specifically, one compiler) /is/ a lot of trouble. Especially when it renders the output unreadable. I understand that to you, nothing is ever to much trouble. But we're not all whizzkids. > I also note that you snipped the suggestion of a few lines to force gcc > into -fwrapv -fno-strict-aliasing mode. Would that be too much trouble > too? Seriously, I don't understand gcc options; they're a minefield. But I also want to generate C that is not dependent on any one compiler, and want to avoid adding things which are only specific to gcc. The question we should be asking is why is it always gcc that is the problem? > You don't have to care what happens when there is undefined behaviour in > your code - you have to care that you don't rely on undefined behaviour. > There's a difference. What I want is that if I get an unexpected arithmetic overflow in my code, of whatever kind, then I get a wrong result in a calculation. That's all. And sometimes it will be expected. No other consequences to consider other than what my code will subsequently do with such wrong values. But that is entirely up to me and my program; I don't want to have to peruse a C language reference or a half a dozen compiler manuals for each of my C compilers to find out what /could/ happen. That doesn't preclude some tools from being able to trap such conditions for debugging purposes. > No, the fuss starts when /you/ try to generate C code without knowing > what you are doing and what C code means. When I generate intermediate code, it's because I need a low-level, ubiquitous language that will let me represent my programs in a mainstream language, that can be used to bootstrap them on machine that lacks a compiler for my language, that can be compiled for a range of platforms I don't support, or that can make use of the more advanced code generators of some compilers. I also need an intermediate language that doesn't get in the way and lets me do my job painlessly. Unfortunately such a language doesn't exist. The nearest that will fit the bill is C. But C comes with a whole bunch of problems that I don't want to have to deal with. I believe I may have mentioned one or two of them. >> Both these promises are undermined when it is necessary to go via C >> source code. >> > > Only if you don't understand C - or rather, only if you refuse to learn C. I understand all right. C is perfect. It should not be changed. Every decision that was ever taken, including refusing to recognised signed overflow, was absolutely the right one. Everyone here will defend such decisions no matter what. Except... if it was the other way around and C had defined signed overflow, and unsigned overflow was undefined, then everyone would be defending that instead! Has no one got any actual opinions of their own? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-28 12:48 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <97480eed-fcf3-49aa-92ad-06cb157a2ccf@googlegroups.com> |
| In reply to | #124859 |
On Thursday, December 28, 2017 at 2:13:59 PM UTC-6, Bart wrote: > Except... if it was the other way around and C had defined signed > overflow, and unsigned overflow was undefined, then everyone would be > defending that instead! System programming is excessively difficult and painful in the absence of a type which behaves as an algebraic of integers congruent mod 2**(word size), as well as similar types for each addressable chunk smaller than a word. Having an unsigned type which meets that criterion is nicer than having only a signed types that do so, but working around the lack of an unsigned type is not difficult *if signed types behave as members of the aforementioned algebraic ring*. Note that having unsigned types may be useful not only for cases where the algebraic-ring behavior is needed, but also for cases where numbers may be slightly too big for a signed object of a given size. This happened a lot in the days of 16-bit integers, but happens less often nowadays. C treats unsigned types smaller than "int" as numbers, while it those which are at least as big as "int" are treated as members of the aforementioned ring. Having different types for unsigned numbers vs. members of the algebraic rings, with the rule that operations on unsigned *numbers* that could yield negative values will promote values to the next larger signed type, would have alleviated the need for promotion rules that are dependent upon the size of "int".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-29 11:03 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p253su$cif$1@dont-email.me> |
| In reply to | #124861 |
On 28/12/17 21:48, supercat@casperkitty.com wrote: > On Thursday, December 28, 2017 at 2:13:59 PM UTC-6, Bart wrote: >> Except... if it was the other way around and C had defined signed >> overflow, and unsigned overflow was undefined, then everyone would be >> defending that instead! > > System programming is excessively difficult and painful in the absence of > a type which behaves as an algebraic of integers congruent mod 2**(word > size), as well as similar types for each addressable chunk smaller than a > word. No, it is not. Wrapping is occasionally useful, but only occasionally - and it would not be hard to live without it if necessary. > Having an unsigned type which meets that criterion is nicer than > having only a signed types that do so, but working around the lack of > an unsigned type is not difficult *if signed types behave as members of > the aforementioned algebraic ring*. If signed types had wraparound but unsigned did not, then signed types would be used when wraparound is useful. No surprise there. > > Note that having unsigned types may be useful not only for cases where the > algebraic-ring behavior is needed, but also for cases where numbers may be > slightly too big for a signed object of a given size. This happened a lot > in the days of 16-bit integers, but happens less often nowadays. C treats > unsigned types smaller than "int" as numbers, while it those which are at > least as big as "int" are treated as members of the aforementioned ring. It happens all the time in embedded programming and systems programming. Unsigned types are a better fit for "data", signed types are usually a better fit for numbers (except with the extra bit of positive range is helpful). > > Having different types for unsigned numbers vs. members of the algebraic > rings, with the rule that operations on unsigned *numbers* that could yield > negative values will promote values to the next larger signed type, would > have alleviated the need for promotion rules that are dependent upon the > size of "int". > The promotion rules in C are, IMHO, not ideal.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-28 13:08 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <lnr2red0gk.fsf@kst-u.example.com> |
| In reply to | #124859 |
bartc <bc@freeuk.com> writes:
[...]
> I understand all right. C is perfect. It should not be changed. Every
> decision that was ever taken, including refusing to recognised signed
> overflow, was absolutely the right one. Everyone here will defend such
> decisions no matter what.
Literally nobody said that. Whom are you talking to?
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-12-29 11:17 +1300 |
| Subject | Re: UB in asm |
| Message-ID | <fal8raFdlufU1@mid.individual.net> |
| In reply to | #124862 |
On 12/29/2017 10:08 AM, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > [...] >> I understand all right. C is perfect. It should not be changed. Every >> decision that was ever taken, including refusing to recognised signed >> overflow, was absolutely the right one. Everyone here will defend such >> decisions no matter what. > > Literally nobody said that. Whom are you talking to? Anyone who will rise to the bait... -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-28 22:54 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <gCe1C.109797$QL6.24137@fx20.am4> |
| In reply to | #124867 |
On 28/12/2017 22:17, Ian Collins wrote: > On 12/29/2017 10:08 AM, Keith Thompson wrote: >> bartc <bc@freeuk.com> writes: >> [...] >>> I understand all right. C is perfect. It should not be changed. Every >>> decision that was ever taken, including refusing to recognised signed >>> overflow, was absolutely the right one. Everyone here will defend such >>> decisions no matter what. >> >> Literally nobody said that. Whom are you talking to? (I was replying to David Brown and referring to people in the thread defending signed overflow being UB, defending UB in general, and defending certain compilers which just have to do things differently enough that they need special handling.) > Anyone who will rise to the bait... You mean, as happens when people are constantly on about how much better C++ is than C?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-29 11:07 +0100 |
| Subject | Re: UB in asm |
| Message-ID | <p2545e$e3u$1@dont-email.me> |
| In reply to | #124868 |
On 28/12/17 23:54, bartc wrote: > On 28/12/2017 22:17, Ian Collins wrote: >> On 12/29/2017 10:08 AM, Keith Thompson wrote: >>> bartc <bc@freeuk.com> writes: >>> [...] >>>> I understand all right. C is perfect. It should not be changed. Every >>>> decision that was ever taken, including refusing to recognised signed >>>> overflow, was absolutely the right one. Everyone here will defend such >>>> decisions no matter what. >>> >>> Literally nobody said that. Whom are you talking to? > > (I was replying to David Brown and referring to people in the thread > defending signed overflow being UB, defending UB in general, and > defending certain compilers which just have to do things differently > enough that they need special handling.) > I certainly did not express anything like the opinion you attribute to me. I think that having undefined behaviour for signed overflow is a good thing - but that is far from saying I agree with all the design decisions of C. And I don't speak for everyone here. I can't even claim to always speak consistently for myself (I change my mind sometimes). >> Anyone who will rise to the bait... > > You mean, as happens when people are constantly on about how much better > C++ is than C? > > > >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-28 15:46 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <lnefnect69.fsf@kst-u.example.com> |
| In reply to | #124867 |
Ian Collins <ian-news@hotmail.com> writes:
> On 12/29/2017 10:08 AM, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>> [...]
>>> I understand all right. C is perfect. It should not be changed. Every
>>> decision that was ever taken, including refusing to recognised signed
>>> overflow, was absolutely the right one. Everyone here will defend such
>>> decisions no matter what.
>>
>> Literally nobody said that. Whom are you talking to?
>
> Anyone who will rise to the bait...
Touché.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2017-12-28 17:00 -0500 |
| Subject | Re: UB in asm |
| Message-ID | <tQd1C.27617$BH4.15758@fx02.iad> |
| In reply to | #124859 |
On 12/28/17 3:13 PM, bartc wrote: > On 28/12/2017 19:44, David Brown wrote: >> On 28/12/17 18:04, bartc wrote: > > >> I don't want to have to go to all that trouble. > >> > > > > "All that trouble" ? You really are one impressive troll. > > Rewriting a code generator to pamper to a language (specifically, one > compiler) /is/ a lot of trouble. Especially when it renders the output > unreadable. > > I understand that to you, nothing is ever to much trouble. But we're not > all whizzkids. > > > I also note that you snipped the suggestion of a few lines to force gcc > > into -fwrapv -fno-strict-aliasing mode. Would that be too much trouble > > too? > > Seriously, I don't understand gcc options; they're a minefield. > > But I also want to generate C that is not dependent on any one compiler, > and want to avoid adding things which are only specific to gcc. The > question we should be asking is why is it always gcc that is the problem? > If you went directly to assembler, you would be dependent on a particular assembler AND a particular processor. In some ways that is a MUCH bigger mine field than looking at and supporting a few main compilers. First, if you generated your code to meet the requirements of the C assumed ideal machine, then your only requirements on C compilers would be that they need to be invoked in a (at least mostly) conforming mode. This of course means you have to limit your code to not producing signed overflows (or be willing to accept what the compiler does in those cases). Second, if you insist on violating the limitations of the ideal machine, you would need to see what options you need to provide to the various C implementations you want to support that support such violations. You also need to accept that you can't just expect to work with any arbitrary implementation with arbitrary options, that would be akin to expecting your assembly code designed for a x86 processor to run on an ARM processor (or a 6502). >> You don't have to care what happens when there is undefined behaviour >> in your code - you have to care that you don't rely on undefined >> behaviour. There's a difference. > > What I want is that if I get an unexpected arithmetic overflow in my > code, of whatever kind, then I get a wrong result in a calculation. > That's all. And sometimes it will be expected. > > No other consequences to consider other than what my code will > subsequently do with such wrong values. But that is entirely up to me > and my program; I don't want to have to peruse a C language reference or > a half a dozen compiler manuals for each of my C compilers to find out > what /could/ happen. > > That doesn't preclude some tools from being able to trap such conditions > for debugging purposes. > >> No, the fuss starts when /you/ try to generate C code without knowing >> what you are doing and what C code means. > > When I generate intermediate code, it's because I need a low-level, > ubiquitous language that will let me represent my programs in a > mainstream language, that can be used to bootstrap them on machine that > lacks a compiler for my language, that can be compiled for a range of > platforms I don't support, or that can make use of the more advanced > code generators of some compilers. > > I also need an intermediate language that doesn't get in the way and > lets me do my job painlessly. > > Unfortunately such a language doesn't exist. The nearest that will fit > the bill is C. > > But C comes with a whole bunch of problems that I don't want to have to > deal with. I believe I may have mentioned one or two of them. > >>> Both these promises are undermined when it is necessary to go via C >>> source code. >>> >> >> Only if you don't understand C - or rather, only if you refuse to >> learn C. > > I understand all right. C is perfect. It should not be changed. Every > decision that was ever taken, including refusing to recognised signed > overflow, was absolutely the right one. Everyone here will defend such > decisions no matter what. > > Except... if it was the other way around and C had defined signed > overflow, and unsigned overflow was undefined, then everyone would be > defending that instead! > > Has no one got any actual opinions of their own? > There are strong historical reasons for why C developed the way it did. Signed arithmetic has a number of cases where because there was no agreement on how machines did signed arithmetic (2's complement, 1's complement, and sign-magnatude being 3 major camps), the results were left undefined. Perhaps they could have chosen a description that gave a bit more of a guarantee, but they didn't, and there hasn't been enough issues brought up about it to make them tighten the spec. Unsigned arithmetic didn't have the same issue with representation, and the major cases that couldn't handle the rules for unsigned overflow (like decimal machines) had serious issues with other parts of the language. C is not a 'perfect' language, no language is. But C IS a good language for many things, IF you are willing to learn it. Complaining that C doesn't exactly fit what you want doesn't really help. People have tried to help you see the various ways YOU could deal with the issues you are having, but it seems you don't want to deal with it, all you really seem to want to do is complain. If you really don't want to have to learn C, then I would suggest direct generation of object code or Assembly, but then you need to choose a target processor (and assembler) and learn enough of it to generate good code. What you will lose if you do this is: 1) The ability to target multiple different processors, 2) Likely lose a lot of optimizations of your code (if you think it is too much work to try to understand the basic options of a few compilers, learning to details of code optimization of even one modern processor may well be beyond your work tolerance) 3) The C library to abstract a lot of OS differences into a common API.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-28 23:39 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <Tgf1C.122777$NO7.14334@fx43.am4> |
| In reply to | #124865 |
On 28/12/2017 22:00, Richard Damon wrote: > On 12/28/17 3:13 PM, bartc wrote: > If you went directly to assembler, you would be dependent on a > particular assembler AND a particular processor. In some ways that is a > MUCH bigger mine field than looking at and supporting a few main compilers. For about 30 years up to around 2012 I did only generate native code and only supported certain processors. It can work. Despite my comments, generating C would actually work provided I ignored people's comments about warnings, and stayed away from optimised gcc if there was trouble. (It means that gcc's code wouldn't be any better than mine, but it will at least cover those other platforms if needed.) > First, if you generated your code to meet the requirements of the C > assumed ideal machine, then your only requirements on C compilers would > be that they need to be invoked in a (at least mostly) conforming mode. > This of course means you have to limit your code to not producing signed > overflows (or be willing to accept what the compiler does in those cases). There are other factors that might be more significant. For example, I do mixed arithmetic using signed, C does it using unsigned, but I haven't bothered doing anything about that. So far however I haven't encountered problems. > There are strong historical reasons for why C developed the way it did. > Signed arithmetic has a number of cases where because there was no > agreement on how machines did signed arithmetic (2's complement, 1's > complement, and sign-magnatude being 3 major camps), the results were > left undefined. Perhaps they could have chosen a description that gave a > bit more of a guarantee, but they didn't, and there hasn't been enough > issues brought up about it to make them tighten the spec. Implementation defined would have been a better choice. > C is not a 'perfect' language, no language is. But C IS a good language > for many things, IF you are willing to learn it. Complaining that C > doesn't exactly fit what you want doesn't really help. People have tried > to help you see the various ways YOU could deal with the issues you are > having, but it seems you don't want to deal with it, all you really seem > to want to do is complain. I complained about the fact that this decision on signed overflow made things much more complicated (see James Kuyper's four points), in a way I didn't like. The debate went on a long time because people persistently disagreed with that. Can /no one/ see the benefits of keeping something simple, or /not/ having to learn complicated rules? I think people like their C to be complicated (even if it's just to be able to tell others they don't understand it!). (Decades of having to create and maintain my own tools have taught me the benefits of being small and being simple. It was essential.) > If you really don't want to have to learn C, then I would suggest direct > generation of object code or Assembly, but then you need to choose a > target processor (and assembler) and learn enough of it to generate good > code. What you will lose if you do this is: > 1) The ability to target multiple different processors, Yes, this is the main problem. But there aren't actually that many I need. Sticking to 32 bits, only two targets needed to be supported (x86 and ARM as they're in the machines I can buy). But I chose x64 as one because it was simpler and supposedly faster (it's a little slower actually). > 2) Likely lose a lot of optimizations of your code (if you think it is > too much work to try to understand the basic options of a few compilers, > learning to details of code optimization of even one modern processor > may well be beyond your work tolerance) For the sort of apps I do, the difference between gcc and my own code is not that significant. Mine might be 20-50% slower. For my interpreter, using my language allows me to add acceleration much more easily (ie. an ASM overlay). Then it can work at double the speed of using gcc with 100% C. With programs that call external functions a lot (graphics, files, etc) there is no practical difference. I can use Tiny C actually and I wouldn't notice much difference from gcc-O3. Smaller, nippier compilers are under-estimated. > 3) The C library to abstract a lot of OS differences into a common API. I can use the C library apart from a few tricky bits. The C interface, together with horrendous-looking, sprawling system headers can make it hard work however (remember that palaver about tracking down the meaning of clock_t?). Now, complaints about endless typedefs, nested macros and #ifdefs everywhere are fully justified. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-28 16:05 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <21513b1e-a0dd-4a51-b05a-98477e60bc54@googlegroups.com> |
| In reply to | #124872 |
On Thursday, December 28, 2017 at 5:39:45 PM UTC-6, Bart wrote: > I complained about the fact that this decision on signed overflow made > things much more complicated (see James Kuyper's four points), in a way > I didn't like. > > The debate went on a long time because people persistently disagreed > with that. Can /no one/ see the benefits of keeping something simple, or > /not/ having to learn complicated rules? Significant optimizations may be possible if one allows the results of overflowed computations to behave in a non-deterministic fashion which is not totally predictable (as would be implied by "Implementation Defined" behavior) but doesn't totally jump the rails either. Likewise in cases involving conflicting unsequenced operations on the same object. It is simpler to leave behavior undefined and figure that implementations that can cheaply offer useful guarantees (e.g. integer multiplication will have no side-effects beyond yielding some kind of value) will do so, than to characterize all aspects of behavior that should or should not be guaranteed. Better than saying that overflow is Implementation-Defined would be to say that it must either yield some kind of value (which might behave non- deterministically), or else trap in an Implementation-Defined fashion. If the act of casting non-deterministic value were required to yield a value chosen from among those possible in the destination type, that would allow programs to stay on the rails while still allowing compilers to employ some useful optimizations that wouldn't be possible if programmers had to code defensively against overflow.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-12-28 15:55 -0800 |
| Subject | Re: UB in asm |
| Message-ID | <5007798a-0775-4240-a40c-918465c0ee22@googlegroups.com> |
| In reply to | #124859 |
On Thursday, December 28, 2017 at 8:13:59 PM UTC, Bart wrote: > > I understand all right. C is perfect. It should not be changed. Every > decision that was ever taken, including refusing to recognised signed > overflow, was absolutely the right one. Everyone here will defend such > decisions no matter what. > > Except... if it was the other way around and C had defined signed > overflow, and unsigned overflow was undefined, then everyone would be > defending that instead! > > Has no one got any actual opinions of their own? > 1 -2 will overflow if the types are unsigned. signed arithmetic will only overflow if the values are very high in relation to the range.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2017-12-29 07:49 +0000 |
| Subject | Re: UB in asm |
| Message-ID | <beBfYArit4KiClFMuFgl4K4diEpqH@bongo-ra.co> |
| In reply to | #124874 |
On Thu, 28 Dec 2017 15:55:17 -0800 (PST) Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > 1 -2 will overflow if the types are unsigned. No , it will wrap around ; unsigned arithmetic doesn't oveflow in C. Now of course I'm guessing that by "overflow" you mean that the mathematically correct result doesn't fit in the object. But this isn't how the standard uses the term. In the C standard "overflow" means that the mathematically correct result doesn't fit in the object (or cannot be represented in the type) *and* this happens in a context where it's undefined behaviour. With unsigned integers it's never undefined behaviour. > signed arithmetic will > only overflow if the values are very high in relation to the range. Or very low. -- "A great disturbance in the internets. It was like a million hentai lovers voices crying out in unison, then suddenly silenced." "automatedresponse" www.reddit.com/r/promos/comments/6mtzb/time_warner_cable_to_block_all_usenet_access
[toc] | [prev] | [next] | [standalone]
Page 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web