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

Groups > comp.lang.c++ > #82003 > unrolled thread

I think references should have been const by default

Back to article view | Back to comp.lang.c++

Contents

  I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-21 05:23 +0000
    Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-21 08:54 +0200
      Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-21 09:48 +0000
        Re: I think references should have been const by default Paavo Helde <myfirstname@osa.pri.ee> - 2021-10-21 12:55 +0300
        Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-21 12:57 +0200
          Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-21 13:40 +0000
            Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-21 15:04 +0100
              Re: I think references should have been const by default Manfred <noname@add.invalid> - 2021-10-21 16:41 +0200
                Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-21 14:57 +0000
              Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-21 14:51 +0000
              Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-21 12:09 -0400
                Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-21 23:49 +0100
                  Re: I think references should have been const by default "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-10-21 16:21 -0700
                    Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-22 16:14 +0100
                      Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-22 12:04 -0700
                        Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-22 20:47 +0100
                          Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-22 13:29 -0700
                      Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-23 11:54 +0200
                        Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-23 11:22 +0100
                          Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-23 12:35 +0200
                        Re: I think references should have been const by default Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-23 13:23 +0100
                          Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-23 13:57 +0100
                            Re: I think references should have been const by default Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-23 21:02 +0100
                            Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-23 15:07 -0700
                              Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-23 21:15 -0700
                          Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-23 21:12 -0700
                Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-22 11:13 +0200
                  Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-22 19:18 -0400
              Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-22 04:41 +0000
                Re: I think references should have been const by default Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-10-23 21:30 +0100
                  Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-25 04:51 +0000
                    Re: I think references should have been const by default Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-10-26 00:53 +0100
              Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-22 09:46 +0200
                Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-22 15:48 +0100
                  Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-23 12:21 +0200
                    Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-23 12:06 +0100
                      Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-23 18:45 +0200
                        Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-23 18:58 +0100
                          Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-24 12:11 +0200
                            Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-24 23:11 +0100
                              Re: I think references should have been const by default Öö Tiib <ootiib@hot.ee> - 2021-10-24 16:18 -0700
                                Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-25 00:58 +0100
                        Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-25 08:21 +0000
                          Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-25 09:47 +0000
                            Re: I think references should have been const by default Bo Persson <bo@bo-persson.se> - 2021-10-25 12:33 +0200
                            Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-25 14:19 +0000
                              Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-25 10:59 -0400
                                Re: I think references should have been const by default Manfred <noname@add.invalid> - 2021-10-25 17:56 +0200
                                  Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-25 11:11 -0700
                                    Re: I think references should have been const by default Manfred <noname@add.invalid> - 2021-10-26 17:15 +0200
                                      Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 06:41 -0700
                                Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-25 16:14 +0000
                                  Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-25 13:14 -0400
                                    Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 08:18 +0000
                                      Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 12:39 +0100
                                        Re: I think references should have been const by default Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-26 14:29 +0100
                                          Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 15:11 +0100
                                            Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-26 09:49 -0700
                                              Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 18:38 +0100
                                                Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-26 11:20 -0700
                                                  Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 20:32 +0100
                                                    Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-26 22:18 +0200
                                              Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 04:43 +0000
                                                Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-27 08:29 +0200
                                                Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 06:32 -0700
                                                  Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-11-01 06:12 +0000
                                                    Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-11-01 08:53 +0100
                                                    Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-01 11:26 -0400
                                                      Re: I think references should have been const by default "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-11-02 16:19 +0100
                                                        Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-02 12:54 -0400
                                                        Re: I think references should have been const by default Paavo Helde <myfirstname@osa.pri.ee> - 2021-11-02 23:49 +0200
                                                          Re: I think references should have been const by default "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-11-03 00:38 +0100
                                        Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 14:36 +0000
                                          Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 15:55 +0100
                                            Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 15:26 +0000
                                              Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 20:35 +0100
                                              Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 04:44 +0000
                                          Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 11:27 -0400
                                      Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 10:31 -0400
                                        Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 14:42 +0000
                                          Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 11:22 -0400
                                            Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 15:30 +0000
                                              Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 12:23 -0400
                                                Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 12:51 -0400
                                                Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 14:34 -0400
                                                  Re: I think references should have been const by default "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-26 12:57 -0700
                                                Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-27 07:57 +0000
                                                  Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 08:47 +0000
                                                    Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-27 14:29 +0000
                                                      Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-28 05:17 +0000
                                                        Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-28 09:30 +0000
                                                          Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-29 04:47 +0000
                                                          Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-29 05:11 +0000
                                                            Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-29 08:40 +0000
                                                              Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-11-01 06:15 +0000
                                                  Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-27 11:07 +0200
                                                    Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-27 14:30 +0000
                                                      Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-27 17:30 +0200
                                                        Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-27 15:46 +0000
                                                        Re: I think references should have been const by default scott@slp53.sl.home (Scott Lurndal) - 2021-10-27 16:13 +0000
                                                      Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-27 11:39 -0400
                                                        Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-27 15:51 +0000
                                                          Re: I think references should have been const by default Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-27 17:21 +0100
                                                            Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-28 09:29 +0000
                                                              Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-28 11:20 +0100
                                                          Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-27 12:26 -0400
                                                            Re: I think references should have been const by default Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2021-10-31 09:22 -0700
                                                              Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-01 00:13 -0400
                                                          Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-28 05:20 +0000
                                                            Re: I think references should have been const by default "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-27 23:10 -0700
                                                            Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-28 09:30 +0000
                                                              Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-29 04:51 +0000
                                                                Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-29 08:39 +0000
                                                                  Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-11-01 06:34 +0000
                                                    Re: I think references should have been const by default Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-10-27 17:41 +0100
                                                      Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-27 19:02 +0200
                                                        Re: I think references should have been const by default Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-10-27 18:21 +0100
                                                  Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-27 11:38 -0400
                                                    Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-27 15:49 +0000
                                                      Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-27 12:36 -0400
                                              Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 04:57 +0000
                                  Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-25 18:19 +0100
                                  Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-25 10:48 -0700
                                    Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 08:21 +0000
                                      Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 08:37 +0000
                                        Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 09:02 +0000
                                          Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 11:14 +0000
                                            Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 14:35 +0000
                                              Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 05:01 +0000
                                            Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 06:34 -0700
                                          Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 10:43 -0400
                                            Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 15:21 +0000
                                              Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-26 22:32 +0200
                                              Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 05:04 +0000
                                      Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 10:42 -0400
                                        Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 14:48 +0000
                                          Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 11:52 -0400
                                          Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-26 10:22 -0700
                                            Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-26 10:27 -0700
                                              Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 14:06 -0400
                                            Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 06:45 -0700
                                              Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-29 11:11 -0700
                                                Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 07:39 -0700
                                                  Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-04-25 10:59 -0700
                                  Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 05:29 +0000
                                    Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-26 08:53 +0200
                                    Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 08:23 +0000
                                      Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 08:40 +0000
                                Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 05:18 +0000
                                  Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-26 09:07 +0200
                                  Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 11:03 -0400
                            Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-25 10:39 -0400
                              Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-25 10:56 -0700
                          Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-25 10:30 -0400
                            Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-25 14:39 +0000
                              Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-25 11:05 -0400
                          Re: I think references should have been const by default "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-25 12:45 -0700
                            Re: I think references should have been const by default "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-26 11:20 -0700
                  Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-25 05:00 +0000
                    Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-25 12:13 +0100
                      Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 05:36 +0000
                    Re: I think references should have been const by default Manfred <noname@add.invalid> - 2021-10-25 16:58 +0200
      Re: I think references should have been const by default "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-10-22 12:28 -0700
    Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-21 09:12 +0000
      Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-21 09:52 +0000
        Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-21 10:36 +0000
          Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-22 04:45 +0000
      Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-21 12:07 -0400
    Re: I think references should have been const by default Paavo Helde <myfirstname@osa.pri.ee> - 2021-10-21 12:18 +0300
    Re: I think references should have been const by default Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-21 13:13 +0200
      Re: I think references should have been const by default Bo Persson <bo@bo-persson.se> - 2021-10-21 15:08 +0200
      Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-22 04:45 +0000
        Re: I think references should have been const by default Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-22 07:55 +0200
          Re: I think references should have been const by default Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-22 11:21 +0000
    Re: I think references should have been const by default "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-10-21 13:22 +0200
      Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-22 04:48 +0000
    Re: I think references should have been const by default Manfred <noname@add.invalid> - 2021-10-21 13:57 +0200
    Re: I think references should have been const by default Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 21:27 +0000
    Re: I think references should have been const by default Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-10-24 14:20 +0000

Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9  Next page →

