Re: [PATCH] Use size_t for mallinfo fields.

[Florian Weimer <fweimer@redhat.com>]

* 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).

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.

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