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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-10-24 16:18 -0700 |
| Message-ID | <792f8b91-0e99-42da-afda-8f9ef013daban@googlegroups.com> |
| In reply to | #82060 |
On Monday, 25 October 2021 at 01:11:57 UTC+3, Bart wrote: > On 24/10/2021 11:11, David Brown wrote: > > On 23/10/2021 19:58, Bart wrote: > > >> I don't do anything with these at the minute (I think 'out' and 'inout', > >> not shown, are just aliases for '&') but they can do a lot just as > >> annotations. > >> > > > > People can write code in a lazy way (or perhaps an old way), and this > > can cause some inconveniences in using it along with code written in > > newer and better ways. That's true in general - it is not special for > > C, nor special for "const" in C. > > > > Your solution to C's const problem (as you see it), is to have a > > language where you can distinguish between pointers which cannot be used > > to change the data, and pointers which /can/ be used to change the data. > > As long as people use these correctly in your language, or Pascal, or > > Ada, everything works correctly. > > > > That's fine - and a good idea. > > > > It is /exactly/ the same as is done in C. "void f1(char *)" is like an > > "inout" parameter, and "void f2(const char *)" is like an "in" parameter. > > > > Using "char *" as a parameter in C when it is read-only data is exactly > > like using "inout" parameters in Ada or Pascal, or "ichar s" in your > > language - it is lazy, unhelpful, and it stops people using it for > > constant data (without extra effort). > > > > Therefore, I simply don't understand what you have against "const" in C > > - your own language is almost identical except for minor syntax differences. > I've played around with C-style readonly type attributes in the past. I > didnt't like them. It disrupts the type system (see the fuss about how > _Generic should work) and it didn't give the necessary protection. > > 'const' in C only affects one level of a complex type. It doesn't > affects those parts not specified (like the members of a struct type, or > rather those values at the other side of an embedded pointer type, which > is not itself const). > > I want 'readonly' to protect an entire data structure, especially one > that is otherwise mutable that is passed to a function, by only > specifying one thing. > > Now, I haven't fully implemented such an attribute (I've only reserved > syntax like 'let' and 'in'), I just know how I'd like it to work. Can it be that you haven't implemented it because it is what you would like to want but do not always want? > That is, propagate down deep into the data structure. I think that is > possible. I don't think it would be part of the type system; it's likely > to be a property of an expression. In most software I have seen pointers in object often point at other objects that are not logically components of said object. So the pointers often do not go to "down deep" but entirely elsewhere.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-25 00:58 +0100 |
| Message-ID | <sl4rv3$i0s$1@dont-email.me> |
| In reply to | #82061 |
On 25/10/2021 00:18, Öö Tiib wrote: > On Monday, 25 October 2021 at 01:11:57 UTC+3, Bart wrote: >> 'const' in C only affects one level of a complex type. It doesn't >> affects those parts not specified (like the members of a struct type, or >> rather those values at the other side of an embedded pointer type, which >> is not itself const). >> >> I want 'readonly' to protect an entire data structure, especially one >> that is otherwise mutable that is passed to a function, by only >> specifying one thing. >> >> Now, I haven't fully implemented such an attribute (I've only reserved >> syntax like 'let' and 'in'), I just know how I'd like it to work. > > Can it be that you haven't implemented it because it is what you would > like to want but do not always want? Partly because I've classed it as low priority; this would not allow me to do anything new, just apply extra restrictions! However it is something interesting to explore. >> That is, propagate down deep into the data structure. I think that is >> possible. I don't think it would be part of the type system; it's likely >> to be a property of an expression. > > In most software I have seen pointers in object often point at other > objects that are not logically components of said object. So the > pointers often do not go to "down deep" but entirely elsewhere. Determining the boundaries of a data structure, beyond which write-protection shouldn't apply or can't be applied, would be one of the problems to look at.
[toc] | [prev] | [next] | [standalone]
| From | RacingRabbit@watershipdown.co.uk |
|---|---|
| Date | 2021-10-25 08:21 +0000 |
| Message-ID | <sl5pdi$4au$1@gioia.aioe.org> |
| In reply to | #82051 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-10-25 09:47 +0000 |
| Message-ID | <sl5ug4$qov$1@gioia.aioe.org> |
| In reply to | #82065 |
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. Very old-style C code, mostly prior to the C89 standard, but you can see even modern examples sometimes (for some old-school C coders habits die hard), often used non-const pointers to char as "strings". In fact, I think even the K&R famous book as examples with non-const char*'s being initialized to point to string literals. The problem with this is that it can be too easy to accidentally try to modify the contents of the "string" through that pointer. If you are accustomed to never using 'const' when dealing with char*'s, you'll probably pay little attention to the fact that some function somewhere is taking a non-const char* as parameter, and you might at some point call it with a pointer that's pointing to a string literal. If said function does modify the "string" it's getting as parameter, that's UB. 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*), but if you were determined to never use 'const' and turn off such warnings, such mistakes are not extraordinarily unlikely.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2021-10-25 12:33 +0200 |
| Message-ID | <itnfg2Frb4mU1@mid.individual.net> |
| In reply to | #82066 |
On 2021-10-25 at 11:47, Juha Nieminen wrote: > 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. Very old-style C code, mostly prior to the C89 standard, > but you can see even modern examples sometimes (for some old-school C coders > habits die hard), often used non-const pointers to char as "strings". > In fact, I think even the K&R famous book as examples with non-const char*'s > being initialized to point to string literals. > In defense of K&R. :-) They didn't have const in original C. It was Bjarne who first added it to C++, and only later did C also adopt the keyword.
[toc] | [prev] | [next] | [standalone]
| From | RacingRabbit@watershipdown.co.uk |
|---|---|
| Date | 2021-10-25 14:19 +0000 |
| Message-ID | <sl6ecq$11uu$1@gioia.aioe.org> |
| In reply to | #82066 |
On Mon, 25 Oct 2021 09:47:50 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >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. Very old-style C code, mostly prior to the C89 standard, >but you can see even modern examples sometimes (for some old-school C coders >habits die hard), often used non-const pointers to char as "strings". And? How do you accidentaly write *str or str[0] for example? >In fact, I think even the K&R famous book as examples with non-const char*'s >being initialized to point to string literals. The concept of const didn't exist in K&R C so what would be your alternative? >The problem with this is that it can be too easy to accidentally try to >modify the contents of the "string" through that pointer. If you are >accustomed to never using 'const' when dealing with char*'s, you'll >probably pay little attention to the fact that some function somewhere >is taking a non-const char* as parameter, and you might at some point >call it with a pointer that's pointing to a string literal. If said >function does modify the "string" it's getting as parameter, that's UB. No idea what UB means, but what'll happen is it'll crash immediately so you'll soon find out.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-25 10:59 -0400 |
| Message-ID | <sl6go4$pjq$1@dont-email.me> |
| In reply to | #82069 |
On 10/25/21 10:19 AM, RacingRabbit@watershipdown.co.uk wrote: > On Mon, 25 Oct 2021 09:47:50 -0000 (UTC) > Juha Nieminen <nospam@thanks.invalid> wrote: >> 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. Very old-style C code, mostly prior to the C89 standard, >> but you can see even modern examples sometimes (for some old-school C coders >> habits die hard), often used non-const pointers to char as "strings". > > And? How do you accidentaly write *str or str[0] for example? It's not the *str that's accidental, its the call to a function that contains *str, with an argument that points to a string that shouldn't be written to. That is in fact a fairly easy mistake to made, and when people didn't use "const" properly, it's actually a fairly common one. ... >> In fact, I think even the K&R famous book as examples with non-const char*'s >> being initialized to point to string literals. > > The concept of const didn't exist in K&R C so what would be your alternative? There was no alternative, which is why that was the case. After "const" was added to the language, K&R 2nd edition was updated accordingly. ... >> call it with a pointer that's pointing to a string literal. If said >> function does modify the "string" it's getting as parameter, that's UB. > > No idea what UB means, but what'll happen is it'll crash immediately so you'll > soon find out. UB means "Undefined Behavior", a technical term from the C standard which does NOT mean "behavior for which there is no definition". It means "behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this document imposes no requirements" (3.4.3). Note that "this document" refers to the C standard; other documents (such as compiler documentation or ABI standards) might define the behavior, without changing the fact that is qualifies as "undefined behavior" as far as the C standard is concerned. 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)." Note, in particular, that the most insidious form of undefined behavior is that your program can behave exactly the way you incorrectly thought it was required to behave. The reason that's dangerous is that it leaves you with no warning that the behavior might change when you recompile with a different compiler, or with different compiler options, or even with the same compiler options, or even if you simply run the program a second time, even if you give it the same inputs as the previous time. That's how comprehensive the phrase "no requirements" is - the undefined behavior is NOT required to be the same each time you execute the offending program. Getting back to your comment - it's not required to crash immediately - that would constitute a requirement. And it's actually possible, as a result of optimizations performed by the compiler, that it might actually do something quite different. In particular, one possibility is the attempt to write to the object might become a NOp (as indicated by the phrase "ignoring the situation completely").
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-10-25 17:56 +0200 |
| Message-ID | <sl6k3n$e8m$1@gioia.aioe.org> |
| In reply to | #82074 |
On 10/25/2021 4:59 PM, James Kuyper wrote: > On 10/25/21 10:19 AM, RacingRabbit@watershipdown.co.uk wrote: <snip> >> >> No idea what UB means, but what'll happen is it'll crash immediately so you'll >> soon find out. > > UB means "Undefined Behavior", a technical term from the C standard > which does NOT mean "behavior for which there is no definition". It > means "behavior, upon use of a nonportable or erroneous program > construct or of erroneous data, for which this document imposes no > requirements" (3.4.3). Note that "this document" refers to the C > standard; other documents (such as compiler documentation or ABI > standards) might define the behavior, without changing the fact that is > qualifies as "undefined behavior" as far as the C standard is concerned. Thanks for the quote, it made me compare it with the definition of UB in the C++ standard, which simply states "behavior for which this International Standard imposes no requirements". The lack of the sentence "upon use of a nonportable or erroneous program construct or of erroneous data" actually relegates the language at the mercy of language lawyers, and led to the UB bloat that affects C++ nowadays. > > 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)." > > Note, in particular, that the most insidious form of undefined behavior > is that your program can behave exactly the way you incorrectly thought > it was required to behave. The reason that's dangerous is that it leaves > you with no warning that the behavior might change when you recompile > with a different compiler, or with different compiler options, or even > with the same compiler options, or even if you simply run the program a > second time, even if you give it the same inputs as the previous time. > That's how comprehensive the phrase "no requirements" is - the undefined > behavior is NOT required to be the same each time you execute the > offending program. > > Getting back to your comment - it's not required to crash immediately - > that would constitute a requirement. And it's actually possible, as a > result of optimizations performed by the compiler, that it might > actually do something quite different. In particular, one possibility is > the attempt to write to the object might become a NOp (as indicated by > the phrase "ignoring the situation completely"). >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-10-25 11:11 -0700 |
| Message-ID | <8735op2cv0.fsf@nosuchdomain.example.com> |
| In reply to | #82076 |
Manfred <noname@add.invalid> writes:
> On 10/25/2021 4:59 PM, James Kuyper wrote:
>> On 10/25/21 10:19 AM, RacingRabbit@watershipdown.co.uk wrote:
> <snip>
>>>
>>> No idea what UB means, but what'll happen is it'll crash immediately so you'll
>>> soon find out.
>> UB means "Undefined Behavior", a technical term from the C standard
>> which does NOT mean "behavior for which there is no definition". It
>> means "behavior, upon use of a nonportable or erroneous program
>> construct or of erroneous data, for which this document imposes no
>> requirements" (3.4.3). Note that "this document" refers to the C
>> standard; other documents (such as compiler documentation or ABI
>> standards) might define the behavior, without changing the fact that is
>> qualifies as "undefined behavior" as far as the C standard is concerned.
>
> Thanks for the quote, it made me compare it with the definition of UB
> in the C++ standard, which simply states "behavior for which this
> International Standard imposes no requirements".
>
> The lack of the sentence "upon use of a nonportable or erroneous
> program construct or of erroneous data" actually relegates the
> language at the mercy of language lawyers, and led to the UB bloat
> that affects C++ nowadays.
[...]
I don't see how the omission of "upon use of a nonportable or erroneous
program construct or of erroneous data" in the C++ standard makes any
real difference.
C definition, all standard editions:
behavior, upon use of a nonportable or erroneous program construct
or of erroneous data, for which this International Standard imposes
no requirements
C++ definition, before C++11:
behavior, such as might arise upon use of an erroneous program
construct or erroneous data, for which this International Standard
imposes no requirement
C++ definition, C++11 and later:
behavior for which this International Standard imposes no requirements
In all cases, "undefined behavior" is determined either by an explicit
statement or by the omission of any definition of the behavior (or, in
C, by violation of a "shall" outside a constraint).
--
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 | Manfred <noname@add.invalid> |
|---|---|
| Date | 2021-10-26 17:15 +0200 |
| Message-ID | <sl961t$qs4$1@gioia.aioe.org> |
| In reply to | #82082 |
On 10/25/2021 8:11 PM, Keith Thompson wrote: > Manfred <noname@add.invalid> writes: >> On 10/25/2021 4:59 PM, James Kuyper wrote: >>> On 10/25/21 10:19 AM, RacingRabbit@watershipdown.co.uk wrote: >> <snip> >>>> >>>> No idea what UB means, but what'll happen is it'll crash immediately so you'll >>>> soon find out. >>> UB means "Undefined Behavior", a technical term from the C standard >>> which does NOT mean "behavior for which there is no definition". It >>> means "behavior, upon use of a nonportable or erroneous program >>> construct or of erroneous data, for which this document imposes no >>> requirements" (3.4.3). Note that "this document" refers to the C >>> standard; other documents (such as compiler documentation or ABI >>> standards) might define the behavior, without changing the fact that is >>> qualifies as "undefined behavior" as far as the C standard is concerned. >> >> Thanks for the quote, it made me compare it with the definition of UB >> in the C++ standard, which simply states "behavior for which this >> International Standard imposes no requirements". >> >> The lack of the sentence "upon use of a nonportable or erroneous >> program construct or of erroneous data" actually relegates the >> language at the mercy of language lawyers, and led to the UB bloat >> that affects C++ nowadays. > [...] > > I don't see how the omission of "upon use of a nonportable or erroneous > program construct or of erroneous data" in the C++ standard makes any > real difference. It depends on the reader: whether it is some sort of text processing machine, a language lawyer or a human being. > > C definition, all standard editions: > behavior, upon use of a nonportable or erroneous program construct > or of erroneous data, for which this International Standard imposes > no requirements > > C++ definition, before C++11: > behavior, such as might arise upon use of an erroneous program > construct or erroneous data, for which this International Standard > imposes no requirement > > C++ definition, C++11 and later: > behavior for which this International Standard imposes no requirements > > In all cases, "undefined behavior" is determined either by an explicit > statement or by the omission of any definition of the behavior (or, in > C, by violation of a "shall" outside a constraint). > For a human being, the additional sentence makes a difference, simply because it is there: it means that the writer had a reason to write it, and such writer's intent is part of the message that matters to a human reader. More specifically: In C, the additional sentence actually poses a distinctive characterization of the code that qualifies for undefined behavior, i.e. "nonportable or erroneus" code, which is something else than saying "anything that is not explicitly defined here". Now, the problem is that the C definition actually redirects to a definition of "nonportable" and (more relevantly) "erroneous", so a machine reader might trigger an "undefined reference" error and stop parsing. A language lawyer might interpret the wording as implying that anything that is not explicitly defined is considered "nonportable" or "erroneous", but that's an interpretation which is still to be proven to hold in court, since the other party's lawyer might interpret the same wording as UB being <<anything that is "nonportable" or "erroneous" /and/ is not covered by this standard's requirements>> Schematically, one might think of the entire set of possible source code to be validated against the standard, and divide it into the subsets: 1) Explicitly defined valid code (e.g. syntax of declarations) 2) Explicitly defined invalid code (e.g. constraint violations) 3) Code which is not explicitly defined by 1) and 2) Ideally, for a perfect standard, subset 3) would be empty - i.e. to make a machine reader happy. In practice, standards are (luckily) written by humans, so there may be something left in subset 3). To me, the additional sentence is intended to give a rationale to discriminate which is which in this area. That said, lawyers may still complain that a non-empty subset 3) leads to ambiguity, and this may be a serious problem in court. Pre-C++11 C++ apparently tried to address this potential ambiguity by adding "such as", thus suggesting that the category of "nonportable" or "erroneous" code is meant to be an example of code for which the standard poses "no requirements". The wording may appear to suggest that subset 3) is meant to be included in subset 2), but the authors didn't feel brave enough to say this explicitly, and left the categories of "nonportable" and "erroneous" in. The fact is that, obviously, placing subset 3) into subset 2) poses a heavy burden on the standard itself. C++11-and-later C++ was actually brave enough to assert that anything that is not explicitly defined in the standard is "undefined behavior", which would just be a self-identity assertion if it weren't for the note that clarifies that UB is a very Bad Thing™, unless such behavior is actually defined by the implementation. The result is that the latest C++ definition of UB is so strong that it suddenly raised the bar of the Standard's quality requirement by several levels, thus opening the Pandora's box of countless examples of UB that affect nowadays' C++, to the point of invalidating even sample code in Bjarne's TC++PL that has been valid since the beginning of time, and led to cryptic additions to the standard itself (std::launder, anyone?) This might be seen as a process of improvement of the language, but so far this seems controversial.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-10-29 06:41 -0700 |
| Message-ID | <86o878dk36.fsf@linuxsc.com> |
| In reply to | #82109 |
Manfred <noname@add.invalid> writes: > On 10/25/2021 8:11 PM, Keith Thompson wrote: > >> Manfred <noname@add.invalid> writes: >> >>> On 10/25/2021 4:59 PM, James Kuyper wrote: >>> >>>> On 10/25/21 10:19 AM, RacingRabbit@watershipdown.co.uk wrote: >>> >>> <snip> >>> >>>>> No idea what UB means, but what'll happen is it'll crash >>>>> immediately so you'll soon find out. >>>> >>>> UB means "Undefined Behavior", a technical term from the C >>>> standard which does NOT mean "behavior for which there is no >>>> definition". It means "behavior, upon use of a nonportable or >>>> erroneous program construct or of erroneous data, for which this >>>> document imposes no requirements" (3.4.3). Note that "this >>>> document" refers to the C standard; other documents (such as >>>> compiler documentation or ABI standards) might define the >>>> behavior, without changing the fact that is qualifies as >>>> "undefined behavior" as far as the C standard is concerned. >>> >>> Thanks for the quote, it made me compare it with the definition of >>> UB in the C++ standard, which simply states "behavior for which >>> this International Standard imposes no requirements". >>> >>> The lack of the sentence "upon use of a nonportable or erroneous >>> program construct or of erroneous data" actually relegates the >>> language at the mercy of language lawyers, and led to the UB bloat >>> that affects C++ nowadays. >> >> [...] >> >> I don't see how the omission of "upon use of a nonportable or >> erroneous program construct or of erroneous data" in the C++ >> standard makes any real difference. > > It depends on the reader: whether it is some sort of text > processing machine, a language lawyer or a human being. > >> C definition, all standard editions: >> behavior, upon use of a nonportable or erroneous program >> construct or of erroneous data, for which this International >> Standard imposes no requirements >> >> C++ definition, before C++11: >> behavior, such as might arise upon use of an erroneous program >> construct or erroneous data, for which this International >> Standard imposes no requirement >> >> C++ definition, C++11 and later: >> behavior for which this International Standard imposes no >> requirements >> >> In all cases, "undefined behavior" is determined either by an >> explicit statement or by the omission of any definition of the >> behavior (or, in C, by violation of a "shall" outside a >> constraint). > > For a human being, the additional sentence makes a difference, > simply because it is there: it means that the writer had a reason > to write it, and such writer's intent is part of the message that > matters to a human reader. > > More specifically: > > In C, the additional sentence actually poses a distinctive > characterization of the code that qualifies for undefined behavior, > i.e. "nonportable or erroneus" code, which is something else than > saying "anything that is not explicitly defined here". Now, the > problem is that the C definition actually redirects to a definition > of "nonportable" and (more relevantly) "erroneous", so a machine > reader might trigger an "undefined reference" error and stop > parsing. A language lawyer might interpret the wording as implying > that anything that is not explicitly defined is considered > "nonportable" or "erroneous", but that's an interpretation which is > still to be proven to hold in court, since the other party's lawyer > might interpret the same wording as UB being <<anything that is > "nonportable" or "erroneous" /and/ is not covered by this > standard's requirements>> > > [...] Thank you for injecting a note of sanity into a discussion of what text in the C and C++ standards means.
[toc] | [prev] | [next] | [standalone]
| From | RacingRabbit@watershipdown.co.uk |
|---|---|
| Date | 2021-10-25 16:14 +0000 |
| Message-ID | <sl6l56$10d6$1@gioia.aioe.org> |
| In reply to | #82074 |
On Mon, 25 Oct 2021 10:59:15 -0400 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >On 10/25/21 10:19 AM, RacingRabbit@watershipdown.co.uk wrote: >>> call it with a pointer that's pointing to a string literal. If said >>> function does modify the "string" it's getting as parameter, that's UB. >> >> No idea what UB means, but what'll happen is it'll crash immediately so >you'll >> soon find out. > >UB means "Undefined Behavior", a technical term from the C standard >which does NOT mean "behavior for which there is no definition". It >means "behavior, upon use of a nonportable or erroneous program >construct or of erroneous data, for which this document imposes no >requirements" (3.4.3). Note that "this document" refers to the C >standard; other documents (such as compiler documentation or ABI >standards) might define the behavior, without changing the fact that is >qualifies as "undefined behavior" as far as the C standard is concerned. 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";
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-25 13:14 -0400 |
| Message-ID | <sl6oln$odm$1@dont-email.me> |
| In reply to | #82077 |
On 10/25/21 12:14 PM, 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.
Perhaps that is true at the hardware level, on some processors. However,
there's also some processors which don't even have the concept of
read-only memory, and there are fully conforming C implementation that
can target some of those processors.
However, I'm talking about the level of C code, not hardware. The
translation from C code to machine code is defined only in terms of the
required behavior, and when there is NO required behavior, that
translation can get distinctly weird if you believe the mistaken idea
that C is a "portable assembler".
> ... 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";
Such code cannot result in the string being placed in read-only memory,
because it's perfectly legal to modify str. On the other hand, both of
the following C declarations do allow strings to be placed in read-only
memory, even if they occur at block scope:
const char str[] = "Hello world!";
char *strptr = "Good bye!";
The first one is allowed to be placed in read-only memory because the
object str is declared "const". The second is allowed to be placed in
read-only memory because it's undefined behavior to write to the memory
pointed at by by strptr, despite the fact that, in C, the string literal
does NOT have the type const char[10], as it would in C++.
However, just because it would be permissible for an implementation to
place those objects in read-only memory, it's not actually required that
they be placed there. Many implementations won't do so, especially if
those declarations occur at block scope.
And even if they were placed in read-only memory, writing C code that
attempts to modify that memory need not result in machine language
instructions being executed to attempt such a read. Because the behavior
of such code is undefined, an implementation is free to translate such
source code into machine code that does nothing of the kind - and this
is, in fact, the natural result, in some contexts, of certain optimizations.
[toc] | [prev] | [next] | [standalone]
| From | RacingRabbit@watershipdown.co.uk |
|---|---|
| Date | 2021-10-26 08:18 +0000 |
| Message-ID | <sl8dlg$nav$1@gioia.aioe.org> |
| In reply to | #82078 |
On Mon, 25 Oct 2021 13:14:30 -0400 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >On 10/25/21 12:14 PM, 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. > >Perhaps that is true at the hardware level, on some processors. However, >there's also some processors which don't even have the concept of >read-only memory, and there are fully conforming C implementation that >can target some of those processors. > >However, I'm talking about the level of C code, not hardware. The >translation from C code to machine code is defined only in terms of the >required behavior, and when there is NO required behavior, that >translation can get distinctly weird if you believe the mistaken idea >that C is a "portable assembler". > >> ... 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"; > >Such code cannot result in the string being placed in read-only memory, >because it's perfectly legal to modify str. On the other hand, both of Yes, that was my point. [] means modifyable, * means read only in every C implementation I've ever used.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-26 12:39 +0100 |
| Message-ID | <sl8pee$5c3$1@dont-email.me> |
| In reply to | #82090 |
On 26/10/2021 09:18, RacingRabbit@watershipdown.co.uk wrote:
> On Mon, 25 Oct 2021 13:14:30 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 10/25/21 12:14 PM, 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.
>>
>> Perhaps that is true at the hardware level, on some processors. However,
>> there's also some processors which don't even have the concept of
>> read-only memory, and there are fully conforming C implementation that
>> can target some of those processors.
>>
>> However, I'm talking about the level of C code, not hardware. The
>> translation from C code to machine code is defined only in terms of the
>> required behavior, and when there is NO required behavior, that
>> translation can get distinctly weird if you believe the mistaken idea
>> that C is a "portable assembler".
>>
>>> ... 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";
>>
>> Such code cannot result in the string being placed in read-only memory,
>> because it's perfectly legal to modify str. On the other hand, both of
>
> Yes, that was my point. [] means modifyable, * means read only in every
> C implementation I've ever used.
>
>
You've misunderstood then.
But * and [] types are modifable:
char* s = "ABC";
puts(s);
*s = 'Z';
This shows ABC the first time it's executed. The second time it shows
ZBC; the code has changed the string literal! Where the same literal iS
shared across the program, it will change the value of "ABC" everywhere.
This is on those implementations that don't put ABC into readonly memory
(eg. tcc, bcc, DMC, lcc, msvc). Ones like gcc and clang will crash.
You can't compare that with this:
char t[] = "ABC";
puts(t)
t[0] = 'Z';
Here, "ABC" is left unmolested. But the reason is because the
initialisation /copies/ the literal string to the array. So it modifies
a copy. The declaration of s directly points it to the literal.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-10-26 14:29 +0100 |
| Message-ID | <87v91jzzgt.fsf@bsb.me.uk> |
| In reply to | #82097 |
Bart <bc@freeuk.com> writes: > On 26/10/2021 09:18, RacingRabbit@watershipdown.co.uk wrote: >> On Mon, 25 Oct 2021 13:14:30 -0400 >> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>> On 10/25/21 12:14 PM, 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. >>> >>> Perhaps that is true at the hardware level, on some processors. However, >>> there's also some processors which don't even have the concept of >>> read-only memory, and there are fully conforming C implementation that >>> can target some of those processors. >>> >>> However, I'm talking about the level of C code, not hardware. The >>> translation from C code to machine code is defined only in terms of the >>> required behavior, and when there is NO required behavior, that >>> translation can get distinctly weird if you believe the mistaken idea >>> that C is a "portable assembler". >>> >>>> ... 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"; >>> >>> Such code cannot result in the string being placed in read-only memory, >>> because it's perfectly legal to modify str. On the other hand, both of >> Yes, that was my point. [] means modifyable, * means read only in every >> C implementation I've ever used. > > You've misunderstood then. Yes, RR has misunderstood (or is expressing the point in a confusing way). > But * and [] types are modifable: And this is bad wording. Some objects with pointer type are modifiable and some are not. No objects with array types are modifiable. But in fact you seem to be referring to the /target/ of pointer types (again, some of which are modifiable and some are not) and to array /elements/ about which the same is also true. There is no general rule about "* and [] types". > char* s = "ABC"; This relies on an a conversion that is valid (bad unwise) in C and not permitted in C++. > puts(s); > *s = 'Z'; This is undefined behaviour in both C and C++. The target of the assignment (the first character of the string) is not a modifiable object. > This shows ABC the first time it's executed. The second time it shows > ZBC; the code has changed the string literal! It might show ABC again, or it may not get that far. Or, formally, anything at all could happen. > This is on those implementations that don't put ABC into readonly > memory (eg. tcc, bcc, DMC, lcc, msvc). Ones like gcc and clang will > crash. It may vary depending on the command-line options, the platform and compiler version. Talking about what "gcc" or "tcc" does is not very helpful. Anyway, people should be encouraged to write, where possible, code that does not depend on such things. > You can't compare that with this: > > char t[] = "ABC"; > puts(t) > t[0] = 'Z'; > > Here, "ABC" is left unmolested. But the reason is because the > initialisation /copies/ the literal string to the array. So it > modifies a copy. The declaration of s directly points it to the > literal. Yes. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-26 15:11 +0100 |
| Message-ID | <sl92b8$83g$1@dont-email.me> |
| In reply to | #82098 |
On 26/10/2021 14:29, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> On 26/10/2021 09:18, RacingRabbit@watershipdown.co.uk wrote: >>> On Mon, 25 Oct 2021 13:14:30 -0400 >>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>>> On 10/25/21 12:14 PM, 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. >>>> >>>> Perhaps that is true at the hardware level, on some processors. However, >>>> there's also some processors which don't even have the concept of >>>> read-only memory, and there are fully conforming C implementation that >>>> can target some of those processors. >>>> >>>> However, I'm talking about the level of C code, not hardware. The >>>> translation from C code to machine code is defined only in terms of the >>>> required behavior, and when there is NO required behavior, that >>>> translation can get distinctly weird if you believe the mistaken idea >>>> that C is a "portable assembler". >>>> >>>>> ... 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"; >>>> >>>> Such code cannot result in the string being placed in read-only memory, >>>> because it's perfectly legal to modify str. On the other hand, both of >>> Yes, that was my point. [] means modifyable, * means read only in every >>> C implementation I've ever used. >> >> You've misunderstood then. > > Yes, RR has misunderstood (or is expressing the point in a confusing > way). > >> But * and [] types are modifable: > > And this is bad wording. It's a modification of what RR said. > Some objects with pointer type are modifiable > and some are not. No objects with array types are modifiable. I don't know what you mean by that. Unless it is that you can't directly assign to a whole array object at once; only an element at a time. Or, going the other way, when the array is a member of a struct and you assign to the whole struct. (I know that you can't make a whole array const, only the elements.) > But in > fact you seem to be referring to the /target/ of pointer types (again, > some of which are modifiable and some are not) and to array /elements/ > about which the same is also true. There is no general rule about "* > and [] types". > >> char* s = "ABC"; > > This relies on an a conversion that is valid (bad unwise) in C and not > permitted in C++. I tried it in C++ before posting (as I'd thought that "ABC" would have type const char*) but it seemed to work. (Using -Wall -std=c++14.) >> puts(s); >> *s = 'Z'; > > This is undefined behaviour in both C and C++. The target of the > assignment (the first character of the string) is not a modifiable > object. >> This shows ABC the first time it's executed. The second time it shows >> ZBC; the code has changed the string literal! > > It might show ABC again, or it may not get that far. Or, formally, > anything at all could happen. >> This is on those implementations that don't put ABC into readonly >> memory (eg. tcc, bcc, DMC, lcc, msvc). Ones like gcc and clang will >> crash. > > It may vary depending on the command-line options, the platform and > compiler version. Talking about what "gcc" or "tcc" does is not very > helpful. Anyway, people should be encouraged to write, where possible, > code that does not depend on such things. I'm writing about what is typically observed. (I don't put string literals into a readonly segment because I haven't got round to it yet. It is surprising that a big compiler like MSVC doesn't do so either, but apparently that's only done when optimising; rather odd.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-10-26 09:49 -0700 |
| Message-ID | <87y26f20kh.fsf@nosuchdomain.example.com> |
| In reply to | #82099 |
Bart <bc@freeuk.com> writes:
> On 26/10/2021 14:29, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
[...]
>>> char* s = "ABC";
>> This relies on an a conversion that is valid (bad unwise) in C and
>> not
>> permitted in C++.
>
> I tried it in C++ before posting (as I'd thought that "ABC" would have
> type const char*) but it seemed to work. (Using -Wall -std=c++14.)
And you didn't bother to mention the diagnostic? I get
warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]
And of course with "-pedantic-errors" it becomes a fatal error.
Did you not get a diagnostic? It's not all that interesting to see what
you can get away with by ignoring warnings.
> I'm writing about what is typically observed.
What I typically observe is that skilled programmers pay attention to
warnings and do not attempt to modify string literals.
> (I don't put string literals into a readonly segment because I haven't
> got round to it yet.
>
> It is surprising that a big compiler like MSVC doesn't do so either,
> but apparently that's only done when optimising; rather odd.)
My quick experiment with MSVC 2017 does not confirm that.
char *s = "ABC";
gives a fatal error in C++. It compiles in C (as expected), but
attempting to modify the literal causes a run-time crash.
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-26 18:38 +0100 |
| Message-ID | <sl9eev$6vj$1@dont-email.me> |
| In reply to | #82117 |
On 26/10/2021 17:49, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 26/10/2021 14:29, Ben Bacarisse wrote: >>> Bart <bc@freeuk.com> writes: > [...] >>>> char* s = "ABC"; >>> This relies on an a conversion that is valid (bad unwise) in C and >>> not >>> permitted in C++. >> >> I tried it in C++ before posting (as I'd thought that "ABC" would have >> type const char*) but it seemed to work. (Using -Wall -std=c++14.) > > And you didn't bother to mention the diagnostic? I get > warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings] > And of course with "-pedantic-errors" it becomes a fatal error. > > Did you not get a diagnostic? It's not all that interesting to see what > you can get away with by ignoring warnings. I used rextester.com, which uses the default options I used. There were no diagnostics. Maybe I could have tested half a dozen more C++ compilers, but they're thin on the ground on my machine. >> I'm writing about what is typically observed. > What I typically observe is that skilled programmers pay attention to > warnings and do not attempt to modify string literals. In general a compiler is not able to warn about the latter, and a programmer may not know that a pointer passed via a function for example points into readonly memory. Or out-of-bounds memory. Or contains NULL or other invalid memory address. It is however useful to know what might TYPICALLY happen if you do try and write into a string literal.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-10-26 11:20 -0700 |
| Message-ID | <87ilxj1wd3.fsf@nosuchdomain.example.com> |
| In reply to | #82121 |
Bart <bc@freeuk.com> writes:
> On 26/10/2021 17:49, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 26/10/2021 14:29, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>> [...]
>>>>> char* s = "ABC";
>>>> This relies on an a conversion that is valid (bad unwise) in C and
>>>> not
>>>> permitted in C++.
>>>
>>> I tried it in C++ before posting (as I'd thought that "ABC" would have
>>> type const char*) but it seemed to work. (Using -Wall -std=c++14.)
>> And you didn't bother to mention the diagnostic? I get
>> warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]
>> And of course with "-pedantic-errors" it becomes a fatal error.
>> Did you not get a diagnostic? It's not all that interesting to see
>> what
>> you can get away with by ignoring warnings.
>
> I used rextester.com, which uses the default options I used. There
> were no diagnostics.
Yes, there were. rextester.com didn't show them to you because you
didn't enable the "Show compiler warnings" checkbox.
> Maybe I could have tested half a dozen more C++ compilers, but they're
> thin on the ground on my machine.
>
>>> I'm writing about what is typically observed.
Any C++ compiler that does not issue a diagnostic for
char* s = "ABC";
is non-conforming. I'm skeptical that there are very many C++ compilers
out there that fail to do this when invoked properly. (C does not
require a diagnostic, which makes it important to remember to add
"const".)
>> What I typically observe is that skilled programmers pay attention to
>> warnings and do not attempt to modify string literals.
>
> In general a compiler is not able to warn about the latter, and a
> programmer may not know that a pointer passed via a function for
> example points into readonly memory. Or out-of-bounds memory. Or
> contains NULL or other invalid memory address.
In C++, it's difficult to even attempt to modify a string literal
without either triggering a required diagnostic or explicitly doing
something to override const. (It's easier in C, unfortunately.)
> It is however useful to know what might TYPICALLY happen if you do try
> and write into a string literal.
Agreed. What typically happens in C++ is that you'll get a diagnostic
before you even try to modify a string literal, since C++ string
literals are const. What typically happens in C is that the program
crashes. There are C compilers that don't put string literals in
read-only memory (I've confirmed that tcc doesn't), but as far as I
known none of them are in widespread use.
--
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]
Page 3 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