On 03/09/2023 22:40, Scott Lurndal wrote:
> 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.

If I have a block of memory, and I want to change its size, it's
possible that the heap management routines can optimise to something
better than make new allocation then memcpy. Perhaps there's enough free
space just past my buffer for my expansion. Perhaps there's enough free
memory that it's not worth moving the data to a smaller block.

It's not something I've used often, but I have used it occasionally.

Andy

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

[ to realloc or malloc/copy/free ? ]

> Most of the code I've worked on has been bare metal (operating
> systems, hypervisors, run-time firmware) where dynamic allocation
> is either discouraged or managed with fixed size pool allocators
> or slab allocators, et cetera. I suppose that's influenced my
> thinking about the desirability of realloc() and run-time heap
> management.
>
> Clearly others have found it useful.

Now that I understand your perspective I think we are on the
same page (no pun intended). Stand-alone environments do
indeed promote a different mindset with respect to malloc()
and to memory allocation generally.

(Inspired by a sub-thread in one or another of the usual, interminable
navel-gazing threads for which CLC is justly famous...)

(On my system) "man realloc" says that:

If size was equal to 0, either NULL or a pointer suitable to be passed
to free() is returned.

which is odd, since, although the standard says either one is legal, the
implementation ought to know. Experimentation indicates that the answer is
the former (NULL).

But what I find interesting is the wording of the second alternative.
Earlier on, it says that the above call (realloc(p,0)) is equivalent to
free(p). So, that means that once the call is made, the pointer is no
longer valid. The text quoted above indicates that whatever is returned by
the call (if not NULL) is valid to be passed to free(). But wouldn't that
(doing so) lead to a dreaded "double free" ?

Note: I may have left some T's uncrossed and/or some I's undotted, but I am
running out of time, so I must cut this short. Rest assured that I have
considered all the possibilities, even if I have not delineated them all
here.

--
"Remember when teachers, public employees, Planned Parenthood, NPR and PBS
crashed the stock market, wiped out half of our 401Ks, took trillions in
TARP money, spilled oil in the Gulf of Mexico, gave themselves billions in
bonuses, and paid no taxes? Yeah, me neither."

On 7/30/23 12:36 PM, Kenny McCormack wrote:
> (Inspired by a sub-thread in one or another of the usual, interminable
> navel-gazing threads for which CLC is justly famous...)
>
> (On my system) "man realloc" says that:
>
> If size was equal to 0, either NULL or a pointer suitable to be passed
> to free() is returned.
>
> which is odd, since, although the standard says either one is legal, the
> implementation ought to know. Experimentation indicates that the answer is
> the former (NULL).
>
> But what I find interesting is the wording of the second alternative.
> Earlier on, it says that the above call (realloc(p,0)) is equivalent to
> free(p). So, that means that once the call is made, the pointer is no
> longer valid. The text quoted above indicates that whatever is returned by
> the call (if not NULL) is valid to be passed to free(). But wouldn't that
> (doing so) lead to a dreaded "double free" ?
>
> Note: I may have left some T's uncrossed and/or some I's undotted, but I am
> running out of time, so I must cut this short. Rest assured that I have
> considered all the possibilities, even if I have not delineated them all
> here.
>

My understanding is that, in effect, the call to realloc(p,0), if it is
using the second option of returning a suitable pointer, is effectively
do a free(p), and then allocating a "0 byte" block of memory and
returning the address of that. this pointer might have the same value as
the input pointer, or it might not. Calling free on the returned pointer
is allowed, and in fact needed to avoid a memory leak (of 0 bytes +
overhead) but calling free on the input pointer (unless the return
happens to match it) would be undefined behavior, as it was freed.

This is just like ANY use of the input pointer after the call, as it
might no longer be valid, unless of course, the return pointer happened
to match the input pointer as it was able to do the operation "in place".

As to why the document both behaviors, it may be that they support
multiple implementation libraries, and don't want to restrict them more
than the Standard does. It is NOT "Impleentation Defined Behavor" as to
which it does, it is just Unspecified, so the implementation can do
either, and could in fact do both at different times.

