[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d6b5a758-eed5-e011-b827-6f6417f36484@gmail.com>
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.
