Re: [Wireshark-dev] ARM Build
On Oct 15, 2014, at 11:03 AM, Alexis La Goutte wrote: > packet-mac-lte.c: In function 'dissect_mac_lte': > packet-mac-lte.c:5334:39: error: 'rapid_description' may be used > uninitialized in this function [-We > rror=maybe-uninitialized] > expert_add_info_format(pinfo, ti, > ^ The compiler's wrong, but I redid the code a bit so that rapid_description will always be set. That's not an ARM issue, except perhaps to the extent that the dataflow analysis has architecture-specific parts, with the ARM version not recognizing that this isn't a problem (or with other versions not having the chance to incorrectly decide it is a problem). I've checked a change into the trunk, which simplifies the code a bit. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] ARM Build
On Oct 16, 2014, at 4:50 AM, Graham Bloice wrote: > Visual Studio (VS2013 at least) as 32 & 64 bit ARM compilers. http://msdn.microsoft.com/en-us/library/0w6ke344.aspx "Type char Visual Studio 2013 Other Versions 1 out of 1 rated this helpful - Rate this topic The char type is used to store the integer value of a member of the representable character set. That integer value is the ASCII code corresponding to the specified character. Microsoft Specific Character values of type unsigned char have a range from 0 to 0xFF hexadecimal. A signed char has range 0x80 to 0x7F. These ranges translate to 0 to 255 decimal, and –128 to +127 decimal, respectively. *The /J compiler option changes the default from signed to unsigned.* END Microsoft Specific" (emphasis mine, as that seems to implicitly indicate that an unqualified "char" is signed by default). So, unless that page discusses *only* the x86-32/x86-64/Itanium-if-they-still-support-it compilers, it appears that char is signed by default on all platforms, presumably including ARM. What we *could* do is, on some platform or platforms, do both default compiles and char-is-unsigned compiles, using /J for MSVC and -funsigned-char with GCC (and Clang?). (I couldn't find any -W option for GCC that warns about code that would behave differently with char-is-signed and char-is-unsigned. There should be, but, then, there should also be an option to warn about *all* implicit shortenings - or, at least, all implicit shortenings that aren't known to be safe, such as converting "sizeof (int)" to a type shorter than size_t - even though there should be.) ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] ARM Build
On Oct 15, 2014, at 11:43 AM, Guy Harris wrote:
>> 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.
The warning was due to unsigned 8-bit values always being <= 0xFF.
A better fix is to extract the upper and lower nibbles and to make sure they're
both >= 0xA, as a nibble is always <= 0xF (fewer tests, no special-casing of
0xFF). I checked that in, with the nibble extractions casting the result to
guchar to make sure no sign-extension is done on platforms with *signed*
characters.
Checked into the trunk and backported to 1.12 and 1.10.
>> 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.
...and, in addition, the gchars used as array subscripts should be cast to
guchar, so that they're not sign-extended.
Checked into the trunk and backported to 1.12 (1.10 doesn't have that code).
>> 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.
Checked into the trunk and backported to 1.12 and 1.10.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] ARM Build
On 15 October 2014 19:03, Alexis La Goutte wrote: > Hi, > > I have try to build wireshark on ARM(v7) Machine (Using the new cloud > from Online.net[1]) > > > > May be time to add ARM trunk buildbot ? ;-) > > Visual Studio (VS2013 at least) as 32 & 64 bit ARM compilers. I've never fired them up though. I wonder if CMake can be persuaded to make solution files that include ARM compilation options. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
