Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #124638 > unrolled thread

Re: What every compiler writer should know about programmersWhat every compiler writer should know about programmers

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.

Contents

  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 2 of 13 — ← Prev page 1 [2] 3 4 … 13  Next page →

#125095 — Re: UB in asm

James Kuyper <jameskuyper@verizon.net> writes:
>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.

It's not uncommon for multithreaded JITs.   Given that the ARMv8
architecture doesn't require the L1I cache to snoop memory writes,
it's wise to flush the instruction cache(s) when self-modifying
code.   Although it is generally wiser not to self-modify code
(JITs notwithstanding).

[toc] | [prev] | [next] | [standalone]

#125096 — Re: UB in asm

On Thursday, January 4, 2018 at 5:39:09 AM UTC-6, a...@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.

UB is worse.  On an embedded system which is physically incapable of
running code from anything other than a non-writable code store, an
event which is limited to simultaneously corrupting every bit of memory
and registers in the most vexatious way possible would not be able to
wreak the same havoc that UB can wreak on a "modern" compiler.

For example, given:

    disarm_missiles();
    if (should_launch_missiles())
    {
      arm_missiles();
      if (should_launch_missiles())
        launch_missiles();
    }
    disarm_missiles();
    -1 << 1;

a compiler that sees that calls to should_launch_missiles() and
disarm_missiles() will always return, but that a call to launch_missiles()
might not, could rewrite the code "more efficiently" as:

    should_launch_missiles();
    arm_missiles();
    should_launch_missiles();
    launch_missiles();

In the original, one could rig external hardware so that there would be
no way for a single corrupting event--no matter how severe--to both arm
and launch the missiles.  If the only piece of code that could generate
the stimuli necessary to arm the missiles was between the two calls to
should_launch_missiles, then either the corruption event would put code
execution in a place that would call should_launch_missiles() before it
launches them, and would disarm the missiles if they weren't supposed to
launch, or it would put it in a place that would call launch_missiles
without having harmed them [which external hardware could then trap].
Modern "optimizations", however, can bypass such safety mechanisms.

[toc] | [prev] | [next] | [standalone]

#125094 — Re: UB in asm

On Thursday, January 4, 2018 at 4:19:54 AM UTC-6, James Kuyper 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). In most cases, probably all,
> there are severe restrictions on what happens when you misuse an
> instruction.

On the 6502, a number of encodings would cause the sequencing logic to fall
off the rails in a way that could only be recovered by hard reset.  Further,
some opcodes would operate on addresses computed in "interesting" fashion.
For example, opcode 0x8D is followed by two bytes (which I'll call L and H)
and stores the accumulator to (H*256+L); opcode 0x8C does likewise, but
stores the Y register rather than the accumulator.  Opcode 0x9D stores the
accumulator to address (H*256+L+X).  Operator 0x9C almost gates the proper
circuitry to store the Y register to (H*256+L+X), which would in fact be a
useful thing to do, but it actually stores (H+1) & y to address (H*256+L+X)
in cases where L+X <= 255, but to address ((H+1) & y)*256+((L+X) & 255) when
L+X >= 256.

[toc] | [prev] | [next] | [standalone]

#125093 — Re: UB in asm

On 1/2/18 12:26 PM, Keith Thompson wrote:
> 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?

For modern processors, which implement a user protection mode, I could 
agree, if in user mode you could execute an instruction that would 
perform 'UB', it would be a violation of the concept of protected mode.

It might not be an violation of the concept if it only was UB in the 
highest privileged level, but such behavior is unlikely to actually be 
the simplest way to impediment the processor.

On the old machines that had this sort of behavior, had no concept of 
'protection', the program running had full control over the machine, and 
instruction execution was often implemented by discrete logic, and to 
save logic, some unused codes might not have controlled behavior, 
Normally on a given revision of such a machine, these instructions had 
fairly after the fact predictable behavior (as digital hardware tends to 
act the same given the same initial conditions), there were cases where 
the logic might a metastable behavior). Sometimes a revision of the 
processor might change this behavior.

I believe the early 8086 had instructions like this (I know the 
predecessor 8080 did), and one thing that some people did was to try and 
figure out if any of these instructions did anything 'useful'. (Note, 
these processors did not have an illegal instruction trap, that came 
with later processors). I seem to remember that there were some 
'commercial' programs that actually used some of these instructions, and 
these programs broke when later processors used these instructions for 
new features.

