Re: PROBLEM: please remove reserved word "new" from kernel headers

[Jakob Oestergaard <jakob@unthought.net>]

On Wed, Jul 06, 2005 at 02:26:57AM -0700, Rob Prowel wrote:
> [1.] One line summary of the problem:    
> 
> 2.4 and 2.6 kernel headers use c++ reserved word "new"
> as identifier in function prototypes.

Correction:

[1.] One line summary of problem:

Userspace application is making use of private kernel headers.

> 
> [2.] Full description of the problem/report:
> 
> When kernel headers are included in compilation of c++
> programs the compile fails because some header files
> use "new" in a way that is illegal for c++.  This
> shows up when compiling mySQL under linux 2.6.  It
> uses $KERNELSOURCE/include/asm-i386/system.h.

Corrected:

[2.] Full description of the problem/report:

When userspace applications include headers they shouldn't, all kinds of
problems can appear. One example of this shows up when compiling mySQL
under linux 2.6.  It uses $KERNELSOURCE/include/asm-i386/system.h.

...
> While not an error, per se, it is kind of sloppy and
> it is amazing that it hasn't shown up before now. 

It has shown up, and it has been discussed. Search the archives. I'm
pretty sure the exact problem you're reporting was discussed here a few
months back.

> using the identifier "new" in kernel headers that are
> visible to applications programs is a bad idea.

Noone's doing that. Because the headers aren't meant to be visible.

This is not a C vs. C++ problem and it has nothing to do with
'sloppiness'. Something much subtler could have happened had it been C
application code which would have parsed cleanly but just broken in
strange ways (due to assumptions in kernel header code which just happen
to not be met in the userspace code). Actually, you should be greatful
someone used 'new' - at least now the error is caught at compile time ;)

It should be simple to fix MySQL to keep it's dirty little fingers off
of the kernel's private parts..

Really, that is the solution.

Take a look at *what* MySQL is doing with the header. If it is the same
problem (I have not double checked, but I guess chances are good) as was
reported earlier, it's really just a small braindamage in MySQL which is
easily fixed (thus removing the need for inclusion of the header in
question).

-- 

 / jakob