Stut wrote: > Please tell me you're kidding? If you can't provide a piece of code > that always causes the segfault are you seriously expecting the devs > to waste their time trying to find the cause? Talk about a needle in a > haystack. > > The ease of reproduction is not particularly important, although the > easier the better. The important thing is that every time you run the > script it causes a segfault. > > > I still maintain it is exceptionally poor show by php to let user > > code produce segfaults in apache. > > To me this comment indicates a lack of experience in software > development with C. To let a user script bring down the host environment is just not acceptable. IMHO. I've spent my professional life (sofar) doing development in C and assembler - when your code causes a problem at a customer site in Japan, you have absolutely zero chance of reproducing the problem - until you have analysed whatever dumps and system traces you have been provided with. Maybe you have to set a SLIP trap for producing more diagnostics, but you can only hope the problem re-occurs. > Segfaults are a fact of life Only if you are forced to accept poor programming. I can assure you that segfaults are not tolerated in a regular production environment. Segfaults happen in test and development. > and it's very difficult to cover every possible cause, especially when > you are using a number of external libraries. Expecting PHP to be > perfect is unrealistic. Actually I think the PHP developers should strive for just that. Not to do so is like the GCC people saying - "well, don't expect us to generate working code EVERY time" ... /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
