Re: [sr #110399] turning off preference for newest supported C?

[Nick Bowler]

On 2020-12-10, Karl Berry <INVALID.NOREPLY@gnu.org> wrote:
> When a longstanding core existing feature (AC_PROG_CC) is changed in a
> backward-incompatible way, a way to get the heretofore standard behavior
> feels  more like a bug fix than a feature request to me. For that matter, it 
> feels
> like a new macro or option would have been more desirable than incompatibly
> changing existing behavior.

I will note that -std=gnu11 (or, more recently, the substantially
equivalent -std=gnu17) mode has been the default mode of GCC for the
better part of a decade now.

So with modern compilers I would not expect there to be much
difference between old and new behaviour of AC_PROG_CC (you'll get a
modern C flavour
in either case).

> Anyway. Semantics aside, I had the same reaction to the weird error about
> "long int". I haven't had a chance to look into it yet, but my expectation
> is that it is something specific to the TL autoconfigury. (I mean, presumably
> int64_t should not be getting #define-d in the first place.)

My guess would be that something is including either <stdint.h> or
<inttypes.h> with these macros defined.  Per the C spec, int64_t is a
reserved identifier if either header is included so defining a macro
with this name and including one of these headers gives undefined
behaviour.

It is really odd that such a problem would occur simply by changing
the C standard version.  Perhaps there is code conditional code on
__STDC_VERSION__?  For example, it could be that <stdint.h> is
included only if __STDC_VERSION >= 199901, and because of the macro
definition you get undefined results (translation failure in this
case).

Cheers,
  Nick