[toc] | [prev] | [next] | [standalone]

#124658 — Re: UB in asm

On 12/24/2017 03:59 PM, Johannes Bauer wrote:
> 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.

UB is usually used as abbreviation for "undefined behavior".

The phrase "undefined result" is not used by the C standard, but that's
essentially what "indeterminate value" means. The key point is that an
indeterminate value is either an unspecified value or a trap
representation. There are several types prohibited from having trap
representations by the C standard, and for code that doesn't have to
portable, you can also rely upon implementation-specific guarantees that
a given type has no trap representations. When using such a type, you
know that an indeterminate result is "a valid value of the relevant
type". Subsequent code could be correctly written to handle all valid
values of the relevant type. Such a program can be far safer than one
that has undefined behavior.

[toc] | [prev] | [next] | [standalone]

#124660 — Re: UB in asm

On 24/12/2017 20:59, Johannes Bauer wrote:
> 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.

I usually generate ASM, don't write it. So I already have a program 
expressed in a simple higher level language.

It is perfectly reasonable to generate, instead of direct ASM, 
intermediate HLL in order to benefit from a better optimiser or for a 
platform not directly supported, or as a universal format for code 
distribution.

Then, you just want C as an way of expressing the same constructs as in 
the original language without dragging in all these extraneous issues 
with undefined behaviour or being conforming or non-conforming. There 
will be enough other obstacles (with the type system for example).

So, in the original language, I might cast a generic pointer to a 
function pointer, which I /know/ shouldn't be a problem in my platforms 
of interest (eg. x86 and ARM).

But in C, that's apparently illegal. (Why? Perhaps because on some 
obscure system that conversion doesn't work. But I don't care.)

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#124661 — Re: UB in asm

bartc <bc@freeuk.com> writes:
[...]
> It is perfectly reasonable to generate, instead of direct ASM, 
> intermediate HLL in order to benefit from a better optimiser or for a 
> platform not directly supported, or as a universal format for code 
> distribution.
>
> Then, you just want C as an way of expressing the same constructs as in 
> the original language without dragging in all these extraneous issues 
> with undefined behaviour or being conforming or non-conforming. There 
> will be enough other obstacles (with the type system for example).

Those aren't "extraneous issues".  They're part of the language.

But you knew that.

> So, in the original language, I might cast a generic pointer to a 
> function pointer, which I /know/ shouldn't be a problem in my platforms 
> of interest (eg. x86 and ARM).
>
> But in C, that's apparently illegal. (Why? Perhaps because on some 
> obscure system that conversion doesn't work. But I don't care.)

It's not "illegal".  The C standard doesn't even have a concept of
"illegal".  It has undefined behavior.

But you knew that.

-- 
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]

#124662 — Re: UB in asm

On 24/12/2017 22:50, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
> [...]
>> It is perfectly reasonable to generate, instead of direct ASM,
>> intermediate HLL in order to benefit from a better optimiser or for a
>> platform not directly supported, or as a universal format for code
>> distribution.
>>
>> Then, you just want C as an way of expressing the same constructs as in
>> the original language without dragging in all these extraneous issues
>> with undefined behaviour or being conforming or non-conforming. There
>> will be enough other obstacles (with the type system for example).
> 
> Those aren't "extraneous issues".  They're part of the language.
> 
> But you knew that.

For what many people are looking for in such a language, they are 
extraneous.

If I want a program to work on 1 platform out of 1000, I'm not 
interested in possible undefined behaviour on /one/ of the other 999 
machines, yet C, AIUI, will make it UB on /all/ machines.

Then those issues are extraneous and unwanted.

>> So, in the original language, I might cast a generic pointer to a
>> function pointer, which I /know/ shouldn't be a problem in my platforms
>> of interest (eg. x86 and ARM).
>>
>> But in C, that's apparently illegal. (Why? Perhaps because on some
>> obscure system that conversion doesn't work. But I don't care.)
> 
> It's not "illegal".  The C standard doesn't even have a concept of
> "illegal".

> But you knew that.

Actually I didn't. I've given up trying to figure out what is and isn't 
allowed in C.

As far as I can tell, it seems to be up to the programmer whether a 
program compiles or not, by mixing and matching compilers and options 
until they get the desired result.

If use gcc and tell it -pedantic-errors, then it says:

  error: ISO C forbids conversion of object pointer to function pointer
  type

