lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

I don't think thank shrinking or keeping the same size may fail: if a better location can't be used (because the memory pool where it would fit can't be augmented or modified, the best thing to do is to keep the existing pointer, and just mark the end as "supposedly" unused (even if that unused part is not reallocatable for something else as that part would need to be added in a free pool.
The interface allows recording the effective size that is used in an allocated block, so that the end of block may or may not be reused later (immediately or not, when it will be possible to add the free part in a free pool, which may occur later when possible and where there will be an opportunity to do it).
Moving blocks  when shrinking or redefining its size is allowed to move it, but is not forced to do it or to make a real deallocation immediately: the reported available free size may not change immediately.
But returning NULL for shrinking an allocated block or setting it to the same size is a non-sense that would cause more problems than what it would attempt to solve.

Le lun. 10 août 2020 à 17:33, Stefan <> a écrit :
Am 10.08.2020 um 16:34 schrieb Roberto Ierusalimschy:
>> I think Lua relies on the behaviour that the realloc-like function
>> does not return a different pointer (copy) for shrinking an existing
>> block. Maybe that could be a problem for some allocators.
> Lua does not rely on that. The only assumption was that shrinking
> an existing block could not fail, but it can move the block without
> problems. Actually, the test suite in Lua has a mode that forces every
> single reallocation (growing, shrinking, or to the same size!) to move
> the block.

My test program was flawed. Sorry.

> Lua 5.4 has removed this restriction of "no fail when shrinking".
> -- Roberto

Wow, so this is why it is no longer in the manual.
I wonder if there is any system with C support left that can't
run Lua :)