>>12
>In March 2000, ANSI adopted the ISO/IEC 9899:1999 standard. This standard is commonly referred to as C99, and it is the current standard for C programming language.
IIRC the reason gcc defaults to C89 for -ansi is because they don't support all of C99, but I'm too lazy to confirm that.
>>15
That's weird. All the hardcore C++ programmers out their can't take the efficiency of their language and whip out an optimizing compiler? I mean, these guys understand everything about computers, abstraction, and getting down to the metal.
>>13
The actual reason gcc's -ansi is C89 instead of C99 is because that switch is older than C99, and changing its behavior breaks backward compatibility.
>>17
No, sorry, you're incorrect. Please don't make shit up.
By default, GCC provides some extensions to the C language that on rare occasions conflict with the C standard. See Extensions to the C Language Family. Use of the -std options listed above will disable these extensions where they conflict with the C standard version selected. You may also select an extended version of the C language explicitly with -std=gnu90 (for C90 with GNU extensions), -std=gnu99 (for C99 with GNU extensions) or -std=gnu1x (for C1X with GNU extensions). The default, if no C language dialect options are given, is -std=gnu90; this will change to -std=gnu99 in some future release when the C99 support is complete. Some features that are part of the C99 standard are accepted as extensions in C90 mode. http://gcc.gnu.org/onlinedocs/gcc/Standards.html
>>18
Did you just paste a random passage in the hope that nobody would read it and realise you're full of shit? There's nothing there that has anything to do with >>17-kun's post.
Behold, my aclocal file (just put ENABLE_WARNINGS in configure.in and configure with --enable-warnings, or --enable-warnings=-Werror or whatever). If you're not using autotools, then you're PROBABLY using something inferior. Autotools sucks really hard, but still manages to suck less than SCons, Jam, CMake, or your favorite IDE.
AC_DEFUN([ENABLE_WARNINGS],[
AC_ARG_ENABLE(warnings,
[ --enable-warnings enable warnings for GCC ],
[enable_warnings=$enableval], [warnings=no])
if test "x$enable_warnings" != xno ; then
[warning_cflags="-Wall -Wextra -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wchar-subscripts -Wredundant-decls -pedantic"]
if test "x$enable_warnings" != xyes ; then
[warning_cflags="$warning_cflags $enable_warnings"]
fi
fi
AC_SUBST([warning_cflags])
])
The "-Wshadow" can be a bitch, I have to rename variables e.g. "index" because there is a standard library function named "index".
I used to use "-Wno-unused-parameter" but I turned it on and it caught some bugs so I leave it on now, and stick these in my code:
int always_returns_three(int x)
{
(void)x;
return 3;
}
It's ugly but my code DOES have less bugs now.
As an alternative, plug in "clang" for a bit. It might spit out a bunch of new warnings, they'll often be pretty nice.
Name:
Anonymous2010-08-30 15:57
>>20
As a quick addendum, don't put "-W" options in CFLAGS, put them in a separate variable and then add that variable to AM_CFLAGS in Makefile.am. If you put them in CFLAGS, your configuration script might break, or fail to detect certain libraries that are installed.
>>20
Yeah, the problem with things like SCons and CMake is that the developers of these tools never really have experienced the need to have full control over the build process. They're lazy developers who don't care about actual REAL WORLD use cases.
Name:
Anonymous2010-08-30 21:26
>>22
You don't have full control over the build process until you've written your makefiles and configure script by hand.