-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 24.04.2016 14:55, LRN wrote: > On 24.04.2016 13:47, lh_mouse wrote: >> On 2016-04-24 18:36, LRN wrote: >>> On 24.04.2016 12:40, lh_mouse wrote: >>>> On 2016-04-23 03:38, LRN wrote: >>>>> On 22.04.2016 20:24, LRN wrote: >>>>>> This matches the behaviour of MSVC better in cases when >>>>>> there is a mix of values < 0 and values > 0x7FFFFFFF in the >>>>>> same enum, which, without this change, prompts GCC to >>>>>> increase enum size to 8 bytes. >>>>> >>>>>> Fixes bug #456 >>>>> >>>>>> patch is attached >>>>> >>>>> Yeah, and another thing: i don't have x86_64 gcc, nor did i >>>>> test this with x64 msvc. No idea what sizeof(any enum) on >>>>> 64-bit architecture is for these two compilers, or how that >>>>> interacts with sizeof(int) being 8 there. >>>>> >>>> >>>> Within both MS ABI and Itanium ABI for x64, sizeof(int) is 4. >>>> >>>> And FWIW, here is the reason of the enumeration problem: >>>> >>>> Quoting from WG14 N1570 (Programming languages — C) [quote] >>>> 6.7.2.2 Enumeration specifiers 4 Each enumerated type shall be >>>> compatible with char, a signed integer type, or an unsigned >>>> integer type. The choice of type is implementation-defined,128) >>>> but shall be capable of representing the values of all the >>>> members of the enumeration. The enumerated type is incomplete >>>> until immediately after the } that terminates the list of >>>> enumerator declarations, and complete thereafter. [/quote] >>>> >>>> Here if an enum has both an enumerator less than zero and >>>> another one greater than 0x7FFFFFFF, neither `int` nor >>>> `unsigned` could be an option because neither is 'capable of >>>> representing the values of all the members of the enumeration'. >>>> GCC is doing the correct thing to use a 64-bit integer type. >>> >>> >>> Yeah, but the problem here is not being correct. The problem here >>> is being MSVC-compatible (for obvious reasons). >>> >>> I'm not even sure MSVC is entirely incorrect. If one thinks not of >>> numeric values but of byte representations of values, it is >>> possible to represent both negative (between 0x80000000 and >>> 0xFFFFFFFF) and positive (between 0x00000000 and 0x7FFFFFFF) >>> values with a signed 32-bit integer as well as unsigned one - >>> bytes are the same, only their interpretation changes. If you can >>> guarantee that 0xFFFFFFFF, when used in any place where this >>> enumeration value is expected, is casted to -1 (when actual math >>> is done; if no math is done, then its value is irrelevant, as long >>> at it's always the same), then that is just as good as actually >>> specifying -1 instead of 0xFFFFFFFF. >>> >>> It seems that the implementation of casting by both GCC and MSVC >>> does provide that guarantee. I've made a test program that shoves >>> enumeration members into 32-/64-bit signed/unsigned integer >>> variables and then prints out their contents. When enumeration >>> members are casted to (int) like i proposed, the output for GCC >>> and MSVC is identical in all cases. >>> >>> I also got around to download x86_64-gcc (first time in the last >>> few years when i've used a W32 gcc that i have no built myself) >>> and wrestled a bit with x64 MSVC compiler, managing to compile the >>> test program for x86_64. Again, the output is identical for both >>> GCC and MSVC. >> >> I would suggest you cast them to 'unsigned' instead of 'int' for >> semantical correctness reasons. > > Casting to (unsigned) does ensure that enum size remains 4, as all > values, when cast into (unsigned), do fit into 32-bit unsigned > integer. However, the output of the test program changes due to this > cast and looks the same as the initial output of a GCC-compiled test > program, before i started to cast enum members. So while casting to > (unsigned) does solve the main problem (enum size), we would have to > be prepared for unforeseen consequences, if we take that road. > > Curiously, MSVC doesn't give a damn about the casts and never changes > its behaviour no matter how you cast (or not cast) enumeration members > in their definition. >
Well, since everyone else seems to be OK with this (and since there is no other possible fix in sight), i'll push this tomorrow. - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXH9TtAAoJEOs4Jb6SI2CwO2kH/0YHskTp7mLg0HqvfFXzCzQh vziJFjk/d8+VLYf2uAbOoqjEBdGUB1jnQxH5EfPhP3VnE2/EGcynWikw4c9e5KE9 obWmGTqz6QZinKLhwUqg0eXiPvrk9mARfxwNSjMG6j/UDZ3jywSB4XdAKsIeUcbc AoEeLzLgj1HWPi/vOaaSXMCVchBZQXVEeuNzag7GevYR158UUf+Wg/vjjBCR/7ow hHd386Ed+sigUMgbpfnvis1JDA0b9nalNoWQJFCs7maO5UmvQcfozlx43k0vKRpU ksWyAe2Fp4TyhDyq12nEM8dK01m1OHrtiXUk0qCzkADgS3cPAkMrMW6KFRKw06E= =aK7I -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
