On Thu, Aug 16, 2012 at 1:16 PM, Gerald Combs <ger...@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...@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-requ...@wireshark.org?subject=unsubscribe
