[pacman-dev] gnu89-inline
I am just curious, what do we need this flag for ? I only found this : http://gcc.gnu.org/onlinedocs/gcc/Inline.html GCC implements three different semantics of declaring a function inline. One is available with -std=gnu89 or -fgnu89-inline or when gnu_inline attribute is present on all inline declarations, another when -std=c99, -std=c1x, -std=gnu99 or -std=gnu1x (without -fgnu89-inline), and the third is used when compiling C++. There is a small annoyance with clang, the configure check believes fgnu89-inline is supported because clang only emits a warning when that flag is specified : checking for -fgnu89-inline... yes So every libalpm file triggers this warning when building : clang: warning: argument unused during compilation: '-fgnu89-inline' 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] ...
On Sat, Apr 2, 2011 at 12:17 PM, Xavier Chantry <chantry.xavier@gmail.com> 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 <dan@archlinux.org> 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 <dan@archlinux.org> 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.
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. -Dan
On Sat, Apr 2, 2011 at 7:49 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Sat, Apr 2, 2011 at 12:17 PM, Xavier Chantry <chantry.xavier@gmail.com> 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 <dan@archlinux.org> 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 <dan@archlinux.org>
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 Sat, Apr 2, 2011 at 1:18 PM, Xavier Chantry <chantry.xavier@gmail.com> wrote:
On Sat, Apr 2, 2011 at 7:49 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Sat, Apr 2, 2011 at 12:17 PM, Xavier Chantry <chantry.xavier@gmail.com> 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 <dan@archlinux.org> 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 <dan@archlinux.org>
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.
I'm mixed feelings, looking at it again: * commas at the end of enumerator lists: great to have, but we also do it in the worst possible place- a public header file. * variable declaration in for loop: for a "must-have", we only do it once in our entire codebase (in a function written by you), so it is easily fixable: dmcgee@galway ~/projects/pacman-maint (maint) $ git grep 'for(int' | cat src/pacman/util.c: for(int d = start; d <= end; d++) { -Dan
On Sun, Apr 3, 2011 at 1:17 AM, Xavier Chantry <chantry.xavier@gmail.com>wrote:
I am just curious, what do we need this flag for ?
I only found this : http://gcc.gnu.org/onlinedocs/gcc/Inline.html GCC implements three different semantics of declaring a function inline. One is available with -std=gnu89 or -fgnu89-inline or when gnu_inline attribute is present on all inline declarations, another when -std=c99, -std=c1x, -std=gnu99 or -std=gnu1x (without -fgnu89-inline), and the third is used when compiling C++.
There is a small annoyance with clang, the configure check believes fgnu89-inline is supported because clang only emits a warning when that flag is specified : checking for -fgnu89-inline... yes
So every libalpm file triggers this warning when building : clang: warning: argument unused during compilation: '-fgnu89-inline'
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] ...
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
On Sun, Apr 3, 2011 at 6:55 AM, Sebastian Nowicki <sebnow@gmail.com> 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] Seems like I was also confused by the high number of repetition of the first warning in my previous post. My opinion is still the same though : - commas the end of enum lists : much nicer for adding new items at the end - variable declaration in for loop : further reducing of variable scope. its silly to always need to put the i in the outer block.
On Sun, Apr 3, 2011 at 10:04 AM, Xavier Chantry <chantry.xavier@gmail.com> wrote:
On Sun, Apr 3, 2011 at 6:55 AM, Sebastian Nowicki <sebnow@gmail.com> 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 4:12 PM, Xavier Chantry <chantry.xavier@gmail.com>wrote:
On Sun, Apr 3, 2011 at 10:04 AM, Xavier Chantry <chantry.xavier@gmail.com> wrote:
On Sun, Apr 3, 2011 at 6:55 AM, Sebastian Nowicki <sebnow@gmail.com> 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.
On Sun, Apr 3, 2011 at 3:46 AM, Sebastian Nowicki <sebnow@gmail.com> wrote:
On Sun, Apr 3, 2011 at 4:12 PM, Xavier Chantry <chantry.xavier@gmail.com>wrote:
On Sun, Apr 3, 2011 at 10:04 AM, Xavier Chantry <chantry.xavier@gmail.com> wrote:
On Sun, Apr 3, 2011 at 6:55 AM, Sebastian Nowicki <sebnow@gmail.com> 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
participants (3)
-
Dan McGee
-
Sebastian Nowicki
-
Xavier Chantry