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

Groups > comp.lang.c > #173845

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

Show all headers | View raw

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>> [use of address space for zero-byte allocated objects]
>>
>>>> I think the key word there is sparsely.  A very small
>>>> fraction of a 64-bit address space suffices, and that
>>>> needn't be all contiguous either - it's easy to handle
>>>> a modest number of distinct areas, without too much
>>>> burden either in space or time.
>>>
>>> Perhaps, but vis-a-vis realloc(p,0),  I'd say just don't
>>> do that rather than adding an arcane 'zero-byte object'
>>> concept.  Deprecate the feature completely.
>>
>> Probably a lot of other people agree with you, but the problem
>> is not just realloc().  A call of malloc(0) has the same problem.
>> And that problem is not going away - the C standard gives an
>> implementation-defined choice as to whether malloc(0) returns
>> NULL or a pointer to "a zero-sized object" (my phrasing).
>>
>>> In fact, I'd suggest using malloc(), memcpy()/and free() if
>>> necessary to reallocate something.
>>
>> I think that idea is nutty.  The realloc() function serves a
>> useful purpose, including better utilization of memory.  If
>> someone wants to avoid the weird possibilities of zero-sized
>> objects, it's easy enough to program around that without
>> having to completely give up on realloc().
>
> I've never used it (realloc) in forty-plus years of C programming.
>
> As for better utilization of memory,  there may be cases where
> a growth request can be fulfilled by expanding the existing
> allocation (e.g. glibc _int_realloc).   I'd think that would be
> less likely in modern threaded environments, although I'd like
> to see some real workload data, perhaps by instrumenting
> _int_realloc to keep statistics on the frequency of cases
> where the memcpy is not required.

Obviously it depends on how much memory is available, and how
close to the memory limits the program is running.  If we have an
environment with only, say, 1.5 G available, and we want to grow
a 0.8 G block to 1 G, the malloc/copy/free approach will fail,
but using realloc may very well succeed.  Even shrinking a memory
block can fail under the malloc/copy/free approach, but will
almost certainly succeed when using realloc.  Clearly there are
some potential upsides to using realloc, and I don't see any
downsides.  So I still don't understand your position, unless
you're saying this is what you've always done and you don't see
any reason to change it, even if it might be suboptimal.

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

Thread

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