If I can't compile and program, and it says something is forbidden, then 
it looks pretty illegal to me.

On the other hand, if I leave out that option (or use any other 
compiler), it says this:

   <nothing>

So now you're right, it isn't illegal!

In other words, a C programmer has to make this stuff up as they go along.

But what would you tell a beginner regarding the general validity of 
converting void* to function pointers? I wouldn't have a clue how to 
advise anyone because the language does a lousy job of it, while 
compilers will just do what you tell them.


-- 
bartc

[toc] | [prev] | [next] | [standalone]

#124663 — Re: UB in asm

bartc <bc@freeuk.com> writes:
> On 24/12/2017 22:50, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
[...]
>>> So, in the original language, I might cast a generic pointer to a
>>> function pointer, which I /know/ shouldn't be a problem in my platforms
>>> of interest (eg. x86 and ARM).
>>>
>>> But in C, that's apparently illegal. (Why? Perhaps because on some
>>> obscure system that conversion doesn't work. But I don't care.)
>> 
>> It's not "illegal".  The C standard doesn't even have a concept of
>> "illegal".
>
>> But you knew that.
>
> Actually I didn't. I've given up trying to figure out what is and isn't 
> allowed in C.

Search for the word "illegal" in n1570.pdf.  You'll find a single
occurrence in a footnote discussing the SIGILL signal.

> As far as I can tell, it seems to be up to the programmer whether a 
> program compiles or not, by mixing and matching compilers and options 
> until they get the desired result.
>
> If use gcc and tell it -pedantic-errors, then it says:
>
>   error: ISO C forbids conversion of object pointer to function pointer
>   type

I believe that's a bug in gcc.  I don't see an existing bug report.
I'll submit one.  (clang doesn't report an error with the same options.)

As a basis for any further discussion here's the test program I used:

int main(void) {
    typedef void (func)(void);
    void *ptr = 0;
    func *fptr = (func*)ptr;
}

Converting an object pointer to a function pointer does not violate
any constraint or syntax rule.  It does have undefined behavior (by
omission, since there nothing in the standard defines the behavior).

A conforming compiler could recognize that undefined behavior is
inevitable and reject the program on that basis, but the error message
at least needs to be reworded.

> If I can't compile and program, and it says something is forbidden, then 
> it looks pretty illegal to me.
> 
> On the other hand, if I leave out that option (or use any other 
> compiler), it says this:
>
>    <nothing>
>
> So now you're right, it isn't illegal!

More of your usual obfuscation.

> In other words, a C programmer has to make this stuff up as they go along.

Nonsense.

> But what would you tell a beginner regarding the general validity of 
> converting void* to function pointers? I wouldn't have a clue how to 
> advise anyone because the language does a lousy job of it, while 
> compilers will just do what you tell them.

I'd tell them that it's not forbidden, but it has undefined behavior.
It should never be done in code that's intended to be portable.  It can
be done in more restricted code that's portable only to implementations
that support it.

See, for example, the POSIX dlsym() function, which relies on
conversions between void* and function pointers.

Your decision not to try to explain it is wise since you clearly
don't understand it yourself and are unwilling to learn.

-- 
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]

#124664 — Re: UB in asm

Keith Thompson <kst-u@mib.org> writes:
> bartc <bc@freeuk.com> writes:
[...]
>> If use gcc and tell it -pedantic-errors, then it says:
>>
>>   error: ISO C forbids conversion of object pointer to function pointer
>>   type
>
> I believe that's a bug in gcc.  I don't see an existing bug report.
> I'll submit one.  (clang doesn't report an error with the same options.)
[...]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584

Title: "ISO C forbids conversion of object pointer to function
       pointer type" -- no, not really

-- 
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]

#124707 — Re: UB in asm

Keith Thompson <kst-u@mib.org> writes:

> Keith Thompson <kst-u@mib.org> writes:
>> bartc <bc@freeuk.com> writes:
> [...]
>>> If use gcc and tell it -pedantic-errors, then it says:
>>>
>>>   error: ISO C forbids conversion of object pointer to function pointer
>>>   type
>>
>> I believe that's a bug in gcc.  I don't see an existing bug report.
>> I'll submit one.  (clang doesn't report an error with the same options.)
> [...]
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
>
> Title: "ISO C forbids conversion of object pointer to function
>        pointer type" -- no, not really