This just goes back to the Standards Committee not wanting to take sides
in a philosophical debate about 0-byte objects back when this came up,
and then not wanting to break code that depends on either behavior, such
code just needs to use implementations that promise the behavior they
depend on.

On 7/30/2023 9:36 AM, Kenny McCormack wrote:
> (Inspired by a sub-thread in one or another of the usual, interminable
> navel-gazing threads for which CLC is justly famous...)
>
> (On my system) "man realloc" says that:
>
> If size was equal to 0, either NULL or a pointer suitable to be passed
> to free() is returned.
>
> which is odd, since, although the standard says either one is legal, the
> implementation ought to know. Experimentation indicates that the answer is
> the former (NULL).
>
> But what I find interesting is the wording of the second alternative.
> Earlier on, it says that the above call (realloc(p,0)) is equivalent to
> free(p). So, that means that once the call is made, the pointer is no
> longer valid. The text quoted above indicates that whatever is returned by
> the call (if not NULL) is valid to be passed to free(). But wouldn't that
> (doing so) lead to a dreaded "double free" ?
>
> Note: I may have left some T's uncrossed and/or some I's undotted, but I am
> running out of time, so I must cut this short. Rest assured that I have
> considered all the possibilities, even if I have not delineated them all
> here.
>

void* p = realloc(p,0);
free(p);

Is fine. free(NULL) is fine.

Even if p is not NULL, it still can be passed to free. Keep in mind that
if p is not NULL it should never be used because its pointing to no
memory at all. What am I missing here?

Thanks.

On Sunday, 30 July 2023 at 20:12:58 UTC+1, Chris M. Thomasson wrote:
> On 7/30/2023 9:36 AM, Kenny McCormack wrote:
> > (Inspired by a sub-thread in one or another of the usual, interminable
> > navel-gazing threads for which CLC is justly famous...)
> >
> > (On my system) "man realloc" says that:
> >
> > If size was equal to 0, either NULL or a pointer suitable to be passed
> > to free() is returned.
> >
> > which is odd, since, although the standard says either one is legal, the
> > implementation ought to know. Experimentation indicates that the answer is
> > the former (NULL).
> >
> > But what I find interesting is the wording of the second alternative.
> > Earlier on, it says that the above call (realloc(p,0)) is equivalent to
> > free(p). So, that means that once the call is made, the pointer is no
> > longer valid. The text quoted above indicates that whatever is returned by
> > the call (if not NULL) is valid to be passed to free(). But wouldn't that
> > (doing so) lead to a dreaded "double free" ?
> >
> > Note: I may have left some T's uncrossed and/or some I's undotted, but I am
> > running out of time, so I must cut this short. Rest assured that I have
> > considered all the possibilities, even if I have not delineated them all
> > here.
> >
> void* p = realloc(p,0);
> free(p);
>
> Is fine. free(NULL) is fine.
>
> Even if p is not NULL, it still can be passed to free. Keep in mind that
> if p is not NULL it should never be used because its pointing to no
> memory at all. What am I missing here?
>
p is a valid pointer, but to a buffer of zero bytes. So it can be passed to any
function expecting a buffer, as long as that function is written to handle the
N ==0 case properly.
If we have this code.
unsigned char randomjunk[sizeof(void*)];
mempcy(&p, randomjunk, sizeof(void *));
functionexpectingabuffer(p, 0);

Then it's UB because the system can pick up that we're loading random junk
into an address register and trigger some sort of memory protection.

However is p is returned from realloc(ptr, 0) then it's OK.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Sunday, 30 July 2023 at 20:12:58 UTC+1, Chris M. Thomasson wrote:

>> void* p = realloc(p,0);

Danger Will Robinson! This is UB: p is indeterminate when passed to
realloc.

