On Sat, Apr 2, 2011 at 7:49 PM, Dan McGee wrote:

On Sat, Apr 2, 2011 at 12:17 PM, Xavier Chantry wrote:

...

I am just curious, what do we need this flag for ?

Searching commits, it wasn't too hard to find this, although I don't know the full context or relevance. Not sure if it was just a GCC bug at the time?

commit d8e88aa0175fd950d007578ea0690952f49247f1 Author: Dan McGee Date:   Tue Jun 5 17:32:09 2007 -0400

   Fix compilation with GCC 4.2.0

   'inline' keyword in C99 is not correctly recognized, so compilation fails on    the warning it spits. This fixes this.

   Signed-off-by: Dan McGee

I also see this in the GCC 4.2.0 release notes, which is surely what I was referring to at the time:

In the next release of GCC, 4.3, -std=c99 or -std=gnu99 will direct GCC to handle inline functions as specified in the C99 standard. In preparation for this, GCC 4.2 will warn about any use of non-static inline functions in gnu99 or c99 mode. This new warning may be disabled with the new gnu_inline function attribute or the new -fgnu89-inline command-line option. Also, GCC 4.2 and later will define one of the preprocessor macros __GNUC_GNU_INLINE__ or __GNUC_STDC_INLINE__ to indicate the semantics of inline functions in the current compilation.

So now the question is whether you still want to support gcc 4.2 ? You are always much more conservative than I am :)

...

Anyway it looks like we could use -std=gnu89 alternatively ? ... which brings to another topic that was brought recently on the ML : I tried to build with that and got a lot of warnings :) ../../lib/libalpm/alpm.h:396:29: warning: commas at the end of enumerator lists are a C99-specific feature [-pedantic] pacman.c:1201:8: warning: ISO C90 forbids mixing declarations and code [-Wdeclaration-after-statement] util.c:797:8: warning: variable declaration in for loop is a C99-specific feature [-pedantic]

How many are there; did you just trim the list down? If it is easy to fix then we might think about doing so.

Yes there were many in total, several of each. IMO warning 1 and 3 are must-have c99 features so I am for using these everywhere and certainly not for removing them :) I am fine with fixing declaration-after-statement, and IIRC there were just a few.

On Sun, Apr 3, 2011 at 10:04 AM, Xavier Chantry wrote:

On Sun, Apr 3, 2011 at 6:55 AM, Sebastian Nowicki wrote:

...

Looks like there are more warnings when using gnu89:

$ make 2>&1 | grep 'warning:' | cut -d' ' -f3- | sort | uniq -c     74 comma at end of enumerator list      1 initializer element is not computable at load time      7 ISO C90 does not support the 'j' gnu_printf length modifier    106 ISO C90 does not support the 'z' gnu_printf length modifier     41 ISO C90 forbids mixed declarations and code     57 ISO C90 forbids specifying subobject to initialize

There are lots of duplicates (173 -> 58 warnings after removing them).      4 commas at the end of enumerator lists are a C99-specific feature [-pedantic]      2 extension used [-pedantic]     50 ISO C90 forbids mixing declarations and code [-Wdeclaration-after-statement]      2 variable declaration in for loop is a C99-specific feature [-pedantic]

Actually that was the clang result while Seb posted results with gcc. In that case, removing duplicates goes from 286 to 214 (mostly comma at end of enumerator list from alpm.h) grep warning make-gcc.log | sort -u | cut -d' ' -f3- | sort | uniq -c 4 comma at end of enumerator list 1 initializer element is not computable at load time 6 ISO C90 does not support the 'j' gnu_printf length modifier 105 ISO C90 does not support the 'z' gnu_printf length modifier 41 ISO C90 forbids mixed declarations and code 57 ISO C90 forbids specifying subobject to initialize

On Sun, Apr 3, 2011 at 3:46 AM, Sebastian Nowicki wrote:

On Sun, Apr 3, 2011 at 4:12 PM, Xavier Chantry wrote:

...

On Sun, Apr 3, 2011 at 10:04 AM, Xavier Chantry wrote:

...

On Sun, Apr 3, 2011 at 6:55 AM, Sebastian Nowicki wrote:

...

Looks like there are more warnings when using gnu89:

$ make 2>&1 | grep 'warning:' | cut -d' ' -f3- | sort | uniq -c     74 comma at end of enumerator list      1 initializer element is not computable at load time      7 ISO C90 does not support the 'j' gnu_printf length modifier    106 ISO C90 does not support the 'z' gnu_printf length modifier     41 ISO C90 forbids mixed declarations and code     57 ISO C90 forbids specifying subobject to initialize

There are lots of duplicates (173 -> 58 warnings after removing them).      4 commas at the end of enumerator lists are a C99-specific feature [-pedantic]      2 extension used [-pedantic]     50 ISO C90 forbids mixing declarations and code [-Wdeclaration-after-statement]      2 variable declaration in for loop is a C99-specific feature [-pedantic]

Actually that was the clang result while Seb posted results with gcc. In that case, removing duplicates goes from 286 to 214 (mostly comma at end of enumerator list from alpm.h)

grep warning make-gcc.log | sort -u | cut -d' ' -f3- | sort | uniq -c       4 comma at end of enumerator list      1 initializer element is not computable at load time      6 ISO C90 does not support the 'j' gnu_printf length modifier     105 ISO C90 does not support the 'z' gnu_printf length modifier      41 ISO C90 forbids mixed declarations and code     57 ISO C90 forbids specifying subobject to initialize

Any reason not to move to C99? I believe the 'j' and 'z' length modifiers are standard in C99, along with mixed declarations and probably commas at the end of enums. The code doesn't conform to C90 atm anyway. Not exactly compelling arguments, but it would be good to explicitly define which standard the code base should conform to.

We're already using C99, so this would be nothing new. Note how configure.ac asks for a C99 compiler specifically- AC_PROG_CC_C99. The only thing that I see as potentially worth it out of this is making alpm.h and alpm_list.h C89 compliant, if we even do that. -Dan