Any need for __cplusplus?

KJ Richard Knutsson 6 participants 11 messages Apr 3, 2007 – Apr 4, 2007 Kernel janitors

Share & tools

Richard Knutsson

author

2007-04-03 07:26 UTC #0 lore raw

Hello

There were recently a thread in LKML about C++-usage in the kernel (again). That reminded me, why do we have those "ifdef __cplusplus"? As an example, we have this (in include/linux/stddef.h) when defining NULL as 0 in C++ and ((void *)0) otherwise. From what I can see, there is no reason to have them, or am I missing something? (like they are needed by libraries)

Quoted 1 line

grep -nr cplusplus * | wc -l

121

Richard Knutsson

_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

[email protected]

2007-04-03 08:58 UTC #1 lore raw

Quoted 11 lines · Richard Knutsson

There were recently a thread in LKML about C++-usage in the kernel (again). That reminded me, why do we have those "ifdef __cplusplus"? As an example, we have this (in include/linux/stddef.h) when defining NULL as 0 in C++ and ((void *)0) otherwise. From what I can see, there is no reason to have them, or am I missing something? (like they are needed by libraries)
Quoted 1 line
grep -nr cplusplus * | wc -l
121

most of them are in
./scripts/genksyms/keywords.c_shipped
./scripts/genksyms/lex.c_shipped
./scripts/genksyms/parse.c_shipped
./scripts/kconfig/expr.h
./scripts/kconfig/lex.zconf.c_shipped
./scripts/kconfig/lkc.h
./scripts/kconfig/zconf.hash.c_shipped
./scripts/kconfig/zconf.tab.c_shipped
./Documentation/DocBook/kernel-hacking.tmpl
this shouldn't be a surprise

./include/linux/linkage.h
./include/linux/socket.h
./include/linux/stddef.h
./include/linux/string.h
if included from userspace

donno
./arch/ppc/mm/mem_pieces.h
./drivers/media/video/pwc/pwc.h

./drivers/net/sk98lin/h/lm80.h ./drivers/net/sk98lin/h/skaddr.h ./drivers/net/sk98lin/h/skgehw.h ./drivers/net/sk98lin/h/skgeinit.h ./drivers/net/sk98lin/h/skrlmt.h ./drivers/net/sk98lin/h/xmac_ii.h ./drivers/net/sk98lin/skaddr.c ./drivers/net/sk98lin/skdim.c ./drivers/net/sk98lin/skrlmt.c
i read some where that drivers are sometimes compile tested in userspace

drivers/md/raid6.h:114:/* Some definitions to allow code to be compiled for testing in userspace */
dosen't seem to be the case here but still.....

CMIIW

Milind A Choudhary

_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Jaco Kroon

2007-04-03 09:30 UTC #2 lore raw

In reply to Richard Knutsson

Quoted 8 lines · Richard Knutsson

Hello
There were recently a thread in LKML about C++-usage in the kernel (again). That reminded me, why do we have those "ifdef __cplusplus"? As an example, we have this (in include/linux/stddef.h) when defining NULL as 0 in C++ and ((void *)0) otherwise. From what I can see, there is no reason to have them, or am I missing something? (like they are needed by libraries)

Many of these headers are exported to userspace, eg the linux-headers package on many linux distributions. If a user includes them from a C++ program, they shouldn't break.

Jaco
_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Robert P. J. Day

2007-04-03 10:40 UTC #3 lore raw

In reply to Richard Knutsson

Quoted 11 lines · Jaco Kroon

Quoted 9 lines · Richard Knutsson
Hello
There were recently a thread in LKML about C++-usage in the kernel (again). That reminded me, why do we have those "ifdef __cplusplus"? As an example, we have this (in include/linux/stddef.h) when defining NULL as 0 in C++ and ((void *)0) otherwise. From what I can see, there is no reason to have them, or am I missing something? (like they are needed by libraries)

Quoted 3 lines

