Messages in this thread | | | Subject | Re: linux headers and C++ | Date | Tue, 6 Jul 1999 21:27:58 +0100 (BST) | From | Alan Cox <> |
| |
> 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/
| |