The bug report was closed forthwith (on Christmas Day, no less) and has
now degenerated into a fatuous pissing contest as to whether
"<construct> is undefined" can be reported as "ISO C forbids
<construct>".

It appears that "an error message Keith doesn't like" is not a
permissible "Undefined Behaviour".

It is, in short, the most Keith Thompson conversation imaginable, and
utterly hilarious.

[toc] | [prev] | [next] | [standalone]

#124716 — Re: UB in asm

On Tuesday, December 26, 2017 at 12:03:49 PM UTC-6, gwowen wrote:
> It appears that "an error message Keith doesn't like" is not a
> permissible "Undefined Behaviour".

Setting aside the "One Program Rule" loophole, a conforming implementation
must correctly process programs that could invoke UB with some inputs, in
cases where the actual inputs receive do not invoke UB.

On the other hand, a conforming implementation is allowed to output any
diagnostics it likes when given any source text, provided that it then
proceeds to process such text in accordance with the Standard.

Consequently, I think the -pedantic-errors flag puts gcc into a non-conforming
mode.

I think, however, that even without such flags there are some cases where gcc
regards as fatal certain pieces of code which should only generate UB if
executed (such as assignments which involve incomplete structure types).  I
suspect that such constructs were classified as UB rather than constraint
violations to allow for the possibility of compilers which could handle
such assignments, as well as the possible existence of code that might rely
upon them.  Such code would not be portable to other platforms, but there
was no reason that compilers which could accept it should not be allowed
to keep doing so.

[toc] | [prev] | [next] | [standalone]

#124718 — Re: UB in asm

supercat@casperkitty.com writes:
[...]
> Setting aside the "One Program Rule" loophole, a conforming implementation
> must correctly process programs that could invoke UB with some inputs, in
> cases where the actual inputs receive do not invoke UB.
>
> On the other hand, a conforming implementation is allowed to output any
> diagnostics it likes when given any source text, provided that it then
> proceeds to process such text in accordance with the Standard.
>
> Consequently, I think the -pedantic-errors flag puts gcc into a non-conforming
> mode.
>
> I think, however, that even without such flags there are some cases where gcc
> regards as fatal certain pieces of code which should only generate UB if
> executed (such as assignments which involve incomplete structure types).  I
> suspect that such constructs were classified as UB rather than constraint
> violations to allow for the possibility of compilers which could handle
> such assignments, as well as the possible existence of code that might rely
> upon them.  Such code would not be portable to other platforms, but there
> was no reason that compilers which could accept it should not be allowed
> to keep doing so.

Are you referring to 6.3.2.1p2, "If the lvalue has an incomplete type
and does not have array type, the behavior is undefined."?  If so, I'm
having difficulty coming up with an example that could have meaningful
semantics.  Do you have one?

-- 
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]

#124754 — Re: UB in asm

On Tuesday, December 26, 2017 at 2:45:06 PM UTC-6, Keith Thompson wrote:
> Are you referring to 6.3.2.1p2, "If the lvalue has an incomplete type
> and does not have array type, the behavior is undefined."?  If so, I'm
> having difficulty coming up with an example that could have meaningful
> semantics.  Do you have one?

// Translation unit 1

  void test(struct foo *p1, struct foo *p2)
  {
    *p1 = *p2;
  }

// Translation unit 2a

  #include <stdio.h>
  struct foo { int x; };
  void test(struct foo *p1, struct foo *p2);
  int main(void)
  {
    struct foo s1,s2;
    s2.x = 5;
    test(&s1,&s2);
    printf("%d\n", s1.x);
  }

// Translation unit 2b

  #include <stdio.h>
  struct foo { int x, y};
  void test(struct foo *p1, struct foo *p2);
  int main(void)
  {
    struct foo s1,s2;
    s2.x = 5; s2.y = 6;
    test(&s1,&s2);
    printf("%d %d\n", s1.x, s1.y);
  }


If a compiler defines for every structure type a symbol which contains its
size, then it could process the first compilation unit as:

  #include <string.h>
  // The following would be defined as an address whose integer
  // representation matches the size fo struct foo

  extern __SIZE_OF_STRUCT_foo[]; 

  void test(struct foo *p1, struct foo *p2)
  {
    memcpy(p1, p2, (size_t)__SIZE_OF_STRUCT_FOO);
  }

No need for the compiler to have the complete type of "foo" in the former
translation unit, if a suitable linker symbol gets generated in the latter.

