Paul Eggert wrote:
the project could suddenly stop building on systems it used to build on
because that compiler doesn't support all C99 features.
That's fine, for projects that want to assume C99. Or perhaps I'm
misunderstanding your scenario?
Nope, you've understood it properly. I have had more
Guus Leeuw jr. wrote:
1. POSIX threads
Is this solved as easily as adding the acx_pthread macro in
aclocal.m4, then
calling it in configure.ac and using the defined variables to properly
set
my foo_CFLAGS, foo_LIBS (or do I use LDADD?), etc., in my Makefile.am?
Yes it is ;)
Yes, I figured
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>> People's code shouldn't assume the features of
>> C89 that are incompatible with C99.
>
> This is a good notion, IMVHO. Unfortunately, it conflicts with
> (standards.info)CPU Portability
> where the infamous `error' example is advocated to be used
Paul Eggert wrote:
Can you please also check for the following features?
variable declarations in for loops
last member of a struct may be an incomplete array type
varargs macros
named initialization of structs
variable length arrays
long long
These are all features that C99-ish program
Steven G. Johnson wrote:
As you yourself point out, the purpose of the AC_PROG_CC_C99 macro is to
discover compiler flags that put the compiler in a C99-ish mode, *not*
to guarantee that the compiler completely conforms to the C++ standard.
"Steven G. Johnson" <[EMAIL PROTECTED]> writes:
> As you yourself point out, the purpose of the AC_PROG_CC_C99 macro is
> to discover compiler flags that put the compiler in a C99-ish mode,
> *not* to guarantee that the compiler completely conforms to the [C99]
> standard.
Yes, quite clearly it's