#82177

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> RacingRabbit@watershipdown.co.uk writes:
>
>> On Tue, 26 Oct 2021 10:42:24 -0400
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>
>>> On 10/26/21 4:21 AM, RacingRabbit@watershipdown.co.uk wrote:
>>>
>>>> On Mon, 25 Oct 2021 10:48:57 -0700
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>
>>>>> RacingRabbit@watershipdown.co.uk writes:
>>>>>
>>>>>> Any attempt to write to a read only program text area will
>>>>>> result in a crash regardless of the language.  It is implicit
>>>>>> that its read only in C because C also provides the following
>>>>>> initialisation which places the string (presumably) on the
>>>>>> heap:
>>>>>>
>>>>>> char str[] = "hello world";
>>>>>
>>>>> I suggest that you would benefit more here from asking questions
>>>>> than from making assertions.
>>>>
>>>> I suggest you ease up on being patronising.
>>>
>>> You'll get less patronizing responses when you cease displaying
>>> such an abysmal understanding of C, while believing you understand
>>> it better than others.
>>
>> Says the preening fool.
>
> James is not a "preening fool".  He's right.

To be fair, sometimes he is one, and sometimes the other.

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

#82180

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> RacingRabbit@watershipdown.co.uk writes:
>>> On Tue, 26 Oct 2021 10:42:24 -0400
>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>
>>>> On 10/26/21 4:21 AM, RacingRabbit@watershipdown.co.uk wrote:
>>>>
>>>>> On Mon, 25 Oct 2021 10:48:57 -0700
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>>
>>>>>> RacingRabbit@watershipdown.co.uk writes:
>>>>>>
>>>>>>> Any attempt to write to a read only program text area will
>>>>>>> result in a crash regardless of the language.  It is implicit
>>>>>>> that its read only in C because C also provides the following
>>>>>>> initialisation which places the string (presumably) on the
>>>>>>> heap:
>>>>>>>
>>>>>>> char str[] = "hello world";
>>>>>>
>>>>>> I suggest that you would benefit more here from asking questions
>>>>>> than from making assertions.
>>>>>
>>>>> I suggest you ease up on being patronising.
>>>>
>>>> You'll get less patronizing responses when you cease displaying
>>>> such an abysmal understanding of C, while believing you understand
>>>> it better than others.
>>>
>>> Says the preening fool.
>>
>> James is not a "preening fool".  He's right.
>
> To be fair, sometimes he is one, and sometimes the other.

