Eric Blake wrote:
I'm still open to any cleaner test, easy enough to maintain.
All we care about is (1) is it MingW and (2) has it defined PRIdMAX to be "lld"
or to be "I64d". Is that right? If so, the first we can tell via inspecting a
predefined preprocessor macro, and the second we can t
On 05/20/2015 09:40 PM, Paul Eggert wrote:
> $EGREP has undefined behavior on binary data, so this isn't portable.
Bummer. It will work on mingw (which only uses GNU grep), which is the
affected platform, but you're right that we have to make it not break
other platforms. And 'strings' is not po
$EGREP has undefined behavior on binary data, so this isn't portable.
I long ago gave up on AC_EGREP_CPP, since it's too flaky nowadays. Why can't we
test directly for what we're worried about? I'm afraid I am not following why
the value of PRIdMAX is related to whether printf should use the
On 21/05/15 00:26, Eric Blake wrote:
> Per https://gcc.gnu.org/gcc-5/porting_to.html, gcc 5.1 intentionally
> changed the preprocessor to emit multiple lines, rather than one
> line, when expanding text that includes literal markers combined with
> a macro expansion obtained from a header. This in
Per https://gcc.gnu.org/gcc-5/porting_to.html, gcc 5.1 intentionally
changed the preprocessor to emit multiple lines, rather than one
line, when expanding text that includes literal markers combined with
a macro expansion obtained from a header. This in turn breaks the
probe for whether mingw head
On 01/05/2015 04:03 PM, Eric Blake wrote:
> Commit cf88e56ab broke the use of PRIdMAX and friends on modern
> mingw64 installations. Basically, when requesting
> _USE_MINGW_ANSI_STDIO, not only does mingw turn on support for %lld,
> it also rewrites to provide PRIdMAX as "lld" instead of
> "I64d"
