On 24/07/14 12:36, Joerg Mayer wrote:
> On Thu, Jul 24, 2014 at 11:58:51AM -0400, Bill Meier wrote:
>> While reviewing the new ceph dissector [1], two issues cropped up
>> where my build on Linux (using Autofoo) apparently gave different
>> results then a build by Kevin Cox (the submitter of the new
>> dissector) using CMake on Linux.
>>
>> He used GCC 4.9.1 and CMake while I used GCC 4.9.0 and Autofoo.
>>
>> 1. The Autofoo compile indicated an
>> "unused but set" variable
>> The CMake apparently did not.
>
> Should not be: I do (or at least did) get these messages regularly with
> CMake.
I usually get these too. Maybe it was a compiler bug or something. I
will try checking out the old version and doing a clean build to see if
the warning/error shows up now.
>> 2. The ceph dissector had several value_string_ext structs
>> defined as 'static const ...'.
>>
>> The Wireshark built with CMake worked AOK when
>> the ceph dissector used the extended value
>> strings for the first time (i.e., no exceptions).
>>
>> The Wireshark built with Autofoo trapped
>> when the extended value string structs were used
>> for the first time (when there was an attempt to
>> write to the struct).
>>
>> IOW: In one case, the structs were apparently not in a r/o section
>> while in the other they apparently were.
>>
>> I've no idea if this difference has anything to
>> do with CMake vs Autofoo.
>>
>>
>> Thoughts ?
>
> Not on first sight. Maybe you can do a comparison on your system where
> all the other tools are identical?
>
I just ran a test build and ./autogen && ./configure && make performed
the same way. It seems that GCC 4.9.1 doesn't want to put those
structures in .rodata on my system for whatever reason.
Also of note, the header_field_info.strings member is defined as 'const
void*' but when passed an extended value string it appears that the
const is casted away. This should probably be changed in order to be
type safe, as an error would have been raised if it was declared
properly as 'void*'.
Of course the downside to this is that regular value strings will not be
allowed to be const, but that can be worked around by modifying the
VALS() macro to cast away that const-ness as value_string's will always
be treated const. Ideally there would be a more type safe way to do this.
Attachment:
signature.asc
Description: OpenPGP digital signature
