Martin Fuchs wrote:
I already used the following defines: (in winefile
and explorer)
#ifdef _MSC_VER
#define LONGLONGARG _T("I64")
#else
#define LONGLONGARG _T("L")
#endif
I think you misunderstood me. I wasn't talking about printf-ish format
string specifiers, I was talking about integral literals. Where some code
currently is littered with:
#if defined __GNUC__
a = 1LL;
#elif defined _MSC_VER
a = 1i64;
#else
#error unknown compiler for 64-bit integral literal
#endif
to have it somewhat compiler independent, I was aiming for a single:
a = ZZZ(1);
The sprinkled conditional compilation approach is not only butt-ugly but
also a maintenance nightmare, especially if there comes along a compiler
using neither i64 nor LL suffix for 64-bit integral literals.
Your example does however nicely display an example of what I didn't want to
see - exposing compiler specific extentions/implementation details.
Staying in the realm of C89, which we must do if any MS compilers are to be
able to translate the code (since the word from MS is "we don't care about
C99, and will not bother with it"), "long long" and variations thereof is
a
compiler specific extension to C to store a 64-bit integer as much as
__int64 is.
What I would prefer is to find a macro name that isn't so long that people
wildly objects to it, while at the same time make the casual
reader/maintainer of the code immediately understand it's a 64-bit integer
being defined without having to know specific implementation details between
2..n compilers.
Another thing to perhaps consider/look into is - what will happen when a
single "long" is 64 bits (on a 64-bit CPU)? Will then "long long" be
128
bits? If so, any names containing "long long" or any variations thereof will
then obviously be wrong if what's intended in the code is specifically a
64-bit value.
Your example did however bring up the next logical question, even if
somewhat superceeded by the fact msvcrt.dll printf format specification by
design and necessity handles the "%i64d"-style format specifications.
For code intended to run on not-ReactOS too, or with a runtime library not
compatible with MS, macros such as yours can be useful. In the realm of
ReactOS I however don't see this as a problem, and even if it is I think its
time would be better placed as a follow-up discussion once a macro name to
define 64-bit integral literals has been decided upon.
/Mike