To be fair, Tim, shut up.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#83726

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> RacingRabbit@watershipdown.co.uk writes:
>>>
>>>> On Tue, 26 Oct 2021 10:42:24 -0400
>>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>>
>>>>> On 10/26/21 4:21 AM, RacingRabbit@watershipdown.co.uk wrote:
>>>>>
>>>>>> On Mon, 25 Oct 2021 10:48:57 -0700
>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>>>
>>>>>>> RacingRabbit@watershipdown.co.uk writes:
>>>>>>>
>>>>>>>> Any attempt to write to a read only program text area will
>>>>>>>> result in a crash regardless of the language.  It is implicit
>>>>>>>> that its read only in C because C also provides the following
>>>>>>>> initialisation which places the string (presumably) on the
>>>>>>>> heap:
>>>>>>>>
>>>>>>>> char str[] = "hello world";
>>>>>>>
>>>>>>> I suggest that you would benefit more here from asking
>>>>>>> questions than from making assertions.
>>>>>>
>>>>>> I suggest you ease up on being patronising.
>>>>>
>>>>> You'll get less patronizing responses when you cease displaying
>>>>> such an abysmal understanding of C, while believing you
>>>>> understand it better than others.
>>>>
>>>> Says the preening fool.
>>>
>>> James is not a "preening fool".  He's right.
>>
>> To be fair, sometimes he is one, and sometimes the other.
>
> To be fair, Tim, shut up.

I don't know why you find my comment so objectionable.  I was
only reporting some observations of past events.  I think the
same statement applies, to a greater or lesser degree, to most
people who post here regularly and who present themselves as
speaking authoritatively.  It's no big deal.

Furthermore, on a number of occasions James has posted comments
about me, and not just about my writing but about my character.
(Note that my comment was only about his writing, not about
him personally, in case that was not evident.)  So if you're
going to be even handed, it seems like you should also tell
him to shut up.

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

#83748

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> RacingRabbit@watershipdown.co.uk writes:
>>>>> On Tue, 26 Oct 2021 10:42:24 -0400
>>>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
[...]
>>>>>> You'll get less patronizing responses when you cease displaying
>>>>>> such an abysmal understanding of C, while believing you
>>>>>> understand it better than others.
>>>>>
>>>>> Says the preening fool.
>>>>
>>>> James is not a "preening fool".  He's right.
>>>
>>> To be fair, sometimes he is one, and sometimes the other.
>>
>> To be fair, Tim, shut up.
>
> I don't know why you find my comment so objectionable.  I was
> only reporting some observations of past events.  I think the
> same statement applies, to a greater or lesser degree, to most
> people who post here regularly and who present themselves as
> speaking authoritatively.  It's no big deal.
> 
> Furthermore, on a number of occasions James has posted comments
> about me, and not just about my writing but about my character.
> (Note that my comment was only about his writing, not about
> him personally, in case that was not evident.)  So if you're
> going to be even handed, it seems like you should also tell
> him to shut up.

Do you *seriously* not see how that was offensive?

Re-reading the thread, I now see that it was not you who originally
called James a "preening fool".  It was another participant who chose to
insult James while James was making correct and reasonable points.  You
just decided to jump in and endorse the insult.  (I didn't remember the
details because it all happened 6 months ago.)

You did not comment on his writing.  It was a personal insult directed
at him, and it was entirely unconstructive.  If you *meant* to comment
on his writing, you could have done so; I believe your mastery of the
English language is sufficient to make the distinction.

James may or may not have posted comments about you; I don't recall.
If he has, it's entirely possible that I didn't call him out because
I didn't disagree.  If I see any such comments in the future,
I may or may not reply, but I feel no obligation to be even handed.

Don't expect me to reply further, especially if you wait another 6
months to post your next followup.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#82086

RacingRabbit@watershipdown.co.uk wrote:
> Any attempt to write to a read only program text area will result in a crash
> regardless of the language.

There's absolutely nothing requiring C (or C++) compilers to put string
literals in a read-only memory segment. They are free to put them in a
normal read/write memory segment if they so wish.

Nothing guarantees that the target architecture even *has* such a thing
as "read-only memory segments".

This means that your program may well work "correctly" in one target
architecture but not in another.

> It is implicit that its read only in C because
> C also provides the following initialisation which places the string 
> (presumably) on the heap:
> 
> char str[] = "hello world";

It cannot place it on the heap because that would just be a memory leak
(there would be nothing freeing it). It would allocate that array on
the stack, if it's inside a function (and if it's at the global scope,
whichever segment is dedicated to those).

And that string literal there, if it actually gets generated into the
final binary, will still be in read-only memory (if the architecture
supports such a thing). It's just that its contents are copied to the
array when the array is allocated on the stack.

(Btw, this is the reason why I say that C as "strings", rather than
strings. They are just char arrays, with a zero byte as an element
that by convention indicates the final character. This causes a
lot of confusion, especially since it induces many people to
think that a char* is a "string". Which it isn't. It's a pointer
to a value of type char. It *might* point to a null-terminated
char array, or it might not. It's not guaranteed that it's a
"string".)

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

#82088

On 26/10/2021 07:29, Juha Nieminen wrote:
> RacingRabbit@watershipdown.co.uk wrote:
>> Any attempt to write to a read only program text area will result in a crash
>> regardless of the language.
> 
> There's absolutely nothing requiring C (or C++) compilers to put string
> literals in a read-only memory segment. They are free to put them in a
> normal read/write memory segment if they so wish.
> 
> Nothing guarantees that the target architecture even *has* such a thing
> as "read-only memory segments".
> 
> This means that your program may well work "correctly" in one target
> architecture but not in another.

There is also nothing to guarantee that attempting to write to read-only
memory will result in a "crash".  It could result in nothing happening
at all (the write being ignored), or a hang, or a reset of the entire
system, or a write to somewhere different in memory.  (I've worked with
systems with all four such behaviours to at least some extent.)

A particular /OS/ might guarantee that attempting to write to read-only
memory segments results in a particular handling of the process, but it
is certainly not guaranteed by C or C++.

And of course, the C compiler might not actually attempt to make the
write, but act as though it had.  (I think that would be unlikely in
practice, but it could be done for strings local to a function.)

> 
>> It is implicit that its read only in C because
>> C also provides the following initialisation which places the string 
>> (presumably) on the heap:
>>
>> char str[] = "hello world";
> 
> It cannot place it on the heap because that would just be a memory leak
> (there would be nothing freeing it). It would allocate that array on
> the stack, if it's inside a function (and if it's at the global scope,
> whichever segment is dedicated to those).
> 

(Hypothetically, it /could/ be allocated on the heap, or elsewhere, if
the compiler also generated code to free it appropriately.  While almost
all C implementations use a stack for local data, there are a few
exceptions.)

> And that string literal there, if it actually gets generated into the
> final binary, will still be in read-only memory (if the architecture
> supports such a thing). It's just that its contents are copied to the
> array when the array is allocated on the stack.
> 
> (Btw, this is the reason why I say that C as "strings", rather than
> strings. They are just char arrays, with a zero byte as an element
> that by convention indicates the final character. This causes a
> lot of confusion, especially since it induces many people to
> think that a char* is a "string". Which it isn't. It's a pointer
> to a value of type char. It *might* point to a null-terminated
> char array, or it might not. It's not guaranteed that it's a
> "string".)
> 

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

