AW: [PATCH] newlib: Improve memory allocation for floating-point string

Hi Corinna!

Okay, I will prepare a simple sample/reproducer to show the functional improvement ... But I don’t' know
whether I have enough (spare) time this week. At least it has to do with a "unusual" direct use of gdtoa()

But, I will split (and slightly adopt) this suggested patch into a refactoring-part and fix/improvement.
I will send you the refactoring-only patch(es) in advance with a more detailed description what is intended.

Best regards from Salzburg,
Markus


-----Ursprüngliche Nachricht-----
Von: Corinna Vinschen <[email protected]> 
Gesendet: Friday, 6 December 2024 16:47
An: Markus Eisenmann <[email protected]>
Cc: [email protected]
Betreff: Re: [PATCH] newlib: Improve memory allocation for floating-point string

BeSecure!       This email comes from outside of ABB. Make sure you verify the sender before clicking any links or downloading/opening attachments.
If this email looks suspicious, report it by clicking 'Report Phishing' button in Outlook or raising a ticket on MyIS.


Hi Markus,

On Dec  5 15:20, Markus Eisenmann wrote:
> Hi!
>
> IMHO, the commit "newlib: Fix memory leak regarding gdtoa-based 
> _ldtoa_r()" [02/08/2023] has solved a memory leak issue, but I think there's still scenarios that may lead to memory corruption or exception.
> E.g., calling freedtoa() after gdto() frees the memory-block but does 
> not invalidate the copy in the mp-result member in the 
> reent-structure. Call _dtoa_r() or _ldtoa_r() afterwards will "free" this block twice and will corrupt the chain of free blocks.

Do you have a simple reproducer?

> In addition, I think that the previous implementation in gdto() - like 
> used in phyton - that the value _Bigint::_k is stored in front of the 
> memory instead in within the _reent-structure is more robust and is more flexible.

Why?  Again, do you have a reproducer to show that this has an advantage or is more robust?


Thanks,
Corinna