Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: Is this really necessary Date: Fri, 13 Aug 2021 11:18:06 -0700 Organization: None to speak of Lines: 61 Message-ID: <874kbti4yp.fsf@nosuchdomain.example.com> References: <8635rh1m2i.fsf@linuxsc.com> <86bl63zs5l.fsf@linuxsc.com> <86y297x7fz.fsf@linuxsc.com> <86tujuy93d.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="2eb990256145d81ea1ee497015a0529a"; logging-data="17272"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18zwHvxNcen/USPJGvUXF/i" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:dcXV+A2bbTf9C/jcvXtmM2zsako= sha1:XdyWEKWZIjsc3j8AxEmSN3mjY/g= Xref: csiph.com comp.lang.c++:80875 "Alf P. Steinbach" writes: > On 13 Aug 2021 09:16, Juha Nieminen wrote: >> Paavo Helde 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 , 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 */