#82092

On Tue, 26 Oct 2021 05:29:31 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>RacingRabbit@watershipdown.co.uk wrote:
>> It is implicit that its read only in C because
>> C also provides the following initialisation which places the string 
>> (presumably) on the heap:
>> 
>> char str[] = "hello world";
>
>It cannot place it on the heap because that would just be a memory leak
>(there would be nothing freeing it). It would allocate that array on

It wouldn't need to be free'd if it existed for the lifetime of the program.

>strings. They are just char arrays, with a zero byte as an element
>that by convention indicates the final character. This causes a

Wow, really? Who knew!

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

#82094

RacingRabbit@watershipdown.co.uk wrote:
>>strings. They are just char arrays, with a zero byte as an element
>>that by convention indicates the final character. This causes a
> 
> Wow, really? Who knew!

A lot of beginner C programmers don't.

And some not-so-beginner C programmers either. (Well, they do tend to know
about the trailing-zero-byte thing, but otherwise they may have a
surprisingly poor grasp of what a "string" in C actually is, and may
even think that a char* is a "string" (which it most definitely is not).)

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

#82085

James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> A lot of people have trouble understanding how breath-takingly wide the
> scope of "imposes no requirements" is. The standard tries to make that
> clear with the following examples "Possible undefined behavior ranges
> from ignoring the situation completely with unpredictable results, to
> behaving during translation or program execution in a documented manner
> characteristic of the environment (with or without the issuance of a
> diagnostic message), to terminating a translation or execution (with the
> issuance of a diagnostic message)."

No better example of "undefined behavior" causing a major problem than
that bug in the Linux kernel discovered some years ago, where the kernel
would deliberately dereference a null pointer (I don't remember anymore
for what reason), and gcc saw that it was a null pointer dereference,
which according to the C standard is undefined behavior, and since that
allows the compiler to do with it whatever it wants, it (if I remember
correctly) just optimized it away, causing the extraordinarily hard-to-find
bug in the kernel.

(Also, if I remember correctly, it caused quite a discussion about
whether compilers should actually be allowed to "do whatever they want"
with such code, or whether they should do as they are told.)

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

#82089

On 26/10/2021 07:18, Juha Nieminen wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> A lot of people have trouble understanding how breath-takingly wide the
>> scope of "imposes no requirements" is. The standard tries to make that
>> clear with the following examples "Possible undefined behavior ranges
>> from ignoring the situation completely with unpredictable results, to
>> behaving during translation or program execution in a documented manner
>> characteristic of the environment (with or without the issuance of a
>> diagnostic message), to terminating a translation or execution (with the
>> issuance of a diagnostic message)."
> 
> No better example of "undefined behavior" causing a major problem than
> that bug in the Linux kernel discovered some years ago, where the kernel
> would deliberately dereference a null pointer (I don't remember anymore
> for what reason), and gcc saw that it was a null pointer dereference,
> which according to the C standard is undefined behavior, and since that
> allows the compiler to do with it whatever it wants, it (if I remember
> correctly) just optimized it away, causing the extraordinarily hard-to-find
> bug in the kernel.
> 

The compiler did not cause a bug in the kernel.  There was a bug in the
source code - the programmer got the order of the code wrong, and
checked the pointer after using it.  This was a simple mistake in the
code, and should have been spotted by the reviewer - it was an
embarrasing failure in the development chain of the kernel.  (The review
and moderation process in the kernel development usually maintains very
high standards.)

The new optimisation in gcc did not /cause/ the bug, it merely changed
the /consequences/ of the bug.  The optimisation was entirely valid.

It is, however, also reasonable for a project like an OS kernel to
accept that there is a risk of human error leading to bugs in the code,
and want to reduce the consequences that might result from such bugs.

But we can learn from our mistakes - the kernel gained the feature of
having a memory page at address zero mapped with no access, so that any
later attempt to dereference a null pointer would be caught.  At that
point, -fdelete-null-pointer-checks can (and should) be re-enabled,
along with the warning "-Wnull-derefence" that was also added as a
consequence of this issue.

> (Also, if I remember correctly, it caused quite a discussion about
> whether compilers should actually be allowed to "do whatever they want"
> with such code, or whether they should do as they are told.)
> 

The compiler /did/ do as it was told.  It was not told to do what the
programmer wanted to tell it.

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

#82108

