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 03:50:56 -0700
Organization: A noiseless patient Spider
Lines: 31
Message-ID: <86y297x7fz.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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="9454758c9431509775b14536efcf33cd"; logging-data="18910"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19DNV3lLSHdJrKEfY/6AsLacLjsybx3v4k="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:Z8NnBWJ9WvkI7YNY+wQ84d9mMa8= sha1:JbFAwDj5QRrG5AHbWhmcHBlbsG8=
Xref: csiph.com comp.lang.c++:80860

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.