Messages in this thread | | | From | Mikael Pettersson <> | Date | Tue, 15 Oct 2002 23:01:27 +0200 | Subject | Re: unhappy with current.h |
| |
Daniele Lugli writes: > Mikael Pettersson wrote: > > > > Rik van Riel writes: > > > On Mon, 14 Oct 2002, Chris Wedgwood wrote: > > > > On Mon, Oct 14, 2002 at 09:46:08PM +0200, Daniele Lugli wrote: > > > > > > > > > I recently wrote a kernel module which gave me some mysterious > > > > > problems. After too many days spent in blood, sweat and tears, I found the cause: > > > > > > > > > *** one of my data structures has a field named 'current'. *** > > > > > > > > gcc -Wshadow > > > > > > Would it be a good idea to add -Wshadow to the kernel > > > compile options by default ? > > > > While I'm not defending macro abuse, please note that Daniele's problem > > appears to have been caused by using g++ instead of gcc or gcc -x c to > > compile a kernel module. Daniele's later example throws a syntax error > > in gcc, since the cpp output isn't legal C ... > > > > Hence I fail to see the utility of hacking in kludges for something > > that's not supposed to work anyway. > > Yes i confess, i'm writing a kernel module in c++ (and i'm not the only > one). > Anyway my consideration was general and IMHO applies to C too. What is > the benefit of redefining commonly used words? I would say nothing > against eg #define _I386_current get_current(), but just #define current > get_current() seems to me a little bit dangerous. What is the limit? > What do you consider a bad practice? Would #define i j be tolerated?
As I wrote above: "While I'm not defending macro abuse". #define i j is definitely macro abuse, and no sane programmer should do it.
Any programming language has a set of reserved words, and any large piece of software has its own reserved words. Think of C++ "this" or C typedef names, for example. You don't expect new code to work if it violates the syntax of the system in which it is compiled, do you?
"current" is just that: one of the Linux kernel's reserved words, one that kernel programmers are supposed to know about.
> But let me at least summarize my poor-programmer-not-kernel-developer > point of view: at present the kernel if a mined field for c++ and i > understand it is not viable nor interesting for the majority to rewrite > it in a more c++-friendly way. But why not at least keep in mind, while > writing new stuff (not the case of current.h i see), that kernel headers > could be included by c++?
1. The kernel is not written in C++. 2. C++ is not C, and a C++ compiler is not a substitute for a C compiler. 3. User-space should't include raw kernel headers but "sanitized" ones, provided e.g. by the C library.
Ergo, the kernel headers should never be processed by a C++ compiler, and anyone doing it anyway is on their own.
/Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |