Old HP inttypes.h defines UINT32_C as:
#define __CONCAT__(_A,_B) _A ## _B
#define __CONCAT_U__(_A) _A ## u
#define UINT32_C(__c) __CONCAT__(__CONCAT_U__(__c),l)
The __CONCAT__ macro does not delay concatenation for an extra level so
standard preprocessor implementations like GNU complain that they cannot
concatenate the ")" and "l".
The "HP92453-01 A.11.01.20 HP C Compiler" does not define any
identifying macros except for platform __hpux. If we see that platform
with no other compiler identification then assume this compiler. It has
'long long' and its 'char' is signed unless the +uc option is added.
The <inttypes.h> header on some platforms define the integer literal
macros incorrectly for some of the integer types. Generalize the
documented interface reporting broken U/INT64_C to all integer sizes.
The <inttypes.h> header on some platforms define the integer format
macros incorrectly for some of the integer types. Document macros that
we can define to report such platforms to the includer. Check these
reports before trusting the system-defined macros.
Clang warns
test/test_INT_format.h:28:26: warning: identifier after literal will
be treated as a reserved user-defined literal suffix in C++11
[-Wc++11-compat-reserved-user-defined-literal]
" expression [%"KWIML_INT_PRI##PRI"],"
because the KWIML_... part is an identifier lexically immediately
following a string literal. Add a space between the string literal
and the identifier to avoid the C++11 user-defined literal syntax.
Our TEST* macro calls pass arguments such as "int64_t" with the
expectation that the preprocessing token will be used literally.
Some platforms #define int64_t as "long long" which is not a valid
preprocessing token. Perform preprocessor symbol concatenation
on the type names at the first level of macro evaluation to avoid
expanding the names.
MIPS machines are biendian hence they can run both big endian kernels
e.g. Debian mips architecture, and little endian kernels e.g. Debian
mipsel architecture. Use predefined macros to distinguish them.
Teach KWIML_test to use part of the C++ runtime library. Otherwise the
linker complains:
warning LNK4089: all references to 'MSVCP71.dll' discarded by /OPT:REF
The PGI compiler appears to define "long long" as size 8 but does not
provide a feature macro for it. It does provide options for the
signedness of char (-Mschar, -Muchar) but does not define a feature
macro indicating the choice. The default is signed, at least on Linux.
The VS 7.0 header <yvals.h> included by most C++ system headers defines
the macro _LONGLONG as __int64. Teach ABI.h to ignore the definition in
this case because "long long" does not exist.
Some system headers may define macros that interfere with preprocessor
tests in KWIML headers. Test this case to be sure that the verification
checks at the bottom of the headers do not fail.
Xcode 2.x forgets to create the target output directory before linking
the individual architecture pieces of a universal binary for the target
KWIML_test. Then it passes the directory to -L and -F options when
linking the and warns that the directory does not exist. We work around
the problem by using a pre-build rule on the target to create the output
directory.
The Sun compiler does not document support for SCN*8 format (%hh*).
It works only on platforms that happen to provide a runtime library
that supports the format.
KWIML defines format string macros matching the fixed-sized types. This
test checks that they behave as expected and that the arguments match
the *sizes* expected by the format strings.
Provides header files that use preprocessor tests to detect and provide
information about the compiler and its target architecture. The headers
contain no configuration-time test results and thus may be installed
into an architecture-independent include directory. This makes them
suitable for use in the public interface of any package.
Brad King
Modestas Vainius