On 10/26/21 1:18 AM, Juha Nieminen wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> A lot of people have trouble understanding how breath-takingly wide the
>> scope of "imposes no requirements" is. The standard tries to make that
>> clear with the following examples "Possible undefined behavior ranges
>> from ignoring the situation completely with unpredictable results, to
>> behaving during translation or program execution in a documented manner
>> characteristic of the environment (with or without the issuance of a
>> diagnostic message), to terminating a translation or execution (with the
>> issuance of a diagnostic message)."
> 
> No better example of "undefined behavior" causing a major problem than
> that bug in the Linux kernel discovered some years ago, where the kernel
> would deliberately dereference a null pointer (I don't remember anymore
> for what reason), and gcc saw that it was a null pointer dereference,
> which according to the C standard is undefined behavior, and since that
> allows the compiler to do with it whatever it wants, it (if I remember
> correctly) just optimized it away, causing the extraordinarily hard-to-find
> bug in the kernel.
> 
> (Also, if I remember correctly, it caused quite a discussion about
> whether compilers should actually be allowed to "do whatever they want"
> with such code, or whether they should do as they are told.)

That bug serves to illustrate a very important point about undefined
behavior. UB only refers to behavior that is not defined by the C
standard; the behavior might in fact be defined by some other document.
If such a document has authority over every place that your code needs
to work, there's absolutely nothing wrong with writing code with
undefined behavior that relies upon the definition of that behavior
provided by that document. But when you write such code, it's absolutely
essential that you know what the relevant definition is.

The developers in question were absolutely certain that they knew what
the defined behavior was for the platform that they were using: the
hardware had an instruction that could be used to load the data from a
specified memory location, and nothing problematic would occur if that
instruction was passed an address of 0.

There were two key mistakes in this thinking:
1. It's not the hardware that defines the behavior, it's the
implementation of C.

