Wireshark-dev: Re: [Wireshark-dev] cmake giving options the compiler does not understand
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Sun, 5 Jan 2014 11:40:45 -0800
On Jan 5, 2014, at 10:00 AM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> wrote:

> On 01/04/2014 09:51 PM, Guy Harris wrote:
>> 
>> On Jan 4, 2014, at 9:17 AM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> wrote:
>> 

>>> 6) make # just to show that it works (I stopped the build after a few C files were compiled)
>>> 7) vi ../CMakeLists.txt
>>> 8) Put "-Wshorten-64-to-32" back where it was (at the end of WIRESHARK_C_ONLY_FLAGS)
>>> 9) cmake ..
>> 
>> Presumably CMake then reports something such as
>> 
>> 	-- Checking for flag: -Wshorten-64-to-32
>> 	-- Performing Test WS_C_FLAG_VALID44
>> 	-- Performing Test WS_C_FLAG_VALID44 - Success
>> 
>> in that case, meaning it thinks -Wshorten-64-to-32 *is* supported by the C compiler?
> 
> Well it doesn't do the full check on this (cached) pass, it just says:
> 
> -- Checking for flag: -Wjump-misses-init
> -- Checking for flag: -Wshorten-64-to-32
> -- C-Flags:  -Wall -W -Wextra -Wendif-labels [...]

So is the issue that the tests have the ordinal number of the flag, rather than the name of the flag, in the name of the test, with that name being used when caching results, so that the cache is bogus if you've reordered the flags since the cached results are generated?

(Presumably this also caused some flag that *does* work *not* to be added, as the results of the test of -Wshorten-64-to-32 were used on that flag.)

>> Which version of which compiler is this?  (You said "Fedora", so I presume it's either GCC or Clang; which version of Fedora is it?)
> 
> I first hit the problem on Fedora 18 (I'd have to check on the compiler version but it was gcc).  The method quoted above was reproduced on Fedora 19 (gcc 4.8.2).


Apparently GNU GCC 4.8.2 doesn't support -Wshorten-64-to-32.

So maybe Apple were the first people to realize that maybe checking for inadvertently chopping off the upper 32 bits of a value, because your code wasn't 64-bit-clean, was a good idea?

Perhaps someday somebody involved with GCC will realize that maybe checking for *all* shortenings without an explicit cast might be a good idea (which Microsoft figured out a while ago, that being one of the reasons why the build breaks on the Windows builds - MSVC is treating such a shortening as an error).