[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#218482: linux-kernel-headers: Some headers seem to expand inline twice



On Fri, Oct 31, 2003 at 04:45:11PM +0000, Bruce Stephens wrote:
> Package: linux-kernel-headers
> Version: 2.5.999-test7-bk-5
> Severity: normal
> 
> The following simple C++ program doesn't compile.  (I presume it's
> expected that things like signal.h should be available in C++.)

Yes, though it should be:

> 
> #include <iostream>
> extern "C"
> {
> #include <signal.h>
> }

#include <iostream>
#inclde <csignal>


> class Foo
> {
> public:
>   void inline hello ()
>   {
>     std::cout << "hello\n";
>   }
> } foo;
> 
> int
> main ()
> {
>   foo.hello ();
>   exit (0);
> }
> 
> The error seems to be caused by the inclusion of one or more of these
> files:
> 
> /usr/include/linux/compiler-gcc.h
> /usr/include/linux/compiler-gcc3.h
> /usr/include/linux/compiler.h
> 
> After preprocessing, the method looks like this:
> 
>         void __inline__ __attribute__((always_inline)) __attribute__((always_inline)) hello()
>         {
>         std::cout << "hello\n";
>         }
> 
> and g++ reports:
> 
> test.C:10: error: declaration does not declare anything
> test.C:10: error: parse error before `__attribute__'
> test.C:14: error: ISO C++ forbids declaration of `foo' with no type

I don't know if the parse error is a C++ bug or not.  However, the
__attribute__ should not be used in user-space anyway.  I'll fix
linux-kernel-headers.

> However, my reading of the allowable grammar (it's in Appendix A.6 of
> the ANSI standard) suggests that these are all decl-specifiers, and
> any ordering ought to be allowed.  (That's not conclusive, since
> typedef is in the same list, and I doubt it's intended that "double
> typedef ..." is intended to be legal.  But without including signal.h,
> g++ accepts either ordering, so that suggests that the intent is to
> allow "void inline" as equivalent to "inline void", and that one of
> these headers is subverting that.)

Well, __attribute__ isn't exactly a decl-specifier.  It's a GCC/G++
extension and it gets parsed however g++ happens to feel like it that
day.  Oh, and I think "double typedef" is actually legal:
  double typedef bd_type;

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer



Reply to: