Wireshark-dev: Re: [Wireshark-dev] buildbot failure in Wireshark (development) on Windows-XP-x8
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Stephen Fisher <steve@xxxxxxxxxxxxxxxxxx>
Date: Sun, 8 Mar 2009 21:03:03 -0600
On Sun, Mar 08, 2009 at 06:27:17PM -0700, buildbot-no-reply@xxxxxxxxxxxxx wrote:

> Buildslave for this Build: windows-xp-x86

> BUILD FAILED: failed nmake all

This is being caused by the introduction of the following code in SVN 
revision 27667:

     case FT_INT64:
     case FT_UINT64:
     	if (hfinfo->display & BASE_RANGE_STRING) {
        	str = match_strrval(fvalue_get_integer64(&finfo->value), hfinfo->strings);
        } else {
                str = match_strval(fvalue_get_integer64(&finfo->value), hfinfo->strings);
        }
        break;

On Windows, MSVC complains that this is a conversion of a guint64 to a 
guint32 as match_strval() and match_strrval() (and val_to_str() and 
rval_to_str() for that matter) take a guint32 as an index and 
fvalue_get_integer64() is returning a guint64.  The Unix compilers don't 
seem to care.  On MacOS X, Apple introduced a -Wshorten-64-to-32 option 
that would catch this.  In a more general sense, gcc has a -Wconversion 
option that would catch this and many other things.

I started to fix it by changing the index to accept guint64 values, but 
wondered if it is worth the extra overhead?  Then I realized that in the 
VNC dissector, we're using negative (signed) values for some of the 
indices in value strings even though they're being converted to 
unsigned (presumably - I haven't looked at the code for VALS() lately).

Opinions?

Remember, if we change these to accept guint64 or something else, 
doc/README.developer needs to reflect that.


Steve