Re: [PHP-DEV] [PATCH] Zend/zend_alloc.c From: Zeev Suraski (zeev <email protected>)
Date: 08/29/01

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 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>