INT64_C and UINT64_C should be defined in more cross-platform way by DanielB_Logi

Hi,

Thanks for reporting this issue. INT64_C(24 * 60 * 60 * 10000000) is actually prohibited by the C Standard. C99 7.18.4/2 requires that "The argument in any instance of these macros shall be an unsuffixed integer constant (as defined in 6.4.4.1) with a value that does not exceed the limits for the corresponding type." 24 * 60 * 60 * 10000000 is an expression, not a single constant.

However, I've changed our implementation to

#define INT8_C(x) (x)
#define INT16_C(x) (x)
#define INT32_C(x) (x)
#define INT64_C(x) (x ## LL)

#define UINT8_C(x) (x)
#define UINT16_C(x) (x)
#define UINT32_C(x) (x ## U)
#define UINT64_C(x) (x ## ULL)

because of a potential issue with enormous constants. According to C++11 2.14.2 [lex.icon]/2, unsuffixed integer constants in decimal have the first type in the list "int, long, long long" that they can be represented in. /3 says "A program is ill-formed if one of its translation units contains an integer literal that cannot be represented by any of the allowed types." This makes 18446744073709551615 ill-formed, so ((18446744073709551615) + (UINT64_MAX - UINT64_MAX)) is also ill-formed. As far as I can tell, this means that we must use token pasting.

(I'm actually not sure whether 2.14.2/3 is applied before macro expansion, so perhaps the original implementation was technically correct. But I believe my new implementation is also correct, and C99 seems to be suggesting a token-pasting implementation with its requirement for unsuffixed integer constants.)

Note that C99 7.18.4/3 requires the output of these macros to "have the same type as would an expression of the corresponding type converted according to the integer promotions". The integer promotions widen tiny types (like short and unsigned short) to int, which is why my UINT8_C and UINT16_C implementations don't paste U. (It is possible that I should be saying (x + 0) in order to actually activate the integer promotions, given that C++ can detect types with overloading and templates - but I can't spend forever analyzing these macros. :->)

If you have any further questions, feel free to E-mail me at stl@microsoft.com .

Stephan T. Lavavej
Visual C++ Libraries Developer

Thank you for submitting feedback on Visual Studio 2010 and .NET Framework. Your issue has been routed to the appropriate VS development team for review. We will contact you if we require any additional information.

The general integer type is not definited as 32/16/64/any byte-width as anyone thought, which means it is STD-legal for a specific C++ compiler that allows a generic-integer being byte-width any same to or greater than two. To a category 'long long', it may have at least 64 bits. The 'at least' means it should also legal for a compiler that once lets the 'long long' be 128 bits or even wider.
In my opinion, guys code the code formals under those plateforms are bad because too many assumes that a generic integer should be a specific bit-width at any compilers are made by them(smp: They thought the int must always be 32bits, the casts betweens a pointer to a 'long' integer is always available), and that is why the non-STD forced type-defines, such as the INT16/INT32/size_t/intptr_t/,etc. come out under the MS DEV. platforms.
The MS's way is to keep the portable of the future version of the compiling systems. After all, you never should let a INT64 becames to 128-bw integer for a wrong definition "#define INT64 long long".

Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)