>> 2008/6/30 Richard L. Hamilton <rlhamil at smart.net>:
>> It's not that changing the printf behavior is wrong, it's that it's
>> _incomplete_
>> without going after the real problem, namely training the coders.
The C Language Standard ISO/IEC:9899:1999 does not require the implementation
to
raise SEGV followed by a core dump in the specific case of passing a NULL
pointer as an argument to a format specifier, to printf(3C) and related family
of Standard C Library functions.
1. ISO/IEC:9899:1999.6.3.2.3:
Regardless how an invalid pointer is created, any use of it yields
undefined behavior. Even assignment, comparison with a null pointer
constant, or comparison with itself, might on some systems result in an
exception.
2. ISO/IEC:9899:1999.7.19.6.1:
s If no [l] length modifier is present, the argument shall be a pointer
to the initial element of an array of character type[239]. [ ... ]
The "undefined behavior" referenced in ISO/IEC:9899:1999.6.3.2.3 does not
require SIGSEGV. Printing "(null)" is a perfectly valid, and Standard compliant
undefined behavior.
There are no provisions, in the Language Standard, for the special handling of
the 's' format specifier, in the case where the initial element of the array is
a null pointer. Moreover, other format specifiers -- most notably 'p' and 'x'
--
do not raise SIGSEGV followed by a core dump, even today, in case their
corresponding argument is a null pointer.
What is the rationale for treating the 's' format specifier differently than
'p'
or 'x' ?
Also, pursuant to ISO/IEC:9899:1999.6.3.2.3, would you advocate raising SIGSEGV
followed by core dump in case of a trivial comparison with a NULL pointer ?
if (foo == NULL) {
}
ISO/IEC:9899:1999.6.3.2.3 does not expressly prohibit this behavior. Quite the
opposite, it explicitly mentions it as a valid implementation defined behavior.
--Stefan
--
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman at Sun.COM