>> free(p);
>>
>> Is fine. free(NULL) is fine.
>>
>> Even if p is not NULL, it still can be passed to free. Keep in mind that
>> if p is not NULL it should never be used because its pointing to no
>> memory at all. What am I missing here?

Yes. If p in either NULL or a valid pointer from a prior allocation,
then

p = realloc(p, 0);
free(p);

is fine which was the point you wanted to make. It's unfortunate that
your example had an unrelated problem.

> p is a valid pointer, but to a buffer of zero bytes. So it can be
> passed to any function expecting a buffer, as long as that function is
> written to handle the N ==0 case properly.
> If we have this code.
> unsigned char randomjunk[sizeof(void*)];
> mempcy(&p, randomjunk, sizeof(void *));
> functionexpectingabuffer(p, 0);
>
> Then it's UB because the system can pick up that we're loading random junk
> into an address register and trigger some sort of memory protection.

I see you have decided to join Bart in misusing the term UB. That code
is UB regardless of what the system can or can't do. It's UB because
the language standard says you can't expect any defined behaviour from
that code.

Also, your supposed "reason" could lead readers astray. There is no UB
in this:

unsigned char randomjunk[sizeof (void*)];
mempcy(&p, randomjunk, sizeof p);

The undefined behaviour comes from /any/ access to the value in p after
this, even if that access does not involve it being treated as an
address. The confusion comes from the fact "loading random junk into an
address register" might be taken to refer to these lines, not the
passing of p to a function. After all, there no reason to think that
the code you show will result in a junk value getting into an address
register.

--
Ben.

On 7/31/2023 8:26 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Sunday, 30 July 2023 at 20:12:58 UTC+1, Chris M. Thomasson wrote:
>
>>> void* p = realloc(p,0);
>
> Danger Will Robinson! This is UB: p is indeterminate when passed to
> realloc.

AHHH SHIT!!!

void* b = realloc(a, 0);

God damn it! Sorry!

>
>>> free(p);
>>>
>>> Is fine. free(NULL) is fine.
>>>
>>> Even if p is not NULL, it still can be passed to free. Keep in mind that
>>> if p is not NULL it should never be used because its pointing to no
>>> memory at all. What am I missing here?
>
> Yes. If p in either NULL or a valid pointer from a prior allocation,
> then
>
> p = realloc(p, 0);
> free(p);
>
> is fine which was the point you wanted to make. It's unfortunate that
> your example had an unrelated problem.

Yeah. Shit happens. Thanks for the heads up, Ben. God Damn it.

>
>> p is a valid pointer, but to a buffer of zero bytes. So it can be
>> passed to any function expecting a buffer, as long as that function is
>> written to handle the N ==0 case properly.
>> If we have this code.
>> unsigned char randomjunk[sizeof(void*)];
>> mempcy(&p, randomjunk, sizeof(void *));
>> functionexpectingabuffer(p, 0);
>>
>> Then it's UB because the system can pick up that we're loading random junk
>> into an address register and trigger some sort of memory protection.
>
> I see you have decided to join Bart in misusing the term UB. That code
> is UB regardless of what the system can or can't do. It's UB because
> the language standard says you can't expect any defined behaviour from
> that code.
>
> Also, your supposed "reason" could lead readers astray. There is no UB
> in this:
>
> unsigned char randomjunk[sizeof (void*)];
> mempcy(&p, randomjunk, sizeof p);
>
> The undefined behaviour comes from /any/ access to the value in p after
> this, even if that access does not involve it being treated as an
> address. The confusion comes from the fact "loading random junk into an
> address register" might be taken to refer to these lines, not the
> passing of p to a function. After all, there no reason to think that
> the code you show will result in a junk value getting into an address
> register.
>

On 7/31/2023 2:35 PM, Chris M. Thomasson wrote:
> On 7/31/2023 8:26 AM, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Sunday, 30 July 2023 at 20:12:58 UTC+1, Chris M. Thomasson wrote:
>>
>>>> void* p = realloc(p,0);
>>
>> Danger Will Robinson!  This is UB: p is indeterminate when passed to
>> realloc.

