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/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:57 EST