[Guy Harris <guy@xxxxxxxxxxxx>]

On Oct 15, 2014, at 11:03 AM, Alexis La Goutte <alexis.lagoutte@xxxxxxxxx> wrote:

> Hi,
> 
> I have try to build wireshark on ARM(v7) Machine

...which may be running a compiler in which "char" is unsigned; I seem to remember that issue coming up with some software in the past couple of months (possibly Wireshark, possibly libpcap or tcpdump).

> I have try to build lasted trunk/master of wireshark (to test speed..)
> but don't build :
> 
> ftype-pcre.c: In function 'raw_flag_needed':
> ftype-pcre.c:64:13: error: comparison is always true due to limited
> range of data type [-Werror=type
> -limits]
>             (s[i] >= '\xFA' && s[i] <= '\xFF'))
>             ^

We should probably make "s" a "const guchar *", and do the appropriate cast.

> cc1: all warnings being treated as errors
> ./wslua_internals.c: In function 'wslua_hex2bin':
> ./wslua_internals.c:556:9: error: comparison is always false due to
> limited range of data type [-Wer
> ror=type-limits]
>         if (c < 0) {
>         ^
> ./wslua_internals.c:565:9: error: comparison is always false due to
> limited range of data type [-Wer
> ror=type-limits]
>         if (d < 0) break;
>         ^

"static const char str_to_nibble[]" should be "static const gint8 str_to_nibble[]", and "char c, d" should be "gint8 c, d" (the underlying data type would be "signed char", but they're 8-bit signed integers, not characters, so "gint8" is clearer).

> strutil.c: In function 'hex_str_to_bytes_encoding':
> strutil.c:634:13: error: comparison is always false due to limited
> range of data type [-Werror=type-
> limits]
>             if (c < 0) {
>             ^
> strutil.c:641:13: error: comparison is always false due to limited
> range of data type [-Werror=type-
> limits]
>             if (d < 0) {
>             ^

> strutil.c:650:13: error: comparison is always true due to limited
> range of data type [-Werror=type-l
> imits]
>             if (sep > 0 && *end == sep && str_to_nibble[(int)*(end+1)] > -1) {
>             ^

...and the same applies there.

> airpcap_loader.c: In function 'airpcap_if_get_device_supported_channels_array':
> airpcap_loader.c:841:17: error: case label value is less than minimum
> value for type [-Werror]
>                 case -1:
>                 ^
> airpcap_loader.c:870:17: error: case label value is less than minimum
> value for type [-Werror]
>                 case -1:
>                 ^

Change ExtChannel in struct _AirpcapChannelInfo in caputils/airpcap.h from gchar to gint8.  (And, yes, if there's a similar structure in the AirPcap SDK, the AirPcap developers should make sure it's not "char" - make it some appropriate guaranteed-to-be-signed 8-bit data type, whether "signed char" or something else.)

> May be time to add ARM trunk buildbot ? ;-)

Sounds good.  (Some compilers that default to signed "char" might have an option to make "char" unsigned, which would work also, but if we chose to check unsigned "char" on some platform where it's *not* the default, we would want to test with both signed *and* unsigned "char" on that platform - the first to make sure it's OK for a normal build on that platform and the second to check for unsigned "char".)