Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #173545

Re: The return value of realloc(p,0)

From Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups comp.lang.c
Subject Re: The return value of realloc(p,0)
Date 2023-09-01 11:42 -0700
Organization A noiseless patient Spider
Message-ID <86sf7xspk3.fsf@linuxsc.com> (permalink)
References (2 earlier) <kl972jF24chU3@mid.individual.net> <86edjju668.fsf@linuxsc.com> <ucqrn0$3dvle$1@dont-email.me> <86wmxas6ty.fsf@linuxsc.com> <ucsejp$3nrkk$5@dont-email.me>

Show all headers | View raw


Vir Campestris <vir.campestris@invalid.invalid> writes:

> On 01/09/2023 08:14, Tim Rentsch wrote:
>
>> Vir Campestris <vir.campestris@invalid.invalid> writes:
>>
>>> On 31/08/2023 06:33, Tim Rentsch wrote:
>>>
>>>> There are reasons for realloc() to zize 0 to be a special case.
>>>> Specifically, because the pointer value returned doesn't have to
>>>> be dereferencable, it can point to parts of the address space
>>>> that are otherwise unusable.  The overhead for such "zero-byte
>>>> blocks" is very low, just a smidge over one bit.  The usuable
>>>> memory previously allocated can be reclaimed and used in its
>>>> entirely for subsequent allocations.  If running in a 64-bit
>>>> address space, vast amounts of otherwise unusable areas can
>>>> be used for these "special objects", having very little impact
>>>> on memory usable for actual objects.
>>>
>>> Tim, I'm confused by a little bit of that:
>>>
>>> "just a smidge over one bit"
>>>
>>> I can see how you might point them all to a single place that can't be
>>> read or written, and have safety in case anyone tries to use them.
>>>
>>> I can see that you might have a section of memory with a series of
>>> bytes, each one reserved for these empty allocations.  It might be
>>> inaccessible, but will still use address space.
>>>
>>> But how do you get anything smaller than a byte, but non-zero?  I've
>>> only ever used one CPU with addressing smaller than a byte.
>>
>> I was tempted to make a joke here, but I couldn't see how to turn
>> out something funny.
>>
>> What I meant was just over one bit /per zero-byte block/.  So if
>> there were 20,000 zero-byte blocks, they could be managed with
>> just a little more than 2500 bytes of allocated memory.  Sorry
>> for the confusion.
>
> I still don't follow you.
>
> If I realloc to size 0 I get an address back.  That can be a unique
> address, in which case each one uses an address, and therefore a byte.
> [...]

In fact it must be a unique address, distinct from any other
address that has been allocated but not yet freed.

The key point is that, when the size is zero, the allocation
routine allocates /address space/ but does not allocate /memory/.
The address is not mapped to any memory, either physical or
virtual.

In a 64-bit address space, there are a lot more addresses than
there are bytes of memory, even virtual bytes of memory.  All but
a very small fraction of 64-bit addresses cannot map to actual
memory, because there is no room on the address bus (figuratively
speaking).

For example, suppose our zero byte block reside at addresses
in the range

    0x800000000000 to
    0x802000000000

and "objects" are aligned to 32-byte boundaries.  That means
there are 4294967296 zero-byte "objects" available.  For each of
those objects, we need to know if it has been allocated by not
yet freed, that is, one bit per object.  Add in a few extra
pointers and counts to manage the space to hold the bitmap
(so we don't have to use much more space for the bitmap than
is necessary), and we get a little over one bit /of actual
memory/ that is used to manage the zero-byte objects, which
take no actual memory.

Does that make more sense now?

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Re: The return value of realloc(p,0) Robert Latest <boblatest@yahoo.com> - 2023-08-30 15:54 +0000
  Re: The return value of realloc(p,0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-30 22:33 -0700
    Re: The return value of realloc(p,0) Vir Campestris <vir.campestris@invalid.invalid> - 2023-08-31 21:03 +0100
      Re: The return value of realloc(p,0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-01 00:14 -0700
        Re: The return value of realloc(p,0) Vir Campestris <vir.campestris@invalid.invalid> - 2023-09-01 11:32 +0100
          Re: The return value of realloc(p,0) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 17:08 +0000
          Re: The return value of realloc(p,0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-01 11:42 -0700
            Re: The return value of realloc(p,0) scott@slp53.sl.home (Scott Lurndal) - 2023-09-01 19:06 +0000
              Re: The return value of realloc(p,0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 01:45 -0700
                Re: The return value of realloc(p,0) scott@slp53.sl.home (Scott Lurndal) - 2023-09-03 16:12 +0000
                Re: The return value of realloc(p,0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 12:01 -0700
                Re: The return value of realloc(p,0) scott@slp53.sl.home (Scott Lurndal) - 2023-09-03 21:40 +0000
                Re: The return value of realloc(p,0) Spiros Bousbouras <spibou@gmail.com> - 2023-09-03 23:08 +0000
                Re: The return value of realloc(p,0) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-03 16:23 -0700
                Re: The return value of realloc(p,0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 17:01 -0700
                Re: The return value of realloc(p,0) scott@slp53.sl.home (Scott Lurndal) - 2023-09-04 14:22 +0000
                Re: The return value of realloc(p,0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-05 05:23 -0700
                Re: The return value of realloc(p,0) Vir Campestris <vir.campestris@invalid.invalid> - 2023-09-04 16:40 +0100
            Re: The return value of realloc(p,0) Vir Campestris <vir.campestris@invalid.invalid> - 2023-09-02 21:40 +0100
        Re: The return value of realloc(p,0) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 17:03 +0000
          Re: The return value of realloc(p,0) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-09-01 17:57 +0000
            Re: The return value of realloc(p,0) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 18:44 +0000
              Re: The return value of realloc(p,0) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-09-01 20:24 +0000
            Re: The return value of realloc(p,0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-01 11:58 -0700
              Re: The return value of realloc(p,0) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 19:14 +0000
                Re: The return value of realloc(p,0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 12:03 -0700
          Re: The return value of realloc(p,0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-01 11:55 -0700

csiph-web