Re: [PATCH] Zend/zend_alloc.c

From: Date: Wed, 29 Aug 2001 15:51:52 +0000
Subject: Re: [PATCH] Zend/zend_alloc.c
References: 1 2 3 4 5 6  Groups: php.dev 
Request: Send a blank email to php-dev+get-64634@lists.php.net to get a copy of this message 
At 18:45 29-08-01, George Schlossnagle wrote:

At 14:57 29-08-01, Walter Franzini wrote:

From the extension (the user of kernel services) pov I must disagree.

But obviusly I'missing something :-)


I don't see why there's a difference.


Maybe the difference is not ZE vs. extension but internal vs. external
data, where external means coming from the outside of PHP/Zend.

If you try to allocate memory for data that come from the outside (the
browser, a db) you should fail gracefully: a malicious user can send
to your app a huge amount of data only to make it crash.

This sort of checking should be done by the extension before you make the
allocation, no?   You shoulnd't even be -trying- to allocate 2G of memory
for an object in your extension (unless you really want to be, of course).
Amongst other things allowing for this sloppiness only encourages people to
further sloppiness, like not checking the return values of their
malloc/emalloc call, which will almost certainly result in crashes when they
return null and that pointer is sloppily passed to another routine without
proper checking.  Failure to allocate should be a fatal error.


Sometimes it makes sense (but these cases are very rare).  For instance, some hashes that over-populate try to increase their lookup table size, so that they stay efficient - but if you try to allocate a bigger block and fail, it's quite alright to stay with the existing table size.  That's the only reason we added this ability to erealloc(), so they're really rare cases.

Zeev

Thread (18 messages)

« previous php.dev (#64634) next »