Re: Bug #13587 Updated: Recurence makes crash

On Sun, 7 Oct 2001, Derick Rethans wrote: > On 7 Oct 2001 jeroen@php.net wrote: > > > Derick wrote: > > > Indeed, if we can make PHP not to crash, we'll certainly do so. But in this case > > > it is NOT possible as I explained before. > > > > You wrote before: > > > > > There is no clean way to catch this. PHP does not support infinite recursion, as no > > > language does. > > > The performance hit is too big if this kind of checking was build in, and even then > > > it's not very easy to do in a smart way. > > > > That's a reason why PHP cannot check for this at compile time. But PHP > > can of course check at runtime wether there are allocation problems. A > > "Error: out of memory " would be apropriate, or a stack error. (don't > > know where exactly the segfault is being caused by, by the hashtable > > allocation attempt, or because that hash table allocation gets a pointer > > to a location outside the execution stack or something alike, in either > > case, a error would be appropriate and possible, very likely without > > noticable performance hit) > > Read the archives before responding with this kind of stuff. It WILL give > a big performance it. You are referring to bug 8471 (and 11009, 7720 and 1901 are related too). There's no more information than in this bug report as to why it is such a big performance hit. I also failed to find any discussion about that bug, I also couldn't find any request from Jani to suspend that bug. I search from the submittance of that bug until the newyear. (unfortnately, it's impossible to search for numbers in the archives :-((, but searching for 'checkifloggedin' yielded only the bugmails. If there was a discussion, please give me a pointer. Or a hit as to why it'd be such a performance hit, something like checking for malloc to return NULL is not a big performance hit AFAIK. --Jeroen Jeroen van Wolffelaar Jeroen@A-Eskwadraat.nl http://www.A-Eskwadraat.nl/~jeroen