2. Popular misconceptions to the contrary notwithstanding, C is NOT a
portable assembler. C code does not instruct the compiler to generate a
particular set of machine code instructions. It only tells the
implementation what the desired behavior of the program is. An
implementation has no obligation to produce any specific set of machine
code instructions to achieve that goal. The only requirement is that the
observable behavior of the program (a term defined in 5.1.2.3p2, and
that definition is significantly more complicated than "behavior which
can be observed") must meet the requirements of the rest of the standard.

When the behavior is undefined, the standard doesn't impose any
requirements. In this particular case, the implementation provided it's
own definition of the behavior, and it was significantly more complex
than merely the single machine instruction that they expected to be
generated. Specifically, the defined behavior was to optimize all code
between the last time the pointer was updated, until the next time it
was updated, on the assumption that the pointer's value was not null.
Such an optimization is normally a good idea - if they had taken proper
care to prevent the pointer from having a null value, the code that was
removed would have been dead code - removing it sped up the program.

But they didn't take proper care to make sure the pointer was not null.
They dealt with that possibility only after dereferencing it, and as a
result, the code that they wrote to deal with that possibility got
optimized away.

The most ironic aspect of this problem was that the optimization that
revealed the bug in their code was not on by default. It was turned on
because they had explicitly requested it. Your obligation to know how an
implementation defines behavior that is undefined by the standard is
even higher when choosing non-default optimizations.

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

#82071

On 10/25/21 5:47 AM, Juha Nieminen wrote:
...
> Most modern C compilers will give you a warning if you try to assign
> a const char* (eg. a string literal) to a non-const char* (or give
> one to a function taking a non-const char*),

They must do so on assignment; 6.5.16p2 occurs in a "Constraints" section:
"An assignment operator shall have a modifiable lvalue as its left operand."

And if a function prototype is in scope "... the arguments are
implicitly converted, as if by assignment, to the types of the
corresponding parameters ..." (6.5.2.2p7), so the same constraints apply
there, too. For the same reason, they also apply to return statements.

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

#82081

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 10/25/21 5:47 AM, Juha Nieminen wrote:
> ...
>> Most modern C compilers will give you a warning if you try to assign
>> a const char* (eg. a string literal) to a non-const char* (or give
>> one to a function taking a non-const char*),
>
> They must do so on assignment; 6.5.16p2 occurs in a "Constraints" section:
> "An assignment operator shall have a modifiable lvalue as its left operand."
>
> And if a function prototype is in scope "... the arguments are
> implicitly converted, as if by assignment, to the types of the
> corresponding parameters ..." (6.5.2.2p7), so the same constraints apply
> there, too. For the same reason, they also apply to return statements.

I think the example being referred to was something like:
    char *s;
    s = "hello";
which does not require a diagnostic in C (because C string literals are
not const).  The following is recommended in C and required in C++:
    const char *s;
    s = "hello";
but here s is still a modifiable lvalue because the "const" applies to
what s points to, not to s itself.

A case that would invoke the constraint in 6.5.16p2 is:
    char *const s;
    s = "hello";
because s itself is read-only; you can't assign *anything* to it.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#82070

On 10/25/21 4:21 AM, RacingRabbit@watershipdown.co.uk wrote:
...
> Consts in C are pointless because it doesn't have references and its rather
> difficult to "accidentaly" dereference a pointer to update the value its
> pointing to.

Actually, it isn't. All it takes is unfamiliarity with the functions
you're using. I remember, in particular, I've seen messages from several
people expressing surprise that strtok() writes to the string that you
pass it as it's first argument. If the pointers they had tried to pass
to strtok() had been const char * rather than char*, they would have
been reminded of the problem. Of course, they might not have understood
the reminder, if they weren't familiar with functions whose declarations
use "const" appropriately. All of the standard library functions do so,
many other libraries don't.

However, that's only a part of the problem that "const" is intended to
help avoid. The other part is intentionally dereferencing a pointer to
update the value it's pointing act, due to being unaware of the fact
that what it's pointing at is something that shouldn't be written to. In
code which doesn't make proper use of "const", that's a fairly common
mistake, at least in my experience (which is admittedly limited, since
my own code does make proper use of "const").

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

#82072

On Mon, 25 Oct 2021 10:30:04 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>On 10/25/21 4:21 AM, RacingRabbit@watershipdown.co.uk wrote:
>....
>> Consts in C are pointless because it doesn't have references and its rather
>> difficult to "accidentaly" dereference a pointer to update the value its
>> pointing to.
>
>Actually, it isn't. All it takes is unfamiliarity with the functions
>you're using. I remember, in particular, I've seen messages from several
>people expressing surprise that strtok() writes to the string that you
>pass it as it's first argument. If the pointers they had tried to pass

Those are the sorts of people who should stick to python or javascript.

>However, that's only a part of the problem that "const" is intended to
>help avoid. The other part is intentionally dereferencing a pointer to
>update the value it's pointing act, due to being unaware of the fact
>that what it's pointing at is something that shouldn't be written to. In

They'll soon find out if they try to write to it.

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

#82075

On 10/25/21 10:39 AM, RacingRabbit@watershipdown.co.uk wrote:
> On Mon, 25 Oct 2021 10:30:04 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
...
>> However, that's only a part of the problem that "const" is intended to
>> help avoid. The other part is intentionally dereferencing a pointer to
>> update the value it's pointing act, due to being unaware of the fact
>> that what it's pointing at is something that shouldn't be written to. In
> 
> They'll soon find out if they try to write to it.

Not necessarily - the fact that the behavior is undefined gives
implementations the freedom to implement such code anyway they want,
including ways that can be quite hard to recognize as errors - even
though they are.
Back when I was first converting a lot of other people's K&R C code to
make use of the new features of C90, I frequently found errors like that
which had been masked for years - the errors were quite capable of
causing serious problems, but for one reason or the other, they had
failed to do frequently enough for the problem to be successfully
tracked down. Most of that code ran much more reliably after I finished
converting it.

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

#82083

On 10/25/2021 1:21 AM, RacingRabbit@watershipdown.co.uk wrote:
> On Sat, 23 Oct 2021 18:45:22 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> On 23/10/2021 13:06, Bart wrote:
>>> So, even /more/ clutter?! I's also like to see a typedefed version of my
>>> example that is not harder to understand.
>>>
>>
>> typedef const int constant_integer;
>> typedef constant_integer * pointer_to_constant_integer;
>> typedef const pointer_to_constant_integer
>> constant_pointer_to_constant_integer;
>> typedef constant_pointer_to_constant_integer *
>> pointer_to_constant_pointer_to_constant_integer;
>>
>> pointer_to_constant_pointer_to_constant_integer x;
> 
> Consts in C are pointless because it doesn't have references and its rather
> difficult to "accidentaly" dereference a pointer to update the value its
> pointing to.
> 

Fwiw, when writing code in C, I tend to use the following pattern:

struct foo
{
    unsigned int a;
};


void
foo_init(
     struct foo* const self,
     unsigned int a
){
     self->a = a;
}


int
foo_compute(
     struct foo const* const self,
     unsigned int a
){
     return self->a *= a + 123;
}


I like to use a const pointer to self so that if I accidentally modify 
self, I will get a nice warning. Its basically a habit of mine. 'self' 
is akin to the this pointer in C++.

Oh well... ;^)

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

#82124

