[pacman-dev] gnu89-inline

Dan McGee dpmcgee at gmail.com
Sat Apr 2 14:26:51 EDT 2011


On Sat, Apr 2, 2011 at 1:18 PM, Xavier Chantry <chantry.xavier at gmail.com> wrote:
> On Sat, Apr 2, 2011 at 7:49 PM, Dan McGee <dpmcgee at gmail.com> wrote:
>> On Sat, Apr 2, 2011 at 12:17 PM, Xavier Chantry
>> <chantry.xavier at 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 at 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 at 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 at galway ~/projects/pacman-maint (maint)
    $ git grep 'for(int' | cat
    src/pacman/util.c:			for(int d = start; d <= end; d++) {

-Dan


More information about the pacman-dev mailing list