Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #82003 > unrolled thread
| Started by | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| First post | 2021-10-21 05:23 +0000 |
| Last post | 2021-10-24 14:20 +0000 |
| Articles | 20 on this page of 179 — 23 participants |
Back to article view | Back to comp.lang.c++
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 →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-10-29 06:45 -0700 |
| Message-ID | <86k0hwdjwr.fsf@linuxsc.com> |
| In reply to | #82119 |
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]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-10-29 11:11 -0700 |
| Message-ID | <87lf2bzooo.fsf@nosuchdomain.example.com> |
| In reply to | #82177 |
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]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-04-25 07:39 -0700 |
| Message-ID | <867d7d8bwj.fsf@linuxsc.com> |
| In reply to | #82180 |
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]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-04-25 10:59 -0700 |
| Message-ID | <87k0bdavt9.fsf@nosuchdomain.example.com> |
| In reply to | #83726 |
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]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-10-26 05:29 +0000 |
| Message-ID | <sl83np$vf4$1@gioia.aioe.org> |
| In reply to | #82077 |
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-10-26 08:53 +0200 |
| Message-ID | <sl88lt$lc7$1@dont-email.me> |
| In reply to | #82086 |
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]
| From | RacingRabbit@watershipdown.co.uk |
|---|---|
| Date | 2021-10-26 08:23 +0000 |
| Message-ID | <sl8dtk$r7q$1@gioia.aioe.org> |
| In reply to | #82086 |
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]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-10-26 08:40 +0000 |
| Message-ID | <sl8etq$14sk$2@gioia.aioe.org> |
| In reply to | #82092 |
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]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-10-26 05:18 +0000 |
| Message-ID | <sl8339$ou3$1@gioia.aioe.org> |
| In reply to | #82074 |
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-10-26 09:07 +0200 |
| Message-ID | <sl89fj$pum$1@dont-email.me> |
| In reply to | #82085 |
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]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-26 11:03 -0400 |
| Message-ID | <sl95cq$vku$1@dont-email.me> |
| In reply to | #82085 |
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]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-25 10:39 -0400 |
| Message-ID | <sl6fih$ghq$1@dont-email.me> |
| In reply to | #82066 |
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]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-10-25 10:56 -0700 |
| Message-ID | <877de12dkn.fsf@nosuchdomain.example.com> |
| In reply to | #82071 |
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]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-25 10:30 -0400 |
| Message-ID | <sl6f1d$9q0$2@dont-email.me> |
| In reply to | #82065 |
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]
| From | RacingRabbit@watershipdown.co.uk |
|---|---|
| Date | 2021-10-25 14:39 +0000 |
| Message-ID | <sl6fin$1nak$1@gioia.aioe.org> |
| In reply to | #82070 |
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]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-25 11:05 -0400 |
| Message-ID | <sl6h3r$s86$1@dont-email.me> |
| In reply to | #82072 |
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]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-25 12:45 -0700 |
| Message-ID | <sl71g2$sng$1@dont-email.me> |
| In reply to | #82065 |
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]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-26 11:20 -0700 |
| Message-ID | <sl9gtm$pjg$1@dont-email.me> |
| In reply to | #82083 |
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]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-10-25 05:00 +0000 |
| Message-ID | <sl5dlh$1b1t$1@gioia.aioe.org> |
| In reply to | #82037 |
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]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-25 12:13 +0100 |
| Message-ID | <sl63g4$lrg$1@dont-email.me> |
| In reply to | #82064 |
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