[ELDK] [PATCH] usr/include/error.h, argp.h, and n?curses.h

[Detlev Zundel]

Hi Ryan,

> Thanks for the reply. I have a little more information that should
> prove helpful.
>
> On Fri, Sep 25, 2009 at 8:05 AM, Detlev Zundel <dzu at denx.de> wrote:
>> Hy Ryan,
>>
>> > #including <error.h>, argp.h or n?curses.h breaks __attribute__ , such
>> > that no __attribute__ types will be applied, on any source (including
>> > other #includes) after the offending #include.
>>
>> I'm sorry, but this really makes no sense for me.
>
> OK, see below.
>
>> Did you use native or cross-toolchain?
>
> I'm cross compiling for ppc_4xx.
>
> And, I should have included my compiler flags: after seeing your
> success, I narrowed the compiler flags down to the following minimal
> case:
>
> $ ppc_4xx-gcc -std=c99 s1.c -o s1
>
> In other words, c99 mode is sufficient to trigger the bug with
> <error.h> et. al. Looking at the relevant ppc_4xx/usr/include/error.h
> code (the code I proposed removing in my patch), it's easy to see why:
>
> #ifndef __attribute__
> /* This feature is available in gcc versions 2.5 and later.  */
> # if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) || __STRICT_ANSI__
> #  define __attribute__(Spec) /* empty */
> # endif
> /* The __-protected variants of `format' and `printf' attributes
>    are accepted by gcc versions 2.6.4 (effectively 2.7) and later.  */
> # if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 7)
> #  define __format__ format
> #  define __printf__ printf
> # endif
> #endif
>
> -std=c99 defines __STRICT_ANSI__, which (per the above code) causes
> __attribute__ to always be silently clobbered when error.h et. al. are
> #included. (#ifndef __attribute__ is always true with gcc, regardless
> of the c99 flag, so that check is meaningless.) So I assume we'd see
> the same thing with -std=c89, -ansi, etc.

Ok, I'm now able to verify that this is indeed a problem.  Looking at
newer versions of the mentioned header files, I also see that upstream
has the same fixes in.  By the time we build a new version of our ELDK
and do not upgrade the toolchain, we will include your fixes, thanks.

Cheers
  Detlev

-- 
Each language has its purpose, however humble. Each language expresses
the Yin and Yang of software. Each language has its place within the Tao.

But do not program in COBOL if you can avoid it.
                           -- The Tao of Programming
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de