Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c++
Subject: Re: Is this really necessary
Date: Sat, 14 Aug 2021 03:20:39 -0700
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <86a6lkxr7s.fsf@linuxsc.com>
References: <s9fl3f$ha7$1@dont-email.me> <seo7hm$1b7s$1@gioia.aioe.org> <seolt2$nuj$1@dont-email.me> <seqoel$s5l$1@gioia.aioe.org> <serkdg$jh8$1@dont-email.me> <serkpm$36i$1@gioia.aioe.org> <ses4ec$si1$1@dont-email.me> <8635rh1m2i.fsf@linuxsc.com> <inffroF5l5hU1@mid.individual.net> <86bl63zs5l.fsf@linuxsc.com> <sf2ljh$14ur$1@gioia.aioe.org> <86y297x7fz.fsf@linuxsc.com> <sf3cu8$1hga$1@gioia.aioe.org> <86tujuy93d.fsf@linuxsc.com> <sf3fb0$m7g$1@gioia.aioe.org> <sf3kgp$kh9$1@dont-email.me> <sf568p$1o4o$1@gioia.aioe.org> <sf5s5l$j75$1@dont-email.me> <874kbti4yp.fsf@nosuchdomain.example.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="e69182db6e8a2e097c43a26c68c35bd4"; logging-data="12023"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/joIc9/kLA4cvWJISI2lhOzURH7Jm+UZo="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:j13GugQyL13dS+a8lUaUM4/obLU= sha1:Yhv6+N5laX9UiDcPuQ6cR0Qqd+k=
Xref: csiph.com comp.lang.c++:80881

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".