Face palm! How about danger Roger Wilco from SpaceQuest! ;^o

ARGGHHH!

>
> AHHH SHIT!!!
>
> void* b = realloc(a, 0);
>
> God damn it! Sorry!
[...]

gazelle@shell.xmission.com (Kenny McCormack) writes:

> (On my system) "man realloc" says that:
>
> If size was equal to 0, either NULL or a pointer suitable to
> be passed to free() is returned.
>
> which is odd, since, although the standard says either one is
> legal, the implementation ought to know. [...]

Probably the man page was written to express both possibilities,
so it could be used without change in different distributions.
Normally man pages are separate from whatever C implementation
is present; indeed there may be more than one, with different
choices made in the different implementations.

> But what I find interesting is the wording of the second
> alternative. Earlier on, it says that the above call
> (realloc(p,0)) is equivalent to free(p). [...]

The man page is either wrong or poorly written. I expect most
people have seen plenty of cases where what a man page says does
not exactly match what the C standard mandates.

Richard Damon <Richard@Damon-Family.org> writes:

> On 7/30/23 12:36 PM, Kenny McCormack wrote:
>
>> (On my system) "man realloc" says that:
>>
>> If size was equal to 0, either NULL or a pointer suitable to
>> be passed to free() is returned.
>>
>> which is odd, since, although the standard says either one is
>> legal, the implementation ought to know.

[...]

> As to why the document both behaviors, it may be that they support
> multiple implementation libraries, and don't want to restrict them
> more than the Standard does. It is NOT "Impleentation Defined
> Behavor" as to which it does, it is just Unspecified, so the
> implementation can do either, and could in fact do both at
> different times.

The choice for whether an allocation (or reallocation) of size 0
returns a null pointer or a "unique pointer" has been implementation
defined since C90: section 7.10.3 paragraph 1 in C90, 7.20.3 p1 in
n1256 for C99, and 7.22.3 p1 in n1570 for C11.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>gazelle@shell.xmission.com (Kenny McCormack) writes:
>
>> (On my system) "man realloc" says that:
>>
>> If size was equal to 0, either NULL or a pointer suitable to
>> be passed to free() is returned.
>>
>> which is odd, since, although the standard says either one is
>> legal, the implementation ought to know. [...]
>
>Probably the man page was written to express both possibilities,
>so it could be used without change in different distributions.
>Normally man pages are separate from whatever C implementation
>is present; indeed there may be more than one, with different
>choices made in the different implementations.

Some linux distributions simply provide the POSIX/SuS pages
rather than developing their own set of manual pages. Thus
the page will have generic elements not necessarily specific to
the implementation.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 7/30/23 12:36 PM, Kenny McCormack wrote:
>>
>>> (On my system) "man realloc" says that:
>>>
>>> If size was equal to 0, either NULL or a pointer suitable to
>>> be passed to free() is returned.
>>>
>>> which is odd, since, although the standard says either one is
>>> legal, the implementation ought to know.
>
>[...]
>
>> As to why the document both behaviors, it may be that they support
>> multiple implementation libraries, and don't want to restrict them
>> more than the Standard does. It is NOT "Impleentation Defined
>> Behavor" as to which it does, it is just Unspecified, so the
>> implementation can do either, and could in fact do both at
>> different times.
>
>The choice for whether an allocation (or reallocation) of size 0
>returns a null pointer or a "unique pointer" has been implementation
>defined since C90: section 7.10.3 paragraph 1 in C90, 7.20.3 p1 in
>n1256 for C99, and 7.22.3 p1 in n1570 for C11.

Even earlier, the System V Interface Definition (SVID3), first published
in 1983, says:

"If the size of the space requested is zero, the bahavior is
implementation defined; the value returned will either be a NULL
pointer or an unique pointer."

The Future Directions section indicates that the interface defintions
will use size_t instead of unsigned for the size parameter and the
older versions were moved to level 2 on 1989-09-30.