Re: unhappy with current.h

[Mikael Pettersson <mikpe@csd.uu.se>]

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