Lars Roland wrote:
- strtoull() replaced with corresponding glib function
g_ascii_strtoull()
Doesn't work with GLib 1.2[.x]. I changed "config.h.win32" to define
"strtoull" as "g_ascii_strtoull" instead (as we require GLib 2.x on
Windows).
- added tvb_get_ntoh64() to plugin api
Checked in, with "tvb_get_letoh64()" added as well.
- cosmetic fix for nsis installer
Checked in.
I still get a warning in ftype-integer.c in line 324: Conversion of
"__int64" into "int". Possible loss of data.
I assume MSVC6 doesn't know, how to do a "bitwise and" with 64-bit
integers.
It knows how to do other arithmetic, so I'd be surprised if it didn't
know how to do bitwise and.
It doesnt't, however, know how to fit the result of the bitwise AND into
a 32-bit "gboolean" without throwing away 32 of those bits - and neither
does GCC, and neither do I. :-)
The "bitwise AND" operator in display filters appears to be intended to
be a Boolean that returns TRUE if the result is non-zero and FALSE if
the result is zero. I've checked in changes to compare against zero in
the 32-bit and 64-bit integer bitwise AND routines; that should suppress
the warning, and fix the problem that the warning notes (i.e., if you do
proto.64-bit-field & 0x8000000000000000
that test would always return FALSE with the code before my checkin).
However, unless I'm missing something, the byte-array and IPv4 bitwise
AND routines will return FALSE if *any* of the bytes of the result are
zero, rather than returning FALSE only if *all* of them are zero:
p_a = a->data;
p_b = b->data;
while (i < b->len) {
if (p_a[i] & p_b[i])
i++;
else
return FALSE;
}
return TRUE;
I think that should be
p_a = a->data;
p_b = b->data;
while (i < b->len) {
if (p_a[i] & p_b[i])
return TRUE;
else
i++;
}
return FALSE;
The nsis installer can show a readme file, but there is a limitation. It
is necessary to use a standard file extension, e.g. ".txt".
"README.win32" won't work. I didn't activate this feature, but I fixed
the comment.
However I do not think "README.win32" is a good readme file for a normal
user. It is mainly about setting up an development environment on
Windows.
That's mainly a result of the complexity of setting up that environment;
the README.{platform} files are intended to cover all the issues on the
platform in question, including both building Ethereal from source and
running it.
We might want to split the READMEs into "user" and "developer" READMEs,
for the benefit of any binary installers capable of displaying a README
at the end of the installation.
Any suggestions?
