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: Thu, 12 Aug 2021 08:29:58 -0700
Organization: A noiseless patient Spider
Lines: 44
Message-ID: <86tujuy93d.fsf@linuxsc.com>
References: <s9fl3f$ha7$1@dont-email.me> <s9fq58$3qr$1@dont-email.me> <s9fqkc$c14$1@dont-email.me> <s9fqvh$ich$1@dont-email.me> <s9fssi$i74$1@dont-email.me> <lhUuI.12113$341.6150@fx42.iad> <86im0h2fi1.fsf@linuxsc.com> <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="9454758c9431509775b14536efcf33cd"; logging-data="31187"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18KGMhQfedqUSP3jQEHrPOsVYjKXBOkzeY="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:5C88fDK6nszlc8TcGETTEc46syY= sha1:3/IQQvVFUf6VbU/FAdHCeOo9is0=
Xref: csiph.com comp.lang.c++:80862

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.