Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c++ Subject: Re: Is this really necessary Date: Sat, 14 Aug 2021 02:28:19 -0700 Organization: A noiseless patient Spider Lines: 84 Message-ID: <86mtpkxtn0.fsf@linuxsc.com> References: <86im0h2fi1.fsf@linuxsc.com> <8635rh1m2i.fsf@linuxsc.com> <86bl63zs5l.fsf@linuxsc.com> <86y297x7fz.fsf@linuxsc.com> <86tujuy93d.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="e69182db6e8a2e097c43a26c68c35bd4"; logging-data="11330"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19qJie1AsD3aILhZIAso32qJ/N/E9LDwN8=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:Q0odZT/1QRQlRTNR66pht1V9S3c= sha1:j3w5h2kN+2LVhQZ93rqhBDt7wAA= Xref: csiph.com comp.lang.c++:80878 Paavo Helde writes: > 12.08.2021 18:39 mickspud@downthefarm.com kirjutas: > >> On Thu, 12 Aug 2021 08:29:58 -0700 >> Tim Rentsch wrote: >> >>> mickspud@downthefarm.com writes: >>> >>>> On Thu, 12 Aug 2021 03:50:56 -0700 >>>> Tim Rentsch wrote: >>>> >>>>> mickspud@downthefarm.com writes: >>>>> >>>>>> On Wed, 11 Aug 2021 12:40:38 -0700 >>>>>> Tim Rentsch 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.