[PATCH] Use size_t for mallinfo fields.

[Martin Liška]

On 7/7/20 4:22 PM, Florian Weimer wrote:
> * Martin Liška:
> 
>> On 7/7/20 3:49 PM, Florian Weimer wrote:
>>> * Martin Liška:
>>>
>>>> On 7/7/20 2:17 PM, Andreas Schwab wrote:
>>>>> On Jul 07 2020, Martin Liška wrote:
>>>>>
>>>>>> The current int type can easily overflow for allocation of more
>>>>>> than 4GB.
>>>>>>
>>>>>> The following patch changes that to size_t. I guess I need to adjust
>>>>>> the API version of the function, right?
>>>>>
>>>>> Not only that, it breaks the ABI of mallinfo.
>>>>
>>>> Sure, so what options do I have? I'm new to glibc so a hint would be
>>>> appreciated.
>>>
>>> We need to add a new function.  Symbol versioning does not work because
>>> mallinfo is interposed by alternative mallocs (tcmalloc, Address
>>> Sanitizer, etc.).  Without the new function name, the interposer does
>>> not know which ABI the application expects, so it's going to be quite
>>> messy.
> 
>> All right, am I closer with the suggested patch?
> 
> If what I wrote above is right (we'd first gather consensus around
> that), we should probably add struct mallinfo2 and mallinfo2, deprecate
> the original mallinfo function, and eventually remove them from the
> public API (turning the original mallinfo into a compatibility symbol).

All right, I'm sending patch for that.

> 
> I suppose it would make sense to raise this issue with the tcmalloc, tbb
> and Address Sanitizer people, to see if they would be willing to
> implement mallinfo2 on their end.

Once we're done I can file issues to all these to inform them.

Thoughts?
Martin

> 
> The end result, having mallinfo2 and not mallinfo, is a bit ugly, but
> it's an improvement over the current state.  I do not see a need to get
> creative with symbol redirects or symbol versions.
> 
> Thanks,
> Florian
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-mallinfo2-function-that-support-sizes-4GB.patch
Type: text/x-patch
Size: 8177 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20200708/8fee73e0/attachment-0001.bin>