Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95129
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.194 as permitted sender)
To: "Christoph M. Becker" <cmbecker69@gmx.de>, Nikita Popov <nikic@php.net>
References: <85e38ba1-58d4-f8a7-33d4-5f4aa7fce44d@gmx.de>
Cc: internals@lists.php.net
Message-ID: <19a35995-a032-3413-cade-919d60d33875@gmail.com>
Date: Sun, 14 Aug 2016 01:21:13 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0)
 Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <85e38ba1-58d4-f8a7-33d4-5f4aa7fce44d@gmx.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Bug #72828
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> You have commented on <https://bugs.php.net/bug.php?id=72828>:
> 
> | Unless the allocations explicitly use the system allocator (i.e. do
> | not use emalloc and variants), do NOT introduce NULL checks.
> 
> Can you please elaborate, why that shouldn't be done.
> 
> Actually, the allocations use safe_emalloc() and emalloc(),
> respectively[1].  However, the only client of the function does

These do not need null checks. If e* functions can't alloc memory, they
produce fatal error, bail out and do not return. So if it returned, it
succeeded. The only reason why it can return null is a bug. In this case
we'd prefer it crashing fast - bugs in memory allocator are hard to
find, and closer to the source the crash is, easier it to catch it.

If pe* or system functions are used, then check may be warranted.
-- 
Stas Malyshev
smalyshev@gmail.com