Re: linux headers and C++

Alan Cox (alan@lxorguk.ukuu.org.uk)
Tue, 6 Jul 1999 21:27:58 +0100 (BST)


> 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

> 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.

The problem with g++ modules are actually two fold. The first is that g++
has ideas about things like private, new and other quite sane (to C programmers)
normal variable names being keywords). The second one is that it wants to
use new and destroy. You can provide your own new/destroy wrappers using
the kmalloc/kfree functions although you have to be careful to handle failure
cases. The conventional C++ "out of memory" message and quit wont cut it in
a kernel.

There are side issues - stack usage is hard to track in much C++ code, g++ used
at least to have terrible problems remembering about volatile and you can't
expect stuff like exceptions to work.

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.

Alan

-
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/