Of course, most implementations would not be able to provide such
semantics, but on those that can it may be useful to allow compilation
units to be capable of linking with multiple other compilation units
without recompilation.  Not saying that reliance upon such things would
be great design, but I think it's pretty clear what the semantics should
be on any platform that accepts such code without complaint.

[toc] | [prev] | [next] | [standalone]

#124760 — Re: UB in asm

supercat@casperkitty.com writes:
> On Tuesday, December 26, 2017 at 2:45:06 PM UTC-6, Keith Thompson wrote:
>> Are you referring to 6.3.2.1p2, "If the lvalue has an incomplete type
>> and does not have array type, the behavior is undefined."?  If so, I'm
>> having difficulty coming up with an example that could have meaningful
>> semantics.  Do you have one?
>
> // Translation unit 1
>
>   void test(struct foo *p1, struct foo *p2)
>   {
>     *p1 = *p2;
>   }
>
> // Translation unit 2a
>
>   #include <stdio.h>
>   struct foo { int x; };
>   void test(struct foo *p1, struct foo *p2);
>   int main(void)
>   {
>     struct foo s1,s2;
>     s2.x = 5;
>     test(&s1,&s2);
>     printf("%d\n", s1.x);
>   }
>
> // Translation unit 2b
>
>   #include <stdio.h>
>   struct foo { int x, y};
>   void test(struct foo *p1, struct foo *p2);
>   int main(void)
>   {
>     struct foo s1,s2;
>     s2.x = 5; s2.y = 6;
>     test(&s1,&s2);
>     printf("%d %d\n", s1.x, s1.y);
>   }
>
>
> If a compiler defines for every structure type a symbol which contains its
> size, then it could process the first compilation unit as:
[snip]
>   #include <string.h>
>   // The following would be defined as an address whose integer
>   // representation matches the size fo struct foo
>
>   extern __SIZE_OF_STRUCT_foo[]; 
>
>   void test(struct foo *p1, struct foo *p2)
>   {
>     memcpy(p1, p2, (size_t)__SIZE_OF_STRUCT_FOO);
>   }
>
> No need for the compiler to have the complete type of "foo" in the former
> translation unit, if a suitable linker symbol gets generated in the latter.
>
> Of course, most implementations would not be able to provide such
> semantics, but on those that can it may be useful to allow compilation
> units to be capable of linking with multiple other compilation units
> without recompilation.  Not saying that reliance upon such things would
> be great design, but I think it's pretty clear what the semantics should
> be on any platform that accepts such code without complaint.

I'm actually surprised that evaluating *p2, where p2 is a pointer to
an incomplete struct type, is not a constraint violation, and I'm
skeptical that an example like yours is the motivation for making
it UB rather than a constraint violation.  The C99 Rationale doesn't
address this.

I note that both gcc and clang reject the assignment with
    "error: dereferencing pointer to incomplete type 'struct foo'"
and
    "error: incomplete type 'struct foo' is not assignable"
respectively.  tcc doesn't complain, but the resulting programs die
with segmentation faults; tcc doesn't claim to be fully conforming

Anyone else: Why does 6.3.2.1p2 make lvalue conversion for an
lvalue of (non-array) incomplete type undefined behavior rather
a constraint violation?  Is there a realistic and useful example
that motivates allowing it?  I'm skeptical that supercat's example
is realistic.

-- 
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]

#124767 — Re: UB in asm

On Wednesday, December 27, 2017 at 11:15:21 AM UTC-6, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> > No need for the compiler to have the complete type of "foo" in the former
> > translation unit, if a suitable linker symbol gets generated in the latter.
> >
> > Of course, most implementations would not be able to provide such
> > semantics, but on those that can it may be useful to allow compilation
> > units to be capable of linking with multiple other compilation units
> > without recompilation.  Not saying that reliance upon such things would
> > be great design, but I think it's pretty clear what the semantics should
> > be on any platform that accepts such code without complaint.
> 
> I'm actually surprised that evaluating *p2, where p2 is a pointer to
> an incomplete struct type, is not a constraint violation, and I'm
> skeptical that an example like yours is the motivation for making
> it UB rather than a constraint violation.  The C99 Rationale doesn't
> address this.

I don't know if any compilers did in fact process programs in such fashion,
but on most platforms it would not be difficult for a compiler writer to
support such code if so inclined.

