[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?
- From: Philippe Verdy <verdyp@...>
- Date: Wed, 12 Aug 2020 04:01:25 +0200
Yes malloc may fail but this should not affect the existing block pointer that should then still be returned as is, even if it is larger than what was requested. Already when you use malloc, it may return a block larger than what was requested, and almost all libraries do that, at least for alignment or for storing some backtracking data or to add overhead detecting buffer overflows and corruptions or adding security markers.
What is wrong if realloc does not shrink the block when it is not required to do that, and does not even need to do it if reduction is non significant?
>I think it is even if the realloc returned a null. If this is not the case,
>then don't use the realloc from C, but only malloc, perform the
>memcpy after if it succeeds, and free the old block.
This method can't guarantee that no failure occurs when shrinking the block.
You see, malloc may fail indeed.
>But then you need your own memory manager.
>Just a waste of time, consider changing your c library for another that will
>correctly handle block size reduction without ever failing if the original block
>pointer was valid
I hope Lua runs on a real-time platform. I need change the memory manager.
On Wed, Aug 12, 2020 at 9:15 AM Philippe Verdy <firstname.lastname@example.org> wrote:
> Which standard? In C/C++ or Lua?
> May be some C implementations may fail, but these are certainly bad, excemt for saying that the block was not real located but is the original block still usable? I think it is even if the realloc returned a null. If this is not the case, then don't use the realloc from C, but only malloc, perform the memcpy after if it succeeds, and free the old block. That's what all decent C library should do. But then you need your own memory manager. Just a waste of time, consider changing your c library for another that will correctly handle block size reduction without ever failing if the original block pointer was valid
> Le mar. 11 août 2020 à 04:10, Andrew Gierth <email@example.com> a écrit :
>> >>>>> "Philippe" == Philippe Verdy <firstname.lastname@example.org> writes:
>> Philippe> I don't think thank shrinking or keeping the same size may
>> Philippe> fail
>> It doesn't matter what you think. What matters is what the language
>> standards say, and what they say is that realloc() is permitted to fail
>> when shrinking a block. (Some realloc implementations never fail in that
>> case, but many in common use do.)