Many of these headers are exported to userspace, eg the linux-headers package on many linux distributions. If a user includes them from a C++ program, they shouldn't break.

the obvious question is this: is the kernel officially C++-free? that is, is the *only* reason one would see that C++ check is if something is being exported to userspace?

if that's the case, the obvious approach is to generate the sanitized headers with "make headers_install" and see what C++ references are left:

$ make distclean
$ make headers_install
$ cd usr/include
$ grep -r cplusplus *
linux/stddef.h:#if defined(__cplusplus)
linux/socket.h:#elif defined(__cplusplus)
$

and that's it. if the kernel is truly C++-free, then there should be *no* C++ tests within the bounds of a "#ifdef __KERNEL__" test, isn't that right? but it's not that simple.

consider, for example, the header file drivers/net/sk98lin/h/skgehw.h:

...
#ifndef __INC_SKGEHW_H
#define __INC_SKGEHW_H

#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
...

note how that C++ test is not protected by a __KERNEL__ test but, on the other hand, it's not exported to userspace either. so what's the
point of the C++ test if userspace never sees that header file? yes,
it would seem that there are a lot of worthless C++ tests that could be removed if they never make it to userspace.

thoughts?

rday

Signature · 11 lines

====================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
====================================
_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Richard Knutsson

author

2007-04-03 22:50 UTC #4 lore raw

In reply to Richard Knutsson

Hi and thank you all for your responses

Quoted 51 lines · Robert P. J. Day

Quoted 12 lines · Jaco Kroon
Quoted 10 lines · Richard Knutsson
Hello
There were recently a thread in LKML about C++-usage in the kernel (again). That reminded me, why do we have those "ifdef __cplusplus"? As an example, we have this (in include/linux/stddef.h) when defining NULL as 0 in C++ and ((void *)0) otherwise. From what I can see, there is no reason to have them, or am I missing something? (like they are needed by libraries)
Quoted 4 lines
Many of these headers are exported to userspace, eg the linux-headers package on many linux distributions. If a user includes them from a C++ program, they shouldn't break.
the obvious question is this: is the kernel officially C++-free? that is, is the *only* reason one would see that C++ check is if something is being exported to userspace?
if that's the case, the obvious approach is to generate the sanitized headers with "make headers_install" and see what C++ references are left:
$ make distclean
$ make headers_install
$ cd usr/include
$ grep -r cplusplus *
linux/stddef.h:#if defined(__cplusplus)
linux/socket.h:#elif defined(__cplusplus)
$
and that's it. if the kernel is truly C++-free, then there should be *no* C++ tests within the bounds of a "#ifdef __KERNEL__" test, isn't that right? but it's not that simple.
consider, for example, the header file drivers/net/sk98lin/h/skgehw.h:
...
#ifndef __INC_SKGEHW_H
#define __INC_SKGEHW_H
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
...

Quoted 6 lines

note how that C++ test is not protected by a __KERNEL__ test but, on the other hand, it's not exported to userspace either. so what's the
point of the C++ test if userspace never sees that header file? yes,
it would seem that there are a lot of worthless C++ tests that could be removed if they never make it to userspace.

Yep, and just found a few C/C++ structs not even _used_ in the kernel... Guess the __cplusplus may be worth a look or two since it seems to be possible indicator of old cruft.

Thanks for reminding about "headers_install".

Richard Knutsson

_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Robert P. J. Day

2007-04-03 23:13 UTC #5 lore raw

In reply to Richard Knutsson

On Wed, 4 Apr 2007, Richard Knutsson wrote:

... snip ...

Quoted 5 lines

Yep, and just found a few C/C++ structs not even _used_ in the kernel... Guess the __cplusplus may be worth a look or two since it seems to be possible indicator of old cruft.
Thanks for reminding about "headers_install".

so is there anyone on this list who can make a confident proclamation about this C++ stuff in the kernel source one way or the other?

rday

Signature · 11 lines

====================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
====================================
_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Robert P. J. Day

