Re: vasnprintf SEGV when %s arg is NULL
- From: Owen Taylor <otaylor redhat com>
- To: David Jafferian <David Jafferian Sun COM>
- Cc: gnucash-devel gnucash org, gtk-devel-list gnome org
- Subject: Re: vasnprintf SEGV when %s arg is NULL
- Date: Thu, 17 Aug 2006 12:40:15 -0400
[ Leaving the cross-cc for the moment ]
On Mon, 2006-08-14 at 19:49 -0400, David Jafferian wrote:
> g_type_check_instance_cast (GTypeInstance *type_instance,
> GType iface_type)
> g_warning ("invalid uninstantiatable type `%s' in cast to `%s'",
> type_descriptive_name_I (type_instance->g_class->g_type),
> type_descriptive_name_I (iface_type));
> Here the NULL is not hardcoded, so the fix would be a bit more
If you get here, you have a serious bug elsewhere in your code and
will almost certainly crash pretty soon anyways, so the value of
protecting the %s's here against null is low.
> but the real issue here is the suggestion that there may
> be hundreds of these little bugs sprinkled throughout all of those
> libraries and applications which depend on glib.
> Although Owen may have been correct, it would not be grossly
> incorrect to deal with this issue by reimplementing vasnprintf()
> in glib to substitute a constant indicator string, e.g. "(nil)", for any
> NULL argument to a %s specifier.
> What has been the general consensus on this ?
I don't think it would be a bad thing if the Solaris sprintf was made
robust against NULLs for strings. (For some reason, I thought that
already happened... maybe in Solaris 10?)
But what I don't think we should do is blacklist sprintf implementations
and substitute expensive workarounds because they are missing this
feature, since it isn't require by ANSI C or POSIX.
(We have infrastructure that we use for similar things like missing
support for 64-bit integers, but its less efficient and may be less
robust in other ways than using the system sprintf more directly.)
] [Thread Prev