Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 25 Nov 2020 18:41:14 -0500
From: Dominic Chen <d.c.ddcc@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] Fix crash in malloc_usable_size() if nullptr

On 11/25/2020 5:53 PM, Rich Felker wrote:
> Thanks. I wasn't aware of this. I did some research to see if this is
> actually documented as supported, since the Linux man pages aren't
> normative but just descriptive, and sometimes document things that
> aren't actually contracts. It seems glibc doesn't even document the
> existence of this function at all though.
>
> FreeBSD documents it but without any special handling of null
> pointers. But Solaris documents the same behavior you described. So it
> seems this is at least not entirely glibc-specific. Do you know if
> there are other implementations that do the same?

Unfortunately, my understanding is just that this functionality (looking 
up heap allocation sizes) is platform-specific and not standardized. 
UNIX platforms seem to provide malloc_usable_size() (although it's not 
in SUSv4), whereas Mac provides malloc_size(), and Windows provides 
_msize(). Of other platforms, only the Windows documentation explicitly 
mentions null checks, but it calls a platform-specific invalid parameter 
handler instead of returning zero.

On UNIX platforms, although documentation does not consistently describe 
returning zero for nullptr, I believe most do actually implement it. I 
took a look at the source for dlmalloc, glibc, jemalloc, and scudo, and 
can confirm that all four do so.

Thanks,

Dominic

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.