2007-04-03 23:22 UTC #6 lore raw

In reply to Richard Knutsson

Quoted 1 line · Richard Knutsson

Yep, and just found a few C/C++ structs not even _used_ in the kernel...

i'm not sure what that means ... can you explain that? with an example or two?

rday

Signature · 11 lines

====================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
====================================
_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Howell, David P

2007-04-03 23:34 UTC #7 lore raw

In reply to Richard Knutsson

Every time I heard it come up in the kernel mailing list it was emphatically
"No". Only other use I could see would be for source that applies for the kernel and possibly some other application use where C++ can be used.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Robert P. J. Day
Sent: Tuesday, April 03, 2007 7:14 PM
To: Richard Knutsson
Cc: [email protected]
Subject: Re: [KJ] Any need for __cplusplus?

On Wed, 4 Apr 2007, Richard Knutsson wrote:

... snip ...

Quoted 5 lines

Yep, and just found a few C/C++ structs not even _used_ in the kernel... Guess the __cplusplus may be worth a look or two since it seems to be possible indicator of old cruft.
Thanks for reminding about "headers_install".

so is there anyone on this list who can make a confident proclamation about this C++ stuff in the kernel source one way or the other?

rday

Signature · 16 lines

====================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
====================================
_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Richard Knutsson

author

2007-04-04 01:41 UTC #8 lore raw

In reply to Richard Knutsson

Quoted 9 lines · Robert P. J. Day

Quoted 2 lines · Richard Knutsson
Yep, and just found a few C/C++ structs not even _used_ in the kernel...
i'm not sure what that means ... can you explain that? with an example or two?

The ones I was talking about is in drivers/scsi/dpt/sys_info.h. Only found sysInfo_S to be used (by drivers/scsi/dpt_i2o.c).

_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Randy Dunlap

2007-04-04 02:14 UTC #9 lore raw

In reply to Richard Knutsson

Quoted 4 lines · On Wed, 04 Apr 2007 03:41:56 +0200 Richard Knutsson wrote:

Quoted 3 lines · Robert P. J. Day
On Wed, 4 Apr 2007, Richard Knutsson wrote:

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
Yep, and just found a few C/C++ structs not even _used_ in the kernel...
i'm not sure what that means ... can you explain that? with an example or two?
The ones I was talking about is in drivers/scsi/dpt/sys_info.h. Only found sysInfo_S to be used (by drivers/scsi/dpt_i2o.c).

Interesting. Those structs don't seem to be used.

Vendor drivers historically have carried excess baggage in Linux, often for "management application" purposes.
I doubt that that driver would be merged in that same condition today.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
_______________________________________________
Kernel-janitors mailing list [email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Robert P. J. Day

2007-04-04 10:25 UTC #10 lore raw

In reply to Richard Knutsson

Quoted 12 lines · Randy Dunlap

Quoted 10 lines · On Wed, 04 Apr 2007 03:41:56 +0200 Richard Knutsson wrote:
Quoted 9 lines · Robert P. J. Day
Quoted 2 lines · Richard Knutsson
Yep, and just found a few C/C++ structs not even _used_ in the kernel...
i'm not sure what that means ... can you explain that? with an example or two?

Quoted 8 lines

Quoted 2 lines
The ones I was talking about is in drivers/scsi/dpt/sys_info.h. Only found sysInfo_S to be used (by drivers/scsi/dpt_i2o.c).
Interesting. Those structs don't seem to be used.
Vendor drivers historically have carried excess baggage in Linux, often for "management application" purposes. I doubt that that driver would be merged in that same condition today.

under the circumstances, then, i would think that it's fair to rip out anything related to C++ that is not *currently* and *explicitly* exported to userspace for a good reason.

and i would pay no mind to the inevitable whiners who like to say things like, "well, it's for future use." if it eventually becomes useful, they can always put it back in sometime down the road.

rday

Signature · 11 lines

====================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
====================================
_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors