Re: strlen() and NULL pointer checks

[Jakub Zawadzki <darkjames-ws () darkjames pl>]

On Mon, May 16, 2011 at 04:18:40PM -0400, Jeff Morriss wrote:
> Every once in a while, I do some fuzz testing on a Solaris/SPARC system. 
>   When I first did it I was primarily worried about getting bus errors 
> (due to casts increasing alignment requirements), but usually what I 
> find is another case of what I fixed in r37181.  (Fortunately, I have 
> not gotten bus errors.)
>
> The backtrace for that one was:
>
> > #0  0xfc4b2150 in strlen () from /usr/lib/libc.so.1
> > #1  0xfc51d704 in _ndoprnt () from /usr/lib/libc.so.1
> > #2  0xfc51fe24 in vsnprintf () from /usr/lib/libc.so.1
> > #3  0xfd19c07c in proto_tree_set_representation_value (pi=0xff850be8, format=0xfe6d2c48 "(%s) Type %u: Value (hex 
> > bytes): %s", 
> >     ap=0xffbfdb50) at /Wireshark/source/epan/proto.c:3651
> > [...]
>
> The basic problem is that Solaris' strlen() seg-faults if given a NULL 
> pointer whereas a lot of other implementations just return 0. 

Actually no, glibc strlen() also sigsegvs with strlen(0);

"Problem" is with Solaris vsnprintf implementation which doesn't check if
argument for %s is NULL. glibc implementation replaces NULL with "(null)"

Funny thing is that glib already have copy of gnulib formatting routines for system 
with non-C99 snprintf implementation [1] (like Windows), and glib team already fixed this 
issue for such systems. Solaris has good implementation so they won't fix it.

You can read more at https://bugzilla.gnome.org/show_bug.cgi?id=167569

> Is there a better way?  Or better yet, a proper solution?

- Replace g_snprintf() & friends with ws_snprintf() which accepts NULL %s

- I had the same issue with another project, and we created macro:
  #define __(x) ((x) ? (x) : "(null)")

  and use it when passing possible-null-strings. 
  It's still PITA but IMHO it looks a little better than doing it by hand.

[1] Like implementation which returns -1 for truncated output.
___________________________________________________________________________
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