On Fri, Mar 22, 2019 at 09:45:38AM +0000, Yann Ylavic wrote: > Both apr_time_t and apr_interval_time_t are (apr_)int64_t, which is > probably format "%lld" on OpenBSD, so we'd need to determine > APR_INT64_T (and all of our numeric _FMT) with > APR_CHECK_TYPES_FMT_COMPATIBLE too.
Yes, I agree. From my point of view, the problem looks as follows: On OpenBSD/amd64, APR's configure script sees that 'sizeof(long)' and 'sizeof(long long)' are equivalent. It then makes an implicit assumption that all 64 bit types and related constants in C header files are dealt with in 'long' rather than in 'long long'. But this assumption is wrong. INT64_C() returns a 'LL'-suffixed constant on OpenBSD, and int64_t is indeed a 'long long': /usr/include/machine/_types.h:typedef long long __int64_t; /usr/include/sys/stdint.h:typedef __int64_t int64_t; Type checking in printf format strings is stricter than APR's configure script logic. The compiler will complain even if parameters are of the same size but not the same type (e.g. "%ld" format for a long long variable). This makes sense because the format string will end up being used on a variety of platforms with varying sizes for integer types, and printf cannot know that APR is trying to provide a matching format directive via custom macros. A non-APR C program will just hard-code format strings and as long as the format string and the type are an exact match, the program will be fine. So that's what the C compiler checks for. So the answer seems to be: APR needs to improve its configure script logic to match the strictness of format string checks as implemented by gcc and clang when mapping integer types defined by the underlying system to APR's own integer types. Else these warnings will show up one way or another. It cannot just assume that 'long' is preferred over 'long long' or vice versa.
