Re: [PHP4BETA] Re: eval() bug?

Well, I'm not shocked to see that printf() crashes on NULLs. I more or less imagined it wasn't completely standard, it was just a pretty much de-facto standard I experienced on all of the platforms I ever used. I'll guard against NULL arguments to printf() from now on. Zeev On Fri, 11 Jun 1999, Sascha Schumann wrote: > On Fri, Jun 11, 1999 at 07:37:18PM +0300, Zeev Suraski wrote: > > Really? Hmm, that's weird. I never protect against NULL's in printf()'s, > > just about any implementation I saw prints (null), and doesn't crash. > > > > That's kind of bad. > > The problem is that the C standard lays down that the argument > for a %s specifier shall be a pointer to an array of characters. > Since NULL is not such a pointer (it's a pointer, but not to an > array of characters), the call falls into "undefined behaviour." > > The question here is, what do you generally want to do with NULL > pointers passed to library functions. If you insist that *printf > should accept a NULL pointer as if it were valid, how should > other functions such as strcmp behave in such a case? > > Sun chooses the way of everything or nothing. If your program > conforms to the ANSI C standard, everything will work as > expected. Once a programmer uses a construct with undefined > behaviour, the Sun libc segfaults. We observed this already with > a non-deterministic compare function passed to libc's qsort(). > > More information about this topic can be found in "Expert C > Programming" by Peter v.d. Linden, a member of the compiler and > OS kernel group at Sun. He details questions such as "why extern > char *cp isn't equal to extern char cp[]" and other important > things you won't find in common C books. > > -- > > Regards, > > Sascha Schumann > Consultant > -- ----------------------------------------------------- Zeev Suraski <zeev@zend.com> For a PGP public key, finger bourbon@netvision.net.il