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