> I note that both gcc and clang reject the assignment with
>     "error: dereferencing pointer to incomplete type 'struct foo'"
> and
>     "error: incomplete type 'struct foo' is not assignable"
> respectively.  tcc doesn't complain, but the resulting programs die
> with segmentation faults; tcc doesn't claim to be fully conforming
> 
> Anyone else: Why does 6.3.2.1p2 make lvalue conversion for an
> lvalue of (non-array) incomplete type undefined behavior rather
> a constraint violation?  Is there a realistic and useful example
> that motivates allowing it?  I'm skeptical that supercat's example
> is realistic.

Compilers certainly could support such code if they wanted to, and I can
imagine cases where it might be useful for them to do so.  I doubt that
I would be inclined to implement a compiler in such fashion unless I knew
of code that needed it, but I can't think of any *other* reason for such
code to be UB but not a constraint violation.  Taking the address of an
lvalue with incomplete type should be well-defined, and I can't think of
anything *else* one could do with such an lvalue that shouldn't be either
well-defined or a constraint violation.  I'd regard my example as the
*least implausible* situation where there would be benefit to having such
a construct be neither well-defined nor a constraint violation, but I'll
fully admit that "least implausible" isn't saying much.

[toc] | [prev] | [next] | [standalone]

#124780 — Re: UB in asm

On 12/27/17 12:15 PM, Keith Thompson wrote:
> Anyone else: Why does 6.3.2.1p2 make lvalue conversion for an
> lvalue of (non-array) incomplete type undefined behavior rather
> a constraint violation?  Is there a realistic and useful example
> that motivates allowing it?  I'm skeptical that supercat's example
> is realistic.
> 

I don't know for certain, but could it have been bowing to the gcc 
extension where dereferencing a void pointer (and void is an incomplete 
type) acts as if it was a pointer to char (or is it unsigned char?).

[toc] | [prev] | [next] | [standalone]

#124782 — Re: UB in asm

Richard Damon <Richard@Damon-Family.org> writes:
> On 12/27/17 12:15 PM, Keith Thompson wrote:
>> Anyone else: Why does 6.3.2.1p2 make lvalue conversion for an
>> lvalue of (non-array) incomplete type undefined behavior rather
>> a constraint violation?  Is there a realistic and useful example
>> that motivates allowing it?  I'm skeptical that supercat's example
>> is realistic.
>
> I don't know for certain, but could it have been bowing to the gcc 
> extension where dereferencing a void pointer (and void is an incomplete 
> type) acts as if it was a pointer to char (or is it unsigned char?).

I'm not aware of any such extension.  gcc does have an extension that
permits pointer arithmetic on void* values (with sizeof (void) == 1),
but that doesn't involve dereferencing.

-- 
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]

#124772 — Re: UB in asm

supercat@casperkitty.com writes:

> On Tuesday, December 26, 2017 at 2:45:06 PM UTC-6, Keith Thompson wrote:
>
>> Are you referring to 6.3.2.1p2, "If the lvalue has an incomplete type
>> and does not have array type, the behavior is undefined."?  If so, I'm
>> having difficulty coming up with an example that could have meaningful
>> semantics.  Do you have one?
>
> // Translation unit 1
>
>   void test(struct foo *p1, struct foo *p2)
>   {
>     *p1 = *p2;
>   }

This TU has a constraint violation.

[toc] | [prev] | [next] | [standalone]

#124773 — Re: UB in asm

Tim Rentsch <txr@alumni.caltech.edu> writes:
> supercat@casperkitty.com writes:
>> On Tuesday, December 26, 2017 at 2:45:06 PM UTC-6, Keith Thompson wrote:
>>> Are you referring to 6.3.2.1p2, "If the lvalue has an incomplete type
>>> and does not have array type, the behavior is undefined."?  If so, I'm
>>> having difficulty coming up with an example that could have meaningful
>>> semantics.  Do you have one?
>>
>> // Translation unit 1
>>
>>   void test(struct foo *p1, struct foo *p2)
>>   {
>>     *p1 = *p2;
>>   }
>
> This TU has a constraint violation.

That certainly would have been my assumption, but my earlier attempt to
find one was unsuccessful.  What constraint does it violate?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

Page 2 of 13 — ← Prev page 1 [2] 3 4 … 13  Next page →

Back to top | Article view | comp.lang.c

csiph-web