Re: [PATCH] win64 fix for libiberty md5.h

[Ian Lance Taylor <iant at google dot com>]

DJ Delorie <dj@redhat.com> writes:

>> That is definitely a concern in some cases, but I'm not very
>> troubled by the case of uintptr_t.  If your libiberty build and your
>> other builds don't agree on something as basic as uintptr_t, I think
>> you have deeper problems.
>
> They might differ on whether or not you think you *have* uintptr_t,
> though.  If configure's default guess doesn't match uintptr_t, you
> have a problem.  m32c would probably be such a case.

Note that modern autoconf doesn't use a default guess for uintptr_t even
when cross-compiling and type is not available.  It picks the first type
in the series 'unsigned int', 'unsigned long int', 'unsigned long long
int' which is large enough to hold a pointer value.  (This is
unfortunately not in our current 2.59 version; we would have to copy it
from autoconf 2.60 or from gnulib.)

I'm not sure that m32c is a valid counter-example here, since m32c is
new enough that uintptr_t will always be available.  uintptr_t has been
defined in the C standard for ten years now; only old systems won't have
it.


> The most common problem we forethought was that the other module just
> neglected to include the needed test in their configure.

Yes, definitely.  We can check for that: when the autoconf test is used,
either HAVE_UINTPTR_T is defined or uintptr_t is defined.  If neither is
defined as a macro, then the autoconf test was not used.

Ian