-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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. - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXHLRDAAoJEOs4Jb6SI2CwIXMIAIqO/6/2b3xOTs9GG2bVTGY1 UsNyBpioDNI79LoQhso9+xZ3hjF6n5HYUsmulf0pachp8uK2yP8D6xoYs8d1FdUa CVUgzj86LmGbdpvetWx7+g7ahvLoeDxmapmURwp4Ui+bhl/2Fbd3iUo+o6uSd6/A oTUgPkzWTE0dVS9wQPPhUsunBVM810rXHrwSznYi9wXk7CTkhuzGwDFDVuIxQWnC tEExRLVoGt2pb2D3n2M5arH2+H1IRc1mivw/yOUiGKtdzngAPL1FTFB5p2nVsQ8m FvFoUsr+6wnHQijh5ycRFybFbTlf88hdKbrRiWQccnDcDiw71/BeP8LABGtLgLM= =/gnT -----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
