Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #80156 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2021-06-05 12:53 +0200 |
| Last post | 2021-06-07 14:52 +0000 |
| Articles | 20 on this page of 156 — 33 participants |
Back to article view | Back to comp.lang.c++
Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-05 12:53 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 14:19 +0200
Re: Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-05 14:27 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 14:33 +0200
Re: Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-05 15:06 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 15:29 +0200
Re: Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-05 17:38 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 17:51 +0200
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-05 11:56 -0400
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-05 19:08 -0400
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-06 11:24 +0200
Re: Is this really necessary Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-06-06 10:33 +0100
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-06 07:56 -0400
Re: Is this really necessary Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-06-06 15:00 +0100
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 16:20 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-07 00:44 -0700
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-07 12:13 -0700
Re: Is this really necessary Bo Persson <bo@bo-persson.se> - 2021-06-07 21:58 +0200
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 10:25 -0700
Re: Is this really necessary Bo Persson <bo@bo-persson.se> - 2021-08-07 21:21 +0200
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-05 06:34 -0700
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-05 20:03 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 12:59 -0700
Re: Is this really necessary MrSpud_85yGi2@1ahbfz.gov - 2021-08-08 09:18 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-08 09:23 -0400
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-08 15:04 +0000
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-08-08 13:14 -0400
Re: Is this really necessary MrSpud_1dgrmf@dx58865qyrdw30lqllb.info - 2021-08-09 08:21 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-09 08:53 +0000
Re: Is this really necessary "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-08-09 19:53 +0200
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-10 05:22 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 14:54 +0000
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 11:41 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-11 05:39 +0000
Re: Is this really necessary Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-08-08 20:01 +0100
Re: Is this really necessary MrSpud_ifhov@nldls6_1kg3nl2qnwv.biz - 2021-08-09 08:19 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-09 08:55 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-09 12:16 -0400
Re: Is this really necessary MrSpud_HG@_0b772d8ha3yjo0xb.edu - 2021-08-09 16:23 +0000
Re: Is this really necessary Vir Campestris <vir.campestris@invalid.invalid> - 2021-08-09 21:50 +0100
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-08-09 20:57 -0400
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 01:12 +0000
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-08-09 21:21 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-10 07:13 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-10 05:29 +0000
Re: Is this really necessary MrSpud_12tus_Atff@bya886olr5o8dhu9.ac.uk - 2021-08-10 07:28 +0000
Re: Is this really necessary Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-08-10 15:34 +0100
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 14:59 +0000
Re: Is this really necessary MrSpud_wPgnov999o@vv7a6.tv - 2021-08-10 15:54 +0000
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 11:29 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-11 08:45 +0000
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-11 07:05 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-11 14:18 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 14:57 +0000
Re: Is this really necessary MrSpud_pb9bpp7Ej@6urvt16b9fax.gov.uk - 2021-08-10 07:23 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 15:02 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-10 06:11 -0700
Re: Is this really necessary Bo Persson <bo@bo-persson.se> - 2021-08-10 16:13 +0200
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-11 12:40 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-12 08:20 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-12 03:50 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-12 14:58 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-12 08:29 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-12 15:39 +0000
Re: Is this really necessary Paavo Helde <myfirstname@osa.pri.ee> - 2021-08-12 20:07 +0300
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-13 07:16 +0000
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-13 09:26 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-13 10:30 -0400
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-13 14:58 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-14 08:07 +0000
Re: Is this really necessary "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-08-14 10:40 -0700
Re: Is this really necessary "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-08-14 10:38 -0700
Re: Is this really necessary "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-08-13 15:30 +0200
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-13 11:18 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 03:20 -0700
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-14 13:24 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-14 20:33 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-15 00:40 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-15 07:02 -0700
Re: Is this really necessary "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-08-15 21:19 +0200
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-08-15 15:42 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-21 12:38 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-14 08:13 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 02:58 -0700
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-13 14:32 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 02:28 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 03:00 -0700
Re: Is this really necessary Bart <bc@freeuk.com> - 2021-08-14 14:03 +0100
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-14 15:06 +0000
Re: Is this really necessary "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-08-12 12:06 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-13 09:19 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-13 14:35 +0000
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-13 14:58 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 15:03 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-11 12:54 -0700
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 20:20 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-12 03:42 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-11 05:45 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-11 05:26 -0700
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 14:06 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 14:01 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-09 23:20 -0400
Re: Is this really necessary MrSpud_m7k7yilq_8@u6w.biz - 2021-08-10 07:26 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-10 07:51 +0000
Re: Is this really necessary MrSpud_ggBp1lq0@lxz.tv - 2021-08-10 07:59 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-10 12:24 +0000
Re: Is this really necessary MrSpud_u7lm@bxuc3wy1g3cxiqu5j2x1_7iu.com - 2021-08-10 15:51 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-11 05:47 +0000
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-11 08:46 +0000
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-08-10 11:20 +0200
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-10 10:27 -0400
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-08-10 17:44 +0200
Re: Is this really necessary MrSpud_885p_dugji@l6zhsgj_v6t3dbj.tv - 2021-08-10 15:50 +0000
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-08-11 08:31 +0200
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-10 10:27 -0400
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 11:27 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-11 08:44 +0000
Re: Is this really necessary Paavo Helde <myfirstname@osa.pri.ee> - 2021-08-11 16:05 +0300
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-10 06:41 -0700
Re: Is this really necessary Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-06 18:48 +0300
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-06 14:26 -0400
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 16:10 -0700
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-06 21:30 -0400
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 18:49 -0700
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 18:51 -0700
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-06 22:57 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-07 09:43 -0700
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-07 09:51 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 10:22 -0700
Re: Is this really necessary "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-06-07 10:13 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 10:22 -0700
Re: Is this really necessary "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-08-07 12:40 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 12:54 -0700
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-06 23:17 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-07 09:19 -0700
Re: Is this really necessary Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-07 21:58 +0300
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-10 11:29 -0700
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-05 05:38 -0700
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 15:41 +0200
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-05 08:18 -0700
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-05 11:58 -0400
Re: Is this really necessary MrSpook_rs7x@4hhtozmpj299zx.tv - 2021-06-05 16:00 +0000
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 18:16 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-06 17:34 +0200
Re: Is this really necessary MrSpook_ie@q67rq6_2ly9ut44j.org - 2021-06-06 13:55 +0000
Re: Is this really necessary Bo Persson <bo@bo-persson.se> - 2021-06-05 19:50 +0200
Re: Is this really necessary MrSpook_zn7@4tzq7j92.gov - 2021-06-06 13:59 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-05 17:42 -0400
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-06 11:05 +0200
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-07 00:27 -0700
Re: Is this really necessary Vir Campestris <vir.campestris@invalid.invalid> - 2021-06-06 21:27 +0100
Re: Is this really necessary "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-06-07 00:22 +0200
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-06-07 14:53 +0000
Re: Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-07 18:02 +0200
Re: Is this really necessary Vir Campestris <vir.campestris@invalid.invalid> - 2021-06-16 21:38 +0100
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-06-07 14:52 +0000
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-12 03:50 -0700 |
| Message-ID | <86y297x7fz.fsf@linuxsc.com> |
| In reply to | #80858 |
mickspud@downthefarm.com writes: > On Wed, 11 Aug 2021 12:40:38 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> right from the get go. The developers there are real geniuses, >> who knows what they might have come up with. > > If they're the same level of genius as MS's current UI designers > then the internals of the windows kernel are probably a horror show. > >> there is only one at a time. In addition to malloc() there is >> also free(). I ran a test case (on a 32-bit linux system) that >> allocated five large memory regions, one at a time, each of which >> was larger than 2 GB (and so larger than PTRDIFF_MAX in that >> C implementation). > > Which probably underlines the fact that - despite what some > people on here seem to think - no one uses that macro or the > ptrdiff_t type. Any C program that subtracts one pointer value from another depends on the definition of ptrdiff_t, whether the program's author is aware of that fact or not. > It would be trivial to simply use (u)int64_t on a 32 bit system > instead. It isn't possible to avoid depending on the definition of ptrdiff_t in C code that subtracts pointer values. There is no way to substitute another type in such cases.
[toc] | [prev] | [next] | [standalone]
| From | mickspud@downthefarm.com |
|---|---|
| Date | 2021-08-12 14:58 +0000 |
| Message-ID | <sf3cu8$1hga$1@gioia.aioe.org> |
| In reply to | #80860 |
On Thu, 12 Aug 2021 03:50:56 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >mickspud@downthefarm.com writes: > >> On Wed, 11 Aug 2021 12:40:38 -0700 >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> >>> right from the get go. The developers there are real geniuses, >>> who knows what they might have come up with. >> >> If they're the same level of genius as MS's current UI designers >> then the internals of the windows kernel are probably a horror show. >> >>> there is only one at a time. In addition to malloc() there is >>> also free(). I ran a test case (on a 32-bit linux system) that >>> allocated five large memory regions, one at a time, each of which >>> was larger than 2 GB (and so larger than PTRDIFF_MAX in that >>> C implementation). >> >> Which probably underlines the fact that - despite what some >> people on here seem to think - no one uses that macro or the >> ptrdiff_t type. > >Any C program that subtracts one pointer value from another >depends on the definition of ptrdiff_t, whether the program's >author is aware of that fact or not. > >> It would be trivial to simply use (u)int64_t on a 32 bit system >> instead. > >It isn't possible to avoid depending on the definition of >ptrdiff_t in C code that subtracts pointer values. There is no >way to substitute another type in such cases. Rubbish. Memory addresses are simply numbers, not voodoo.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-12 08:29 -0700 |
| Message-ID | <86tujuy93d.fsf@linuxsc.com> |
| In reply to | #80861 |
mickspud@downthefarm.com writes: > On Thu, 12 Aug 2021 03:50:56 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> mickspud@downthefarm.com writes: >> >>> On Wed, 11 Aug 2021 12:40:38 -0700 >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> right from the get go. The developers there are real geniuses, >>>> who knows what they might have come up with. >>> >>> If they're the same level of genius as MS's current UI designers >>> then the internals of the windows kernel are probably a horror show. >>> >>>> there is only one at a time. In addition to malloc() there is >>>> also free(). I ran a test case (on a 32-bit linux system) that >>>> allocated five large memory regions, one at a time, each of which >>>> was larger than 2 GB (and so larger than PTRDIFF_MAX in that >>>> C implementation). >>> >>> Which probably underlines the fact that - despite what some >>> people on here seem to think - no one uses that macro or the >>> ptrdiff_t type. >> >> Any C program that subtracts one pointer value from another >> depends on the definition of ptrdiff_t, whether the program's >> author is aware of that fact or not. >> >>> It would be trivial to simply use (u)int64_t on a 32 bit system >>> instead. >> >> It isn't possible to avoid depending on the definition of >> ptrdiff_t in C code that subtracts pointer values. There is no >> way to substitute another type in such cases. > > Rubbish. Memory addresses are simply numbers, The C standard says otherwise, which is easy to verify. C implementations follow the semantic descriptions given in the C standard, which is also easy to verify.
[toc] | [prev] | [next] | [standalone]
| From | mickspud@downthefarm.com |
|---|---|
| Date | 2021-08-12 15:39 +0000 |
| Message-ID | <sf3fb0$m7g$1@gioia.aioe.org> |
| In reply to | #80862 |
On Thu, 12 Aug 2021 08:29:58 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >mickspud@downthefarm.com writes: > >> On Thu, 12 Aug 2021 03:50:56 -0700 >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> >>> mickspud@downthefarm.com writes: >>> >>>> On Wed, 11 Aug 2021 12:40:38 -0700 >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>>> >>>>> right from the get go. The developers there are real geniuses, >>>>> who knows what they might have come up with. >>>> >>>> If they're the same level of genius as MS's current UI designers >>>> then the internals of the windows kernel are probably a horror show. >>>> >>>>> there is only one at a time. In addition to malloc() there is >>>>> also free(). I ran a test case (on a 32-bit linux system) that >>>>> allocated five large memory regions, one at a time, each of which >>>>> was larger than 2 GB (and so larger than PTRDIFF_MAX in that >>>>> C implementation). >>>> >>>> Which probably underlines the fact that - despite what some >>>> people on here seem to think - no one uses that macro or the >>>> ptrdiff_t type. >>> >>> Any C program that subtracts one pointer value from another >>> depends on the definition of ptrdiff_t, whether the program's >>> author is aware of that fact or not. >>> >>>> It would be trivial to simply use (u)int64_t on a 32 bit system >>>> instead. >>> >>> It isn't possible to avoid depending on the definition of >>> ptrdiff_t in C code that subtracts pointer values. There is no >>> way to substitute another type in such cases. >> >> Rubbish. Memory addresses are simply numbers, > >The C standard says otherwise, which is easy to verify. Ah ok. What are they then, ascii strings? >C implementations follow the semantic descriptions given in >the C standard, which is also easy to verify. I don't need to verify anything, pointer values are numbers. They may have seperate parts and addressing might not be linear on some archaic CPUs, but they're numbers, end of.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-08-12 20:07 +0300 |
| Message-ID | <sf3kgp$kh9$1@dont-email.me> |
| In reply to | #80863 |
12.08.2021 18:39 mickspud@downthefarm.com kirjutas: > On Thu, 12 Aug 2021 08:29:58 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> mickspud@downthefarm.com writes: >> >>> On Thu, 12 Aug 2021 03:50:56 -0700 >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> mickspud@downthefarm.com writes: >>>> >>>>> On Wed, 11 Aug 2021 12:40:38 -0700 >>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>>>> >>>>>> right from the get go. The developers there are real geniuses, >>>>>> who knows what they might have come up with. >>>>> >>>>> If they're the same level of genius as MS's current UI designers >>>>> then the internals of the windows kernel are probably a horror show. >>>>> >>>>>> there is only one at a time. In addition to malloc() there is >>>>>> also free(). I ran a test case (on a 32-bit linux system) that >>>>>> allocated five large memory regions, one at a time, each of which >>>>>> was larger than 2 GB (and so larger than PTRDIFF_MAX in that >>>>>> C implementation). >>>>> >>>>> Which probably underlines the fact that - despite what some >>>>> people on here seem to think - no one uses that macro or the >>>>> ptrdiff_t type. >>>> >>>> Any C program that subtracts one pointer value from another >>>> depends on the definition of ptrdiff_t, whether the program's >>>> author is aware of that fact or not. >>>> >>>>> It would be trivial to simply use (u)int64_t on a 32 bit system >>>>> instead. >>>> >>>> It isn't possible to avoid depending on the definition of >>>> ptrdiff_t in C code that subtracts pointer values. There is no >>>> way to substitute another type in such cases. >>> >>> Rubbish. Memory addresses are simply numbers, >> >> The C standard says otherwise, which is easy to verify. > > Ah ok. What are they then, ascii strings? > >> C implementations follow the semantic descriptions given in >> the C standard, which is also easy to verify. > > I don't need to verify anything, pointer values are numbers. They may have > seperate parts and addressing might not be linear on some archaic CPUs, but > they're numbers, end of. I think what Tim wants to say is that when calculating the difference of pointers, the result is inherently ptrdiff_t. If this is inadequate for holding the actual difference, then it's already too late to convert it to int64, it is already ruined. For making >2GB differences to always work reliably in 32-bit program one needs to cast the pointers themselves first to an (u)int64 type, then subtract. But then it is not subtraction of pointers any more. This is not obvious and not trivial. Luckily it won't come up often in practice, >2GB byte arrays in 32-bit programs are rare.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-08-13 07:16 +0000 |
| Message-ID | <sf568p$1o4o$1@gioia.aioe.org> |
| In reply to | #80864 |
Paavo Helde <myfirstname@osa.pri.ee> wrote: > For making >2GB differences to always work reliably in 32-bit program > one needs to cast the pointers themselves first to an (u)int64 type, > then subtract. But then it is not subtraction of pointers any more. This works in practice, but if we are *really* strict about the standard, converting a pointer to an integer is not guaranteed to work (without loss of information). The C standard states: "Any pointer type may be converted to an integer type. Except as previously specified, the result is implementation-defined. If the result cannot be represented in the integer type, the behavior is undefined. The result need not be in the range of values of any integer type." Notice particularly the last sentence (and, consequently, the second-last sentence.) So, you can do it, but it's not guaranteed to give you the correct result that you expect. I assume the C++ standard says something similar.
[toc] | [prev] | [next] | [standalone]
| From | mickspud@downthefarm.com |
|---|---|
| Date | 2021-08-13 09:26 +0000 |
| Message-ID | <sf5dsc$1346$1@gioia.aioe.org> |
| In reply to | #80866 |
On Fri, 13 Aug 2021 07:16:43 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >Paavo Helde <myfirstname@osa.pri.ee> wrote: >> For making >2GB differences to always work reliably in 32-bit program >> one needs to cast the pointers themselves first to an (u)int64 type, >> then subtract. But then it is not subtraction of pointers any more. > >This works in practice, but if we are *really* strict about the standard, >converting a pointer to an integer is not guaranteed to work (without >loss of information). The C standard states: > >"Any pointer type may be converted to an integer type. Except as previously >specified, the result is implementation-defined. If the result cannot be >represented in the integer type, the behavior is undefined. The result need >not be in the range of values of any integer type." That sounds like simple arse covering. If unsigned long or unsigned long long on a system arn't large enough to hold INT_MAX or its 64 bit equivalent and yet somehow the compiler can still work with even larger numbers as memory addresses then either the compiler has been deliberately crippled or the CPU must use an entirely seperate set of registers to process addresses alone. Which would be an ... interesting design.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-08-13 10:30 -0400 |
| Message-ID | <sf5vlo$c8d$1@dont-email.me> |
| In reply to | #80868 |
On 8/13/21 5:26 AM, mickspud@downthefarm.com wrote: > On Fri, 13 Aug 2021 07:16:43 -0000 (UTC) > Juha Nieminen <nospam@thanks.invalid> wrote: ... >> This works in practice, but if we are *really* strict about the standard, >> converting a pointer to an integer is not guaranteed to work (without >> loss of information). The C standard states: >> >> "Any pointer type may be converted to an integer type. Except as previously >> specified, the result is implementation-defined. If the result cannot be >> represented in the integer type, the behavior is undefined. The result need >> not be in the range of values of any integer type." > > That sounds like simple arse covering. ... More like the advanced version: the committee knew of platforms which would not allow efficient implementation of an integer type that was wide enough to store a distinct value for all possible addresses. They wanted to make sure that a conforming implementation of C would be possible on such systems. They therefore deliberately chose to write the specification lenient enough to allow such implementations.
[toc] | [prev] | [next] | [standalone]
| From | mickspud@downthefarm.com |
|---|---|
| Date | 2021-08-13 14:58 +0000 |
| Message-ID | <sf61a8$1q4o$1@gioia.aioe.org> |
| In reply to | #80870 |
On Fri, 13 Aug 2021 10:30:15 -0400 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >On 8/13/21 5:26 AM, mickspud@downthefarm.com wrote: >> On Fri, 13 Aug 2021 07:16:43 -0000 (UTC) >> Juha Nieminen <nospam@thanks.invalid> wrote: >.... >>> This works in practice, but if we are *really* strict about the standard, >>> converting a pointer to an integer is not guaranteed to work (without >>> loss of information). The C standard states: >>> >>> "Any pointer type may be converted to an integer type. Except as previously >>> specified, the result is implementation-defined. If the result cannot be >>> represented in the integer type, the behavior is undefined. The result need >>> not be in the range of values of any integer type." >> >> That sounds like simple arse covering. ... > >More like the advanced version: the committee knew of platforms which >would not allow efficient implementation of an integer type that was >wide enough to store a distinct value for all possible addresses. They Not allow efficient and not allow at all are 2 different things.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-08-14 08:07 +0000 |
| Message-ID | <sf7tj8$1rfk$1@gioia.aioe.org> |
| In reply to | #80873 |
mickspud@downthefarm.com wrote: > On Fri, 13 Aug 2021 10:30:15 -0400 > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>On 8/13/21 5:26 AM, mickspud@downthefarm.com wrote: >>> On Fri, 13 Aug 2021 07:16:43 -0000 (UTC) >>> Juha Nieminen <nospam@thanks.invalid> wrote: >>.... >>>> This works in practice, but if we are *really* strict about the standard, >>>> converting a pointer to an integer is not guaranteed to work (without >>>> loss of information). The C standard states: >>>> >>>> "Any pointer type may be converted to an integer type. Except as previously >>>> specified, the result is implementation-defined. If the result cannot be >>>> represented in the integer type, the behavior is undefined. The result need >>>> not be in the range of values of any integer type." >>> >>> That sounds like simple arse covering. ... >> >>More like the advanced version: the committee knew of platforms which >>would not allow efficient implementation of an integer type that was >>wide enough to store a distinct value for all possible addresses. They > > Not allow efficient and not allow at all are 2 different things. Undefined behavior does not mean "this is not allowed". It simply means that the behavior isn't guaranteed, and it may depend on the compiler and the architecture (or anything else, for that matter).
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-08-14 10:40 -0700 |
| Message-ID | <a5a36df4-aacf-4d10-956d-a67171073815n@googlegroups.com> |
| In reply to | #80876 |
On Saturday, August 14, 2021 at 4:07:23 AM UTC-4, Juha Nieminen wrote: > mick...@downthefarm.com wrote: > > On Fri, 13 Aug 2021 10:30:15 -0400 > > James Kuyper <james...@alumni.caltech.edu> wrote: ... > >>More like the advanced version: the committee knew of platforms which > >>would not allow efficient implementation of an integer type that was > >>wide enough to store a distinct value for all possible addresses. They > > > > Not allow efficient and not allow at all are 2 different things. > Undefined behavior does not mean "this is not allowed". It simply means > that the behavior isn't guaranteed, and it may depend on the compiler > and the architecture (or anything else, for that matter). I was talking about what the platform would allow, not about what the standard would allow.
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-08-14 10:38 -0700 |
| Message-ID | <6999fbe0-c3c3-4aa5-ba68-d1813cebc3d8n@googlegroups.com> |
| In reply to | #80873 |
On Friday, August 13, 2021 at 10:58:32 AM UTC-4, mick...@downthefarm.com wrote: > On Fri, 13 Aug 2021 10:30:15 -0400 > James Kuyper <james...@alumni.caltech.edu> wrote: ... > >More like the advanced version: the committee knew of platforms which > >would not allow efficient implementation of an integer type that was > >wide enough to store a distinct value for all possible addresses. They > Not allow efficient and not allow at all are 2 different things. Agreed - which is why I was very careful to use the term that correctly conveyed the meaning that I intended. Any platform that allows implementation of C would also allow emulation of int_leastN_t for virtually any reasonable value of N, but those emulations would be unacceptably inefficient for any value of N that is too large - and the inefficiency of those emulations is a valid concern.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2021-08-13 15:30 +0200 |
| Message-ID | <sf5s5l$j75$1@dont-email.me> |
| In reply to | #80866 |
On 13 Aug 2021 09:16, Juha Nieminen wrote: > Paavo Helde <myfirstname@osa.pri.ee> wrote: >> For making >2GB differences to always work reliably in 32-bit program >> one needs to cast the pointers themselves first to an (u)int64 type, >> then subtract. But then it is not subtraction of pointers any more. > > This works in practice, but if we are *really* strict about the standard, > converting a pointer to an integer is not guaranteed to work (without > loss of information). The C standard states: > > "Any pointer type may be converted to an integer type. Except as previously > specified, the result is implementation-defined. If the result cannot be > represented in the integer type, the behavior is undefined. The result need > not be in the range of values of any integer type." > > Notice particularly the last sentence (and, consequently, the second-last > sentence.) > > So, you can do it, but it's not guaranteed to give you the correct result > that you expect. If the implementation provides `uintptr_t` then you're guaranteed a correct result for roundtrip conversion. C99: "any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer" > I assume the C++ standard says something similar. The C++ standard implicitly adopts the C standard's requirements. In C++03 this was perhaps more clear because then the standard stated that the C standard "is incorporated into this Standard by reference". - Alf
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-08-13 11:18 -0700 |
| Message-ID | <874kbti4yp.fsf@nosuchdomain.example.com> |
| In reply to | #80869 |
"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
> On 13 Aug 2021 09:16, Juha Nieminen wrote:
>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>> For making >2GB differences to always work reliably in 32-bit program
>>> one needs to cast the pointers themselves first to an (u)int64 type,
>>> then subtract. But then it is not subtraction of pointers any more.
>> This works in practice, but if we are *really* strict about the
>> standard,
>> converting a pointer to an integer is not guaranteed to work (without
>> loss of information). The C standard states:
>> "Any pointer type may be converted to an integer type. Except as
>> previously
>> specified, the result is implementation-defined. If the result cannot be
>> represented in the integer type, the behavior is undefined. The result need
>> not be in the range of values of any integer type."
>> Notice particularly the last sentence (and, consequently, the
>> second-last
>> sentence.)
>> So, you can do it, but it's not guaranteed to give you the correct
>> result
>> that you expect.
>
> If the implementation provides `uintptr_t` then you're guaranteed a
> correct result for roundtrip conversion.
>
> C99: "any valid pointer to void can be converted to this type, then
> converted back to pointer to void, and the result will compare equal
> to the original pointer"
>
>> I assume the C++ standard says something similar.
>
> The C++ standard implicitly adopts the C standard's requirements.
>
> In C++03 this was perhaps more clear because then the standard stated
> that the C standard "is incorporated into this Standard by reference".
The wording in C++03 is a bit vague.
17.3.1.4 C Library [lib.structure.see.also]
Paragraphs labelled "SEE ALSO:" contain cross-references to the
relevant portions of this Standard and the ISO C standard, which is
incorporated into this Standard by reference.
That could be read to imply that the entire C standard is included by
reference, but I believe it refers only to the library section (section
7). For example the behavior of printf for C++ is specified by
reference to the C standard, but the behavior of addition is specified
in the C++ standard itself -- and the C standard's specification of the
type of character constants, for example, does not apply to C++.
C++ defines its own semantics for integer/pointer conversions (and its
specification happens to be very close to C's). C's specification for
<stdint.h>, where uintptr_t is defined, applies to C++ (and a C++
implementation won't define uintptr_t if it has no integer type that
meets is requirements).
--
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 | 2021-08-14 03:20 -0700 |
| Message-ID | <86a6lkxr7s.fsf@linuxsc.com> |
| In reply to | #80875 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > "Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes: > >> On 13 Aug 2021 09:16, Juha Nieminen wrote: >> >>> Paavo Helde <myfirstname@osa.pri.ee> wrote: >>> >>>> For making >2GB differences to always work reliably in 32-bit >>>> program one needs to cast the pointers themselves first to an >>>> (u)int64 type, then subtract. But then it is not subtraction of >>>> pointers any more. >>> >>> This works in practice, but if we are *really* strict about the >>> standard, converting a pointer to an integer is not guaranteed to >>> work (without loss of information). The C standard states: >>> >>> "Any pointer type may be converted to an integer type. Except as >>> previously specified, the result is implementation-defined. If >>> the result cannot be represented in the integer type, the behavior >>> is undefined. The result need not be in the range of values of >>> any integer type." >>> >>> Notice particularly the last sentence (and, consequently, the >>> second-last sentence.) >>> >>> So, you can do it, but it's not guaranteed to give you the correct >>> result that you expect. >> >> If the implementation provides `uintptr_t` then you're guaranteed a >> correct result for roundtrip conversion. >> >> C99: "any valid pointer to void can be converted to this type, >> then converted back to pointer to void, and the result will compare >> equal to the original pointer" >> >>> I assume the C++ standard says something similar. >> >> The C++ standard implicitly adopts the C standard's requirements. >> >> In C++03 this was perhaps more clear because then the standard >> stated that the C standard "is incorporated into this Standard by >> reference". > > The wording in C++03 is a bit vague. > > 17.3.1.4 C Library [lib.structure.see.also] > > Paragraphs labelled "SEE ALSO:" contain cross-references to > the relevant portions of this Standard and the ISO C standard, > which is incorporated into this Standard by reference. > > That could be read to imply that the entire C standard is included > by reference, [...] There is no ambiguity in this sentence about what phrase is being referenced for incorporation, and that is the (entire) ISO C standard. If it were meant to incorporate only some portions of the ISO C standard, the sentence would have said "which _are_ incorporated" rather than "which _is_ incorporated".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-08-14 13:24 -0700 |
| Message-ID | <87zgtjhizw.fsf@nosuchdomain.example.com> |
| In reply to | #80881 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> The wording in C++03 is a bit vague.
>>
>> 17.3.1.4 C Library [lib.structure.see.also]
>>
>> Paragraphs labelled "SEE ALSO:" contain cross-references to
>> the relevant portions of this Standard and the ISO C standard,
>> which is incorporated into this Standard by reference.
>>
>> That could be read to imply that the entire C standard is included
>> by reference, [...]
>
> There is no ambiguity in this sentence about what phrase is being
> referenced for incorporation, and that is the (entire) ISO C
> standard. If it were meant to incorporate only some portions of
> the ISO C standard, the sentence would have said "which _are_
> incorporated" rather than "which _is_ incorporated".
(For those not familiar with the C standard, section 6 defines the core
language and section 7 defines the library.)
I agree that it *says* that the entire C standard is incorporated, but
I'm not convinced that was the intent. I admittedly let my assumptions
influence how I read it.
In the C++11 standard, the section is:
17.5.1.5 [structure.see.also]
Paragraphs labeled “See also:” contain cross-references to
the relevant portions of this International Standard and the ISO
C standard, which is incorporated into this International Standard
by reference.
In C++17 (in the draft I have), it changed to:
20.4.1.5 [structure.see.also]
Paragraphs labeled “See also:” contain cross-references to
the relevant portions of the ISO C standard.
I don't believe any of the following "See also" references point to
anything in section 6 of the C standard. Most of them refer to other
sections of the C++ standard, most of the rest refer to ISO C section 7,
and a handful refer to section 5, which is where the C standard defines
<limits.h> and <float.h>.
As far as I know, nothing in the C++ standard depends on section 6 of
the C standard. The core language is defined from scratch.
Whether the C++ standard incorporates the entire C standard or not, it
doesn't *need* to incorporate section 6 -- and as of C++17, that wording
was removed. The change was made in response to
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0063r3.html
"C++17 should refer to C11 instead of C99"
https://github.com/cplusplus/draft commit 6b05dff5
--
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-08-14 20:33 +0000 |
| Message-ID | <sf99bi$ggn$1@gioia.aioe.org> |
| In reply to | #80886 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > In the C++11 standard, the section is: > > 17.5.1.5 [structure.see.also] > > Paragraphs labeled ?See also:? contain cross-references to > the relevant portions of this International Standard and the ISO > C standard, which is incorporated into this International Standard > by reference. I understand that to mean "the referenced parts should be considered part of this standard as well". In other words, *only* the referenced parts. I could be wrong, of course.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-08-15 00:40 -0400 |
| Message-ID | <sfa5re$qq3$1@dont-email.me> |
| In reply to | #80887 |
On 8/14/21 4:33 PM, Juha Nieminen wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> In the C++11 standard, the section is: >> >> 17.5.1.5 [structure.see.also] >> >> Paragraphs labeled ?See also:? contain cross-references to >> the relevant portions of this International Standard and the ISO >> C standard, which is incorporated into this International Standard >> by reference. > > I understand that to mean "the referenced parts should be considered > part of this standard as well". In other words, *only* the referenced > parts. > > I could be wrong, of course. As Tim pointed out, that interpretation is inconsistent with the use of the singular verb - "referenced parts" is plural. There's a simple, obvious singular thing that is the corresponding subject, and that's "the ISO C standard". As Keith pointed out, while this is linguistically correct, it's probably not the intent. Virtually the entirety of section 6 of the C standard is duplicated in the C++ standard, with modifications that in many places make it incompatible with the the wording in the C standard, making it questionable what it would mean for section 6 to be incorporated by reference. The changed wording in C++2017 is almost certainly what was intended all along.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-15 07:02 -0700 |
| Message-ID | <86sfzax0ur.fsf@linuxsc.com> |
| In reply to | #80886 |
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:
>
> [...]
>
>>> The wording in C++03 is a bit vague.
>>>
>>> 17.3.1.4 C Library [lib.structure.see.also]
>>>
>>> Paragraphs labelled "SEE ALSO:" contain cross-references to
>>> the relevant portions of this Standard and the ISO C standard,
>>> which is incorporated into this Standard by reference.
>>>
>>> That could be read to imply that the entire C standard is included
>>> by reference, [...]
>>
>> There is no ambiguity in this sentence about what phrase is being
>> referenced for incorporation, and that is the (entire) ISO C
>> standard. If it were meant to incorporate only some portions of
>> the ISO C standard, the sentence would have said "which _are_
>> incorporated" rather than "which _is_ incorporated".
>
> (For those not familiar with the C standard, section 6 defines the
> core language and section 7 defines the library.)
>
> I agree that it *says* that the entire C standard is incorporated,
> but I'm not convinced that was the intent. I admittedly let my
> assumptions influence how I read it.
I think the intent matches the most literal reading of the words:
the C++ standard incorporates the C standard. That doesn't mean
the C++ /language/ incorporates the C /language/, only that a C++
/document/ incorporates a C /document/. Incorporating the ISO C
standard does not by itself affect the _semantics_ of C++; in
areas where it is important for C++ to adopt the semantics of
some part of C, that is done using an explicit reference to the
incorporated C standard.
> In the C++11 standard, the section is:
>
> 17.5.1.5 [structure.see.also]
>
> Paragraphs labeled ?See also:? contain cross-references to the
> relevant portions of this International Standard and the ISO C
> standard, which is incorporated into this International
> Standard by reference.
Yes, AFAICT the wording of this paragraph is the same from C++98 to
C++14, except that C++11 and C++14 insert the word "International"
between "this" and "Standard".
> In C++17 (in the draft I have), it changed to:
>
> 20.4.1.5 [structure.see.also]
>
> Paragraphs labeled ?See also:? contain cross-references to
> the relevant portions of the ISO C standard.
In N4659, dated 2017-03-21, 20.4.1.5 p1 says this:
Paragraphs labeled "See also:" contain cross-references to
the relevant portions of this International Standard and the
ISO C standard.
Note by the way that section 20.4 is informative, not normative.
The same is true of the subsection containing the requisite
paragraph (that "incorporates" an ISO C standard) in C++98,
C++03, C++11, and C++14.
> I don't believe any of the following "See also" references point
> to anything in section 6 of the C standard. Most of them refer to
> other sections of the C++ standard, most of the rest refer to ISO
> C section 7, and a handful refer to section 5, which is where the
> C standard defines <limits.h> and <float.h>.
>
> As far as I know, nothing in the C++ standard depends on section 6
> of the C standard. The core language is defined from scratch.
AFAIK the same is true of C++98, C++03, C++11, and C++14, and
that is consistent with those instances of the C++ standard
having incorporated (some instance of) the ISO C standard.
> Whether the C++ standard incorporates the entire C standard or
> not, it doesn't *need* to incorporate section 6 -- and as of
> C++17, that wording was removed.
Apparently nothing *needs* to be incorporated, since in C++17
nothing was. It's an editorial choice, nothing more, and has no
effect on the C++ language being defined.
> The change was made in response to
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0063r3.html
> "C++17 should refer to C11 instead of C99"
> https://github.com/cplusplus/draft commit 6b05dff5
I didn't read the document, but judging from the quoted summary
the decision to take out the "is incorporated" clause looks like
an independent change. Again, simply an editorial choice, and
that is reinforced by section 20.4 being informative rather than
normative.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2021-08-15 21:19 +0200 |
| Message-ID | <sfbpbm$rqj$1@dont-email.me> |
| In reply to | #80890 |
On 15 Aug 2021 16:02, Tim Rentsch wrote: > [snip] >> Whether the C++ standard incorporates the entire C standard or >> not, it doesn't *need* to incorporate section 6 -- and as of >> C++17, that wording was removed. > > Apparently nothing *needs* to be incorporated, since in C++17 > nothing was. It's an editorial choice, nothing more, and has no > effect on the C++ language being defined. The minimum ranges for integer types, except `char`, are not specified explicitly in the C++ standard, and as I recall there's not even a specific reference to the C standard for that. Yet these ranges are provided by the C standard. Any reasonable interpretation has to make that happen. - Alf
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c++
csiph-web