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: Wed, 11 Aug 2021 12:40:38 -0700 Organization: A noiseless patient Spider Lines: 52 Message-ID: <86bl63zs5l.fsf@linuxsc.com> References: <86im0h2fi1.fsf@linuxsc.com> <8635rh1m2i.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="9b2de4ec06692993da9b82e10a905748"; logging-data="6531"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18n5AxYXmMXgqT7Kfr4bO52ZfIsRFsiVLk=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:yFNLeWCHcSpH+q2iqo8ZHIQ5pYU= sha1:3+3akgyvNTlnlz6qTA8LgCsnySY= Xref: csiph.com comp.lang.c++:80855 Bo Persson writes: > On 2021-08-10 at 15:11, Tim Rentsch wrote: > >> Vir Campestris writes: >> >> [..stuff about 64 bit systems removed..] >> >>> What bothers me about ptr_diff_t is the size. The difference between >>> two 32-bit pointers is plus or minus 4GB. Which needs a 33 bit value >>> :( >>> >>> As it happens it's never been a practical problem as I've never had a >>> 32 bit system with more than 2GB RAM, >> >> It isn't necessary for there to be more than 2GB of RAM for >> problems with ptrdiff_t to manifest (in 32-bit linux). A call to >> malloc() will gladly return a memory area larger than all of RAM >> if there is swap space to hold it. > > There still has to be a contiguous address space that is free of > already allocated memory blocks and not in a range reserved by the > operating system. True. > I'm no Linux expert, but on Windows configured for LargeAddressAware > programs, with 3 GB user + 1 GB OS, it is extremely unlikely to find a > 2.x GB hole for the heap. That depends on the program doesn't it? And so is more unlikely for some programs than others? Of course it certainly is within the realm of possibility that on Microsoft Windows the virtual address space is all chopped up right from the get go. The developers there are real geniuses, who knows what they might have come up with. > Or that you have a program that needs > exactly 1 such block for byte sized operations. Note that "byte sized operations" might be nothing more than using character pointers to delimit region boundaries within the memory area, and using pointer subtraction to determine the size of various sub-areas. Note also that there may be more than one such block provided 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).