>> Mr. Misra's difficulty had nothing to do with C/C++ wars. It came from
the
>> headers' reliance on a [bug,quirk,feature,extension] of gcc.
>
>We need to use those extensions
I don't think that one (the absent semicolon) is essential.
>
>> Even if the kernel itself is forever joined at the hip to gcc-2.7.2, it
>> would be only civilized to arrange for the headers to be legal ANSI. Many
of
>
>Why ? Certainly glibc should be exporting highly clean and legal ANSI
headers
>to applications, but kernel space happens to need __inline__ and __asm__
>and the like. egcs understands these and also gcc calling conventions.
__inline__ and __asm__ are fine for ANSI; they are gcc macros. Their purpose
is to allow portable headers using the gcc inline and asm keywords. C++
doesnt mind the gcc "inline" keyword, and it probably even does the right
thing most of the time. Kernel headers using __inline__ are not a problem.
Many kernel headers use "extern inline" raw. C++ doesnt mind, egcs
understands it, but "gcc -ansi" will puke.
[...]
>Fixing the use of "private" -> "priv" and similar in the kernel is
eminiently
>reasonable. Trying to write kernel code with another compiler is going to
give
>you a very bad headache. AFAIK the only folks who did it were the linux
8086
>people and even then it was non trivial - thats not even a port but an
offshoot
>of a subset of the kernel code.
I don't think rewriting the kernel is the issue. Obtaining prototypes of
exported symbols is the main reason people include headers.
>
>Alan
>
Will you consider accepting header patches for ansification?
Regards,
Tom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/