[PATCH] Use size_t for mallinfo fields.

Martin Liška mliska@suse.cz
Mon Jul 27 12:08:11 GMT 2020


On 7/23/20 4:38 PM, Szabolcs Nagy wrote:
> The 07/08/2020 09:24, Martin Liška wrote:
>> Subject: [PATCH] Add mallinfo2 function that support sizes >= 4GB.
>>
>> The current int type can easily overflow for allocation of more
>> than 4GB.
> 
> i don't think a new symbol with a similar bad
> design as the old one is desirable.
> 
> (i think a good design would allow exposing malloc
> internal info without abi and api issues when the
> internals change, e.g. no struct field names and
> struct layout that are tied to internals. and
> supportable by other implementations so whatever
> gcc is doing would work elsewhere not just on glibc)

Hello.

All right, I agree with that. So something like:

enum malloc_info
{
   ARENA_BYTES,
   ...
};

size_t get_mallinfo (malloc_info type) ?

That would allow adding new enum values that can supported in the future.

> 
> one hack that may be acceptable is to use some
> nonsensical value in a mallinfo field to signal that
> the fields have new meaning, then the api can work
> backward compatibly when all field values are less
> than 2G and after that things are broken anyway so
> we can switch to some different struct content that
> has no overflow issue, but abi compatible with the
> old struct (e.g. round up the values to multiples of
> 1M), so we don't need a new abi symbol and interposers
> continue to work. (but i'm not entirely sure this
> is a good idea either)

Huh, that's quite hacky approach and I don't like it much :)
Let's forget about the old API/ABI and design a new proper one.

Martin

> 



More information about the Libc-alpha mailing list