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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-08-15 15:42 -0400 |
| Message-ID | <57eSI.14101$fI7.9948@fx33.iad> |
| In reply to | #80891 |
On 8/15/21 3:19 PM, Alf P. Steinbach wrote: > 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 17.3.6 Header <climits> synopsis 1 The header <climits> defines all macros the same as the C standard library header <limits.h>. This at least seems to pull in the C standard definitions which include their allowable range. (From N4860] Other versions had some sort of similar reference to climits and limits.h that at least imply that these macros have the same sort of values.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-21 12:38 -0700 |
| Message-ID | <86o89qwpus.fsf@linuxsc.com> |
| In reply to | #80891 |
"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes: > 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. My point is that no part of the C standard needs to be *incorporated* for that reliance to take place. Any dependency on the restrictions of types in C can be (and apparently has been) worked into the C++ standard without doing any "incorporating" of the C standard.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-08-14 08:13 +0000 |
| Message-ID | <sf7tus$1rfk$2@gioia.aioe.org> |
| In reply to | #80869 |
Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote: > 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. Yes, but alas, support for uintptr_t is optional, both in C and C++ (probably because of that part of the standard I quoted, which would allow an architecture where pointers are larger than any integer type).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-14 02:58 -0700 |
| Message-ID | <86im08xs96.fsf@linuxsc.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". Note that there is some ambiguity as to which C standard is being referenced here. The Normative References list ISO/IEC 9899:1999, but section 1.1 p2 says "C++ is a general purpose programming language based on the C programming language as described in ISO/IEC 9899:1990", and section 1.2 p2 (also in Normative References) says "The library described in clause 7 of ISO/IEC 9899:1990 and clause 7 of ISO/IEC 9899/Amd.1:1995 is hereinafter called the Standard C Library."
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-13 14:32 +0000 |
| Message-ID | <rovRI.23525$NQ1.15492@fx48.iad> |
| In reply to | #80866 |
Juha Nieminen <nospam@thanks.invalid> writes: >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. Indeed. Here's a research project that includes pointers larger than the largest native integer type. https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-14 02:28 -0700 |
| Message-ID | <86mtpkxtn0.fsf@linuxsc.com> |
| In reply to | #80864 |
Paavo Helde <myfirstname@osa.pri.ee> writes: > 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. Thank you for giving this alternate formulation. I myself would not have said exactly this, but indeed it might help some people understand who would not have otherwise. > 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. I'm extremely reluctant either to use or to recommend operating on values that result from converting pointers to integers, and this case is no exception. If it is necessary to deal with the possibility of such circumstances I think there are better ways to do that (and would rather not elaborate further just now). > 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. Surprisingly it can come up in "garden variety" C code, and that is worth knowing and guarding against. Probably the easiest way to protect against it is to limit the sizes of malloc() calls (and other potential object allocation methods) to PTRDIFF_MAX.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-14 03:00 -0700 |
| Message-ID | <86eeawxs4w.fsf@linuxsc.com> |
| In reply to | #80863 |
mickspud@downthefarm.com writes: > 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'm sorry our conversation has not been more productive.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-08-14 14:03 +0100 |
| Message-ID | <sf8euj$nea$1@dont-email.me> |
| In reply to | #80863 |
On 12/08/2021 16:39, mickspud@downthefarm.com wrote: > On Thu, 12 Aug 2021 08:29:58 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> mickspud@downthefarm.com writes: >>> 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 assume that by numbers, you mean integers? Pointers are bit patterns. So are floating point representations, but you don't call them integers because usually you interpret the patterns very differently. It could be that on most hardware, pointers are only exposed as linear byte offsets, so share some characteristics with integers. But usually you can't meaningfully add pointers together, or multiply them. And subtraction only works between compatible pointers to the same type, of the same alignment, and, for C language (I guess C++ too), between objects within the same contiguous memory block. There is normally no such restriction on subtracting two integers. The result is not scaled either. However, when you subtract two u64 integers A and B, the A-B result will be u64 too; you have similar problems if you need a signed result, because i64 can't represent all possible results (you need i65 or i128). But the language here says that A-B is legal and the result is meaningful even when A<B.
[toc] | [prev] | [next] | [standalone]
| From | mickspud@downthefarm.com |
|---|---|
| Date | 2021-08-14 15:06 +0000 |
| Message-ID | <sf8m5g$5p8$1@gioia.aioe.org> |
| In reply to | #80882 |
On Sat, 14 Aug 2021 14:03:03 +0100 Bart <bc@freeuk.com> wrote: >On 12/08/2021 16:39, mickspud@downthefarm.com wrote: >> On Thu, 12 Aug 2021 08:29:58 -0700 >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> mickspud@downthefarm.com writes: > >>>> 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 assume that by numbers, you mean integers? Ints, longs, long long, uint64_t, take your pick. >Pointers are bit patterns. So are floating point representations, but >you don't call them integers because usually you interpret the patterns >very differently. The point is they can all be assigned to and read as numbers. >It could be that on most hardware, pointers are only exposed as linear >byte offsets, so share some characteristics with integers. But usually >you can't meaningfully add pointers together, or multiply them. All sane OSs expose virtual memory as linear and essentially unlimited up to the maximum value the address registers in the MMU can operate on. >However, when you subtract two u64 integers A and B, the A-B result will >be u64 too; you have similar problems if you need a signed result, >because i64 can't represent all possible results (you need i65 or i128). > >But the language here says that A-B is legal and the result is >meaningful even when A<B. diff = A > B ? (A - B) : (B - A)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-08-12 12:06 -0700 |
| Message-ID | <sf3rft$5ph$1@gioia.aioe.org> |
| In reply to | #80858 |
On 8/12/2021 1:20 AM, mickspud@downthefarm.com wrote: > 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. https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos > >> 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. It would be > trivial to simply use (u)int64_t on a 32 bit system instead. >
[toc] | [prev] | [next] | [standalone]
| From | mickspud@downthefarm.com |
|---|---|
| Date | 2021-08-13 09:19 +0000 |
| Message-ID | <sf5dfs$tkf$1@gioia.aioe.org> |
| In reply to | #80865 |
On Thu, 12 Aug 2021 12:06:35 -0700 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote: >On 8/12/2021 1:20 AM, mickspud@downthefarm.com wrote: >> 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. > > >https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos Is that legal? Regardless, I suspect the original version of the NT kernel as designed by dave cutler was nice and clean as it didn't have to support any of the cruft of Win 3.1 or 95. I doubt the same could be said for the Win10 kernel after 30 years of hacks and bodges. Even the linux kernel has been suffering from bloat for some time now.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-13 14:35 +0000 |
| Message-ID | <xqvRI.23526$NQ1.21018@fx48.iad> |
| In reply to | #80867 |
mickspud@downthefarm.com writes: >On Thu, 12 Aug 2021 12:06:35 -0700 >"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote: >>On 8/12/2021 1:20 AM, mickspud@downthefarm.com wrote: >>> 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. >> >> >>https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos > >Is that legal? Regardless, I suspect the original version of the NT kernel >as designed by dave cutler was nice and clean as it didn't have to support >any of the cruft of Win 3.1 or 95. Ah, but it _did_ have to support the cruft of earlier operating systems - and it did that through a subsystem called WoW (Windows on Windows), which you'll find in the aforementioned source distribution.
[toc] | [prev] | [next] | [standalone]
| From | mickspud@downthefarm.com |
|---|---|
| Date | 2021-08-13 14:58 +0000 |
| Message-ID | <sf61bd$1q5m$1@gioia.aioe.org> |
| In reply to | #80872 |
On Fri, 13 Aug 2021 14:35:09 GMT scott@slp53.sl.home (Scott Lurndal) wrote: >mickspud@downthefarm.com writes: >>On Thu, 12 Aug 2021 12:06:35 -0700 >>"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote: >>>On 8/12/2021 1:20 AM, mickspud@downthefarm.com wrote: >>>> 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. >>> >>> >>>https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos >> >>Is that legal? Regardless, I suspect the original version of the NT kernel >>as designed by dave cutler was nice and clean as it didn't have to support >>any of the cruft of Win 3.1 or 95. > >Ah, but it _did_ have to support the cruft of earlier operating >systems - and it did that through a subsystem called WoW (Windows on Windows), >which you'll find in the aforementioned source distribution. WoW is a seperate process, its not part of the kernel.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-10 15:03 +0000 |
| Message-ID | <mzwQI.20478$6p.16127@fx36.iad> |
| In reply to | #80823 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >Vir Campestris <vir.campestris@invalid.invalid> writes: > >[..stuff about 64 bit systems removed..] > >> What bothers me about ptr_diff_t is the size. The difference between >> two 32-bit pointers is plus or minus 4GB. Which needs a 33 bit value >> :( >> >> As it happens it's never been a practical problem as I've never had a >> 32 bit system with more than 2GB RAM, > >It isn't necessary for there to be more than 2GB of RAM for >problems with ptrdiff_t to manifest (in 32-bit linux). A call to >malloc() will gladly return a memory area larger than all of RAM >if there is swap space to hold it. Do recall the split address space in 32-bit intel/amd systems, which by default, limit the application to 2GB of virtual address space. Malloc can't return more than the available user-mode VA space allows.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-11 12:54 -0700 |
| Message-ID | <867dgrzrhp.fsf@linuxsc.com> |
| In reply to | #80834 |
scott@slp53.sl.home (Scott Lurndal) writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Vir Campestris <vir.campestris@invalid.invalid> writes: >> >> [..stuff about 64 bit systems removed..] >> >>> What bothers me about ptr_diff_t is the size. The difference between >>> two 32-bit pointers is plus or minus 4GB. Which needs a 33 bit value >>> :( >>> >>> As it happens it's never been a practical problem as I've never had a >>> 32 bit system with more than 2GB RAM, >> >> It isn't necessary for there to be more than 2GB of RAM for >> problems with ptrdiff_t to manifest (in 32-bit linux). A call to >> malloc() will gladly return a memory area larger than all of RAM >> if there is swap space to hold it. > > Do recall the split address space in 32-bit intel/amd systems, which > by default, limit the application to 2GB of virtual address space. > > Malloc can't return more than the available user-mode VA space > allows. Here is a data point. I have a small C program, which uses malloc() to allocate a large region of memory (once for each input file, which is processed and then the allocated memory is freed). Running the program on a 32-bit linux system (with standard amd or intel hardware), I observe malloc() successfully allocating an area larger than 2 GB. My comment above about problems with ptrdiff_t and about malloc() returning a memory area larger than all of RAM follows directly from first-hand experience. I respect your knowledge and understanding of many different operating systems. But I wasn't just talking through my hat up there.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-11 20:20 +0000 |
| Message-ID | <tiWQI.8823$cd2.5200@fx02.iad> |
| In reply to | #80856 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >scott@slp53.sl.home (Scott Lurndal) writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> Vir Campestris <vir.campestris@invalid.invalid> writes: >>> >>> [..stuff about 64 bit systems removed..] >>> >>>> What bothers me about ptr_diff_t is the size. The difference between >>>> two 32-bit pointers is plus or minus 4GB. Which needs a 33 bit value >>>> :( >>>> >>>> As it happens it's never been a practical problem as I've never had a >>>> 32 bit system with more than 2GB RAM, >>> >>> It isn't necessary for there to be more than 2GB of RAM for >>> problems with ptrdiff_t to manifest (in 32-bit linux). A call to >>> malloc() will gladly return a memory area larger than all of RAM >>> if there is swap space to hold it. >> >> Do recall the split address space in 32-bit intel/amd systems, which >> by default, limit the application to 2GB of virtual address space. >> >> Malloc can't return more than the available user-mode VA space >> allows. > >Here is a data point. I have a small C program, which uses >malloc() to allocate a large region of memory (once for each >input file, which is processed and then the allocated memory is >freed). Running the program on a 32-bit linux system (with >standard amd or intel hardware), I observe malloc() successfully >allocating an area larger than 2 GB. I suspect that your implementation of malloc (glibc?, libc? eglibc?) uses mmap() for very large allocations. In which case, the page table entries won't be allocated and updated until the first time each page is accessed. (If you use 'strace' and 'ltrace' on your applications, you'll be able to tell if brk/sbrk/mmap were used). Did you touch one byte every page in your malloc()d region? It's likely that the page table entry is only filled in when the physical page is actually allocated, and you'd get a SIGSEGV (or SIGBUS) when you touch a page that exceeds any of the resource limits or the user va split. ulimit -aH will show the hard resource limits for your process if any have been established. > My comment above about >problems with ptrdiff_t and about malloc() returning a memory >area larger than all of RAM follows directly from first-hand >experience. I'd have to setup a 32-bit linux system (all mine are 64-bit) to check this, but if you have the kernel config for your distribution, it should show you whether your system has a 2GB or 3GB split on the VA space. In the latter case, a 2GB allocation will succeed, in the former case, if it succeeds, you've identified a bug (perhaps related to lazy allocation), since there is no physical way for an application to access more virtual address space than the user-side of the split, unless the kernel gives up some of the low-end of the kernel VA space, which I don't recall linux ever doing.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-12 03:42 -0700 |
| Message-ID | <8635rfymea.fsf@linuxsc.com> |
| In reply to | #80857 |
scott@slp53.sl.home (Scott Lurndal) writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> scott@slp53.sl.home (Scott Lurndal) writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> >>>> Vir Campestris <vir.campestris@invalid.invalid> writes: >>>> >>>> [..stuff about 64 bit systems removed..] >>>> >>>>> What bothers me about ptr_diff_t is the size. The difference between >>>>> two 32-bit pointers is plus or minus 4GB. Which needs a 33 bit value >>>>> :( >>>>> >>>>> As it happens it's never been a practical problem as I've never had a >>>>> 32 bit system with more than 2GB RAM, >>>> >>>> It isn't necessary for there to be more than 2GB of RAM for >>>> problems with ptrdiff_t to manifest (in 32-bit linux). A call to >>>> malloc() will gladly return a memory area larger than all of RAM >>>> if there is swap space to hold it. >>> >>> Do recall the split address space in 32-bit intel/amd systems, which >>> by default, limit the application to 2GB of virtual address space. >>> >>> Malloc can't return more than the available user-mode VA space >>> allows. >> >> Here is a data point. I have a small C program, which uses >> malloc() to allocate a large region of memory (once for each >> input file, which is processed and then the allocated memory is >> freed). Running the program on a 32-bit linux system (with >> standard amd or intel hardware), I observe malloc() successfully >> allocating an area larger than 2 GB. > > I suspect that your implementation of malloc (glibc?, libc? > eglibc?) uses mmap() for very large allocations. [...] I have no interest in pursuing an answer to that question. I am simply reporting some observed behavior of a program written in standard C, running on what is TTBOMK a conforming implementation. Moreover as long as such an implementation /could/ be conforming, AFAIAC that is all that matters, so any question about what is going "under the hood" is moot.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-08-11 05:45 +0000 |
| Message-ID | <sevo5r$djr$2@gioia.aioe.org> |
| In reply to | #80823 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Vir Campestris <vir.campestris@invalid.invalid> writes: > > [..stuff about 64 bit systems removed..] > >> What bothers me about ptr_diff_t is the size. The difference between >> two 32-bit pointers is plus or minus 4GB. Which needs a 33 bit value >> :( >> >> As it happens it's never been a practical problem as I've never had a >> 32 bit system with more than 2GB RAM, > > It isn't necessary for there to be more than 2GB of RAM for > problems with ptrdiff_t to manifest (in 32-bit linux). A call to > malloc() will gladly return a memory area larger than all of RAM > if there is swap space to hold it. Also, doesn't mmap() in Linux map a file into "virtual memory"? Ostensibly this can be larger than the amount of physical RAM.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-11 05:26 -0700 |
| Message-ID | <86h7fwyxp6.fsf@linuxsc.com> |
| In reply to | #80843 |
Juha Nieminen <nospam@thanks.invalid> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Vir Campestris <vir.campestris@invalid.invalid> writes: >> >> [..stuff about 64 bit systems removed..] >> >>> What bothers me about ptr_diff_t is the size. The difference between >>> two 32-bit pointers is plus or minus 4GB. Which needs a 33 bit value >>> :( >>> >>> As it happens it's never been a practical problem as I've never had a >>> 32 bit system with more than 2GB RAM, >> >> It isn't necessary for there to be more than 2GB of RAM for >> problems with ptrdiff_t to manifest (in 32-bit linux). A call to >> malloc() will gladly return a memory area larger than all of RAM >> if there is swap space to hold it. > > Also, doesn't mmap() in Linux map a file into "virtual memory"? > Ostensibly this can be larger than the amount of physical RAM. That's a more complicated question. I don't see anything in the documentation that rules out mapping a file larger than physical RAM, but I also don't see any indication that such cases must be supported, even if only conditionally supported. My comment about malloc() is based on first-hand experience; I don't have any corresponding first-hand experience with mmap().
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-11 14:06 +0000 |
| Message-ID | <YPQQI.17283$lK.9695@fx41.iad> |
| In reply to | #80849 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >Juha Nieminen <nospam@thanks.invalid> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> >>> Vir Campestris <vir.campestris@invalid.invalid> writes: >>> >>> [..stuff about 64 bit systems removed..] >>> >>>> What bothers me about ptr_diff_t is the size. The difference between >>>> two 32-bit pointers is plus or minus 4GB. Which needs a 33 bit value >>>> :( >>>> >>>> As it happens it's never been a practical problem as I've never had a >>>> 32 bit system with more than 2GB RAM, >>> >>> It isn't necessary for there to be more than 2GB of RAM for >>> problems with ptrdiff_t to manifest (in 32-bit linux). A call to >>> malloc() will gladly return a memory area larger than all of RAM >>> if there is swap space to hold it. >> >> Also, doesn't mmap() in Linux map a file into "virtual memory"? >> Ostensibly this can be larger than the amount of physical RAM. > >That's a more complicated question. I don't see anything in the >documentation that rules out mapping a file larger than physical The limit on mapping is the available virtual address space for the application. And note that Linux and Windows 32-bit systems, limit the application to two or three GB (depending on OS configuration) of virtual address space. The only way to map more that the size of the available VA space is to manually window the file over a subset of the VA space. On Unix/Linux systems, an additional limit (setrlimit(2) RLIMIT_AS) can be set by the administrator (and lowered, but not raised, by the application itself). An application that exceeds the RLIMIT_AS for the process will recieve a SIGSEGV when attempting to allocate virtual address space via any API (e.g. brk, sbrk, mmap).
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.c++
csiph-web