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.


PHP Development Mailing List <>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to