Re: [PATCH] Use size_t for mallinfo fields.

["Martin Liška" <mliska@suse.cz>]

PING^1

On 7/8/20 9:24 AM, Martin Liška wrote:
> 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
>>
>