My only possible objection to this is that this change might mask
certain kinds of bugs which might be useful to catch.
Can we have an environment variable to turn off this behavior for
debugging purposes (perhaps leaving it turned off by default in a debug
build of ON?) A perhaps better solution might be to place an assert()
in printf for the string not being NULL. (Hmmm... do we even *have*
debug/non-debug versions of libc as we do for the kernel?)
-- Garrett
Darren J Moffat wrote:
> 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
>
>
