[ Leaving the cross-cc for the moment ]
On Mon, 2006-08-14 at 19:49 -0400, David Jafferian wrote:
> GTypeInstance*
> 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
> complex,
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.)
Regards,
Owen
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
