On Thu, Mar 14, 2019 at 3:02 PM Yann Ylavic <ylavic....@gmail.com> wrote:
> On Thu, Mar 14, 2019 at 8:38 PM William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> >
> > On Thu, Mar 14, 2019 at 10:49 AM Yann Ylavic <ylavic....@gmail.com>
> wrote:
> >>
> >> Possibly to resolve APR_<INTTYPE>_T_FMT on system with
> >> [std]int[types].h, we could bind to the standard (C99?) format
> >> PR[dxo..]N, especially since we configure the format based off
> >> $ac_cv_sizeof_<inttype>, so something like:
> >> #define APR_<INTTYPE>_T_FMT PR[dxo..]`expr $ac_cv_sizeof_<inttype>_t *
> 8`
> >>
> >> That should work on most "modern" systems/compilers (including
> >> -stdc=c89), no? And for older ones the current as fallback could be
> >> reasonable.
> >
> >
> > No, not with c89 (not as any sort of standard, -stdc is irrelevant.)
>
> Do you mean C89 only compilers which don't support C99+ (i.e. -stdc or
> alike), and thus no inttypes.h and so on?
> Well, configure would work as today for them, and AIUI this is not on
> those systems that we have an issue.
>
The inttypes.h itself doesn't tell us the defines exist, for earlier drafts
and
precursors to C99.
What I mean is, adding more lines to configure.in is the last thing we want
to do, introducing extra complexity. We know what we have to do, determine
the actual int type correspondence and use the corresponding formatter.
In some strange cases we seem to pick up an environment where two types
are effectively equivilant but the %[[l]l]d formatters won't align because
they
are future-proofing the possibility of two now-equivalent int types from
being
distinct later on.
This suggestion above simply introduces the complexity of worrying about
the bitsize. We gain nothing choosing PRIld64 when we can simply use %d.
(For those unfamiliar, PRI is *upper case* prefix of a lowercase type, and
not the prefix 'PR' with type 'ld' - adding to legibility concerns.)
No, I'm not in favor of adding fixed int width considerations and congesting
some already horrible code even further, and let's not double our efforts
to decipher bytewidth and bitwidth of all these types. My current draft
should
be more portable provided that APR_TRY_COMPILE_NO_WARNING catches
and kills the code emitting warnings about printf format mismatches, and we
can trash a bunch of special cases in apr trunk.
dnl
dnl APR_CHECK_TYPES_COMPATIBLE(TYPE-1, TYPE-2, FMT-TAG,
dnl [ACTION-IF-TRUE], [ACTION-IF-FALSE])
dnl
dnl Try to determine whether two types are the same and accept the given
dnl printf formatter (bare token, e.g. literal d, ld, etc).
dnl
AC_DEFUN([APR_CHECK_TYPES_FMT_COMPATIBLE], [
define([apr_cvname], apr_cv_typematch_[]translit([$1], [ ],
[_])_[]translit([$2], [ ], [_])_[][$3])
AC_CACHE_CHECK([whether $1 and $2 use fmt %$3], apr_cvname, [
APR_TRY_COMPILE_NO_WARNING([#include <sys/types.h>
#include <stdio.h>], [
$1 chk1, *ptr1;
$2 chk2, *ptr2 = &chk1;
ptr1 = &chk2;
*ptr1 = *ptr2 = 0;
printf("%$3 %$3", chk1, chk2);
], [apr_cvname=yes
$4], [apr_cvname=no
$5])])
])