On 10/25/2021 12:45 PM, Chris M. Thomasson wrote:
> On 10/25/2021 1:21 AM, RacingRabbit@watershipdown.co.uk wrote:
>> On Sat, 23 Oct 2021 18:45:22 +0200
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 23/10/2021 13:06, Bart wrote:
>>>> So, even /more/ clutter?! I's also like to see a typedefed version 
>>>> of my
>>>> example that is not harder to understand.
>>>>
>>>
>>> typedef const int constant_integer;
>>> typedef constant_integer * pointer_to_constant_integer;
>>> typedef const pointer_to_constant_integer
>>> constant_pointer_to_constant_integer;
>>> typedef constant_pointer_to_constant_integer *
>>> pointer_to_constant_pointer_to_constant_integer;
>>>
>>> pointer_to_constant_pointer_to_constant_integer x;
>>
>> Consts in C are pointless because it doesn't have references and its 
>> rather
>> difficult to "accidentaly" dereference a pointer to update the value its
>> pointing to.
>>
> 
> Fwiw, when writing code in C, I tend to use the following pattern:
> 
> struct foo
> {
>     unsigned int a;
> };
> 
> 
> void
> foo_init(
>      struct foo* const self,
>      unsigned int a
> ){
>      self->a = a;
> }
> 
> 
> int
> foo_compute(
>      struct foo const* const self,
>      unsigned int a
> ){
>      return self->a *= a + 123;
> }
> 
> 
> I like to use a const pointer to self so that if I accidentally modify 
> self, I will get a nice warning. Its basically a habit of mine. 'self' 
> is akin to the this pointer in C++.
> 
> Oh well... ;^)

See the deliberate mistake in here? Besides the foo_compute function 
returning int typo, argh!... Anyway, here is a program:
______________________________
#include <stdio.h>


struct foo
{
    unsigned int a;
};


void
foo_init(
     struct foo* const self,
     unsigned int a
){
     self->a = a;
}


unsigned int
foo_compute(
     struct foo const* const self,
     unsigned int a
){
     return self->a *= a + 123;
}

int main()
{
     struct foo foo;

     foo_init(&foo, 42);

     unsigned int foobar = foo_compute(&foo, 42);

     printf("foobar = %u\n", foobar);

     return 0;
}
______________________________

Does not compile... GOOD! Change foo_compute to:

______________________________
unsigned int
foo_compute(
     struct foo* const self,
     unsigned int a
){
     return self->a *= a + 123;
}
______________________________

and it does compile! So, const has it's uses, indeed.

;^)

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

#82064

Bart <bc@freeuk.com> wrote:
> Neither does the syntax make it that obvious which bit of the type is 
> refered to, as in:
> 
>   const int * const * x;

Actually the syntax *does* make it obvious. You are just reading the type
declaration in the wrong direction. Pointer variable declarations should
be read from right to left (this is a simple but non-obvious trick that
surprisingly few programmers know.) In your example, when we read the
declaration from right to left, it becomes:

"x is a pointer to a const pointer that points to an int that's const".

Or, if you want to be a bit clearer:

"x is a pointer to a (const pointer) that points to an int, the int
itself being const".

(In other words, x itself is not const and can be modified, but it
points to a const pointer, ie. *x cannot be modified, and this
const pointer is pointing to a const int, ie. **x cannot be modified
either.)

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

#82068

On 25/10/2021 06:00, Juha Nieminen wrote:
> Bart <bc@freeuk.com> wrote:
>> Neither does the syntax make it that obvious which bit of the type is
>> refered to, as in:
>>
>>    const int * const * x;
> 
> Actually the syntax *does* make it obvious. You are just reading the type
> declaration in the wrong direction. Pointer variable declarations should
> be read from right to left (this is a simple but non-obvious trick that
> surprisingly few programmers know.) In your example, when we read the
> declaration from right to left, it becomes:
> 
> "x is a pointer to a const pointer that points to an int that's const".
> 
> Or, if you want to be a bit clearer:
> 
> "x is a pointer to a (const pointer) that points to an int, the int
> itself being const".
> 
> (In other words, x itself is not const and can be modified, but it
> points to a const pointer, ie. *x cannot be modified, and this
> const pointer is pointing to a const int, ie. **x cannot be modified
> either.)
> 

If only it was that simple to read declarations!

Ones such as int** can work by going from right to left, but in general 
it is inside out.

I noticed you deftly bypassed the fact that 'const' for 'int' can be 
written either side of 'int', or both!

At least this example helps highlight which of those ** comes first.

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

Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9  Next page →

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

csiph-web