Re: Passing NULL to %s format specifiers

[Evan Huus <eapache () gmail com>]

On Thu, Aug 16, 2012 at 1:16 PM, Gerald Combs <gerald () wireshark org> wrote:
> On 8/15/12 8:12 AM, Evan Huus wrote:
> > On Wed, Aug 15, 2012 at 10:15 AM, Jeff Morriss
> > <jeff.morriss.ws () gmail com> wrote:
> > > Evan Huus wrote:
> > > > On Linux and most other operating systems I know of, passing a NULL to
> > > > a %s format specifier is safe. On Solaris, as it turns out, it isn't
> > > > [1].
>
> It's a little more complex than that. The problem is present if the
> system's C library doesn't handle passing NULL to %s AND GLib wasn't
> compiled with "--enable-included-printf". This used to be the case for
> Windows but was fixed a couple of years ago. It's still broken for
> Solaris because the default for "enable-included-printf" is "auto", at
> least according to the GLib sources. It seems like it should be "yes" in
> order to provide consistent behavior across platforms or at least check
> the behavior of passing NULL to %s.
>
> Note that you can still segfault with printf("%s", NULL) on Linux since
> gcc will use its builtin printf in that case.

Very interesting, thanks for the details.

I've added a short note to README.developer, so hopefully new code at
least will be safe.

> > I'm a fan of a macro like Jakub mentioned as part of the old conversation:
> >
> > http://www.wireshark.org/lists/wireshark-dev/201105/msg00205.html
> >
> > If we go that route, perhaps someone can add a bit to checkAPIs that
> > complains if it finds %s in a format string without the macro?
>
> I'm OK with this but it seems like we should be able to get Coverity or
> Clang to do the work for us. They're both pretty good at finding NULL
> pointer dereferences.

I know that CppCheck supports writing custom rules as XML files and
regexs (although I know nothing more about it at the moment then
that). It may be possible to subsume all of the current checkAPIs into
CppCheck rules, which would probably be a good thing since then we'd
get a proper grammar engine for free instead of relying on perl hacks.

Evan
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe