Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
libc printf behaviour for NULL string
1.2. Name of Document Author/Supplier:
Author: Darren Moffat
1.3 Date of This Document:
25 June, 2008
4. Technical Description
Background
----------
The current behavior of the printf(3C) family of functions in libc when
passed a NULL value for a string format is undefined and usually
results in a SEGV and crashed application.
The workaround to applications written to depend on this behavior is to
LD_PRELOAD=/usr/lib/0 at 0.so.1 (or the 64 bit equivalent). The
workaround isn't always easy to apply (or it is too late data has been
lost or corrupted by that point).
Some will often state, myself included, that you shouldn't assume that
the printf(3C) family will deal with a NULL argument for a string and
that arguments should be checked before calling printf(3C).
The behavior of the SunOS 4.x printf(3C) and that of the still shipping
binary compatibility library /usr/4lib/libc.so.1 was to use the string
"(null)" if the argument for a %s was NULL.
This is also the behavior in current versions of GNU libc (as used
on most (maybe all) mainstream Linux kernel based distributions)
and the libc for FreeBSD, NetBSD, OpenBSD.
The behavior of HP-UX and AIX is unknown to the author of this case,
and since they are closed source there is no easy we to determine what
their implementation does.
It is reasonably common to find FOSS applications that when run on
Solaris/OpenSolaris fail due to the behavior of the printf(3C) in
libc. The GNOME libraries in snv_92 even appear to make this
assumption in some places (g_log function) based on cores I've seen for
gnome-settings-daemon and pidgin, I know that the Sun GNOME team has
fixed such issues in the past. In both of those cases it wasn't the
application that caused it but an assumption in some library code they
both use for error handling.
In some FOSS communities the upstream authors are often not interested
in changing their source and view the failure as a Solaris bug (taking
the stance that Linux and *BSD don't have this issue). Some are more
accommodating and have taken a half way step and have their code check
that 0 at 0.so.1 is LD_PRELOAD'd when running on Solaris, sometimes the
authors will fix the code.
This isn't a scalable way to approach the problem and hurts the
reputation of Solaris and OpenSolaris releases. It also hinders the
building of binaries for upstream FOSS components targeting an
OpenSolaris release repository. There is a large volume of software
not originally authored on Solaris/OpenSolaris that is critical to the
success of OpenSolaris. So a permanent fix for this is needed that
scales well in OpenSolaris and upstream community developer time.
Proposal
--------
This case proposes to change the default Solaris/OpenSolaris libc
behavior for the printf(3C) family so that it reverts to the SunOS 4.x
behavior of printing "(null)" instead of (likely) causing an
application crash. This change will apply the XPG and wide char
variants as well.
There are no documentation changes from this case, as the current
Solaris documentation says nothing about the behavior of printf(3C)
family when passed a NULL.
Since no application should be depending on the current behavior of
getting a SEGV when a passing a NULL there is no need to making this
change configurable. In fact doing so could cause even more harm than
the current situation.
There are no interface taxonomy changes.
The release binding for this change is patch.
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
