Bug 15983

Summary: C++ keywords in kernel header files
Product: Base System Reporter: afo <afo>
Component: kernAssignee: Nick Hibma <n_hibma>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description afo 2000-01-08 11:10:01 UTC 
use of c++ keyword 'class' in kernel header file 
dev/sub/usb.h, around line 496 in struct usb_device_info
i this need this header file for application programming.

problem affects current kernel source - cvsup'd 2000/01/08 - too 

i hope the included patch catches all access of the class field
of struct usb_device_info

Fix: cvs diff: Diffing .
How-To-Repeat: compile the following sample code with g++ -I/src/sys/dev -c main.c:
-- begin main.c --
#include <usb/usb.h>
-- end main.c --

compile gives:
In file included from main.c:1:
/usr/src/sys/dev/usb/usb.h:476: parse error before `;'
Comment 1 Nick Hibma freebsd_committer freebsd_triage 2000-01-10 00:00:30 UTC 
Responsible Changed
From-To: freebsd-bugs->n_hibma

usb.h is mine.
Comment 2 dhagan 2000-01-18 16:19:44 UTC 
Why not wrap your application level include in an extern "C" construct?  
It seems like this would make more sense (as the kernel is written in C,
and you're the one importing it into a C++ context).  I don't see any
reason to make the kernel's C-coders responsible for C++ compatibility, do
you?

Daniel

-- 
Daniel Hagan                                             Computer Science CSE
dhagan@cs.vt.edu                                http://www.cs.vt.edu/~dhagan/
Comment 3 n_hibma 2000-01-18 17:18:47 UTC 
The reason for the delay is simply that the class,subclass,etc. fields
should go away completely. It's duplicate info that can be read from the
device/configuration/interface descriptors.

But it'll have to change (says dfr and he looked like he was sure
about that :-) It'll break the utils that are based on it.

Nick

On Tue, 18 Jan 2000, Daniel Hagan wrote:

> Why not wrap your application level include in an extern "C" construct?  
> It seems like this would make more sense (as the kernel is written in C,
> and you're the one importing it into a C++ context).  I don't see any
> reason to make the kernel's C-coders responsible for C++ compatibility, do
> you?
> 
> Daniel
> 
> -- 
> Daniel Hagan                                             Computer Science CSE
> dhagan@cs.vt.edu                                http://www.cs.vt.edu/~dhagan/
> 
> 

--
n_hibma@webweaving.org
n_hibma@freebsd.org                                          USB project
http://www.etla.net/~n_hibma/
Comment 4 John-Mark Gurney freebsd_committer freebsd_triage 2003-06-21 01:21:32 UTC 
State Changed
From-To: open->closed

this has been fixed by prepending udi_ to the field.