C++ doesn't like asm/atomic.h

asm/atomic.h is not palatable to C++ due to it's use of the C++ keyword "new".

Script started on Fri Apr 5 12:03:38 2002 elm3a87.eng:/home/garyh cat x.C
#include <asm/atomic.h>
elm3a87.eng:/home/garyh c++ -c x.C
In file included from x.C:1:
/usr/include/asm/atomic.h: In function `int ia64_atomic_add (int, atomic_t *)':
/usr/include/asm/atomic.h:33: parse error before new' /usr/include/asm/atomic.h:39: parse error before =' /usr/include/asm/atomic.h:41: parse error before ;' /usr/include/asm/atomic.h: In function int ia64_atomic_sub (int, atomic_t *)':
/usr/include/asm/atomic.h:47: parse error before new' /usr/include/asm/atomic.h:53: parse error before =' /usr/include/asm/atomic.h:54: parse error before )' /usr/include/asm/atomic.h:54: _n_' undeclared (first use this function)
/usr/include/asm/atomic.h:54: (Each undeclared identifier is reported only once for each function it appears in.) /usr/include/asm/atomic.h:55: parse error before `;' elm3a87.eng:/home/garyh exit
exit

Script done on Fri Apr 5 12:03:55 2002

Patch for 2.4.18 included below.

Gary

Gary Hade
IBM Linux Technology Center
503-578-4503  IBM T/L: 775-4503
[email protected]
http://www.ibm.com/linux/ltc


--- linux/include/asm-ia64/atomic.h.orig	Fri Apr  5 11:56:12 2002
+++ linux/include/asm-ia64/atomic.h	Fri Apr  5 11:55:21 2002
@@ -30,29 +30,29 @@
 static __inline__ int
 ia64_atomic_add (int i, atomic_t *v)
 {
-	__s32 old, new;
+	__s32 old_val, new_val;
 	CMPXCHG_BUGCHECK_DECL
 
 	do {
 		CMPXCHG_BUGCHECK(v);
-		old = atomic_read(v);
-		new = old + i;
-	} while (ia64_cmpxchg("acq", v, old, old + i, sizeof(atomic_t)) != old);
-	return new;
+		old_val = atomic_read(v);
+		new_val = old_val + i;
+	} while (ia64_cmpxchg("acq", v, old_val, old_val + i, sizeof(atomic_t)) != old_val);
+	return new_val;
 }
 
 static __inline__ int
 ia64_atomic_sub (int i, atomic_t *v)
 {
-	__s32 old, new;
+	__s32 old_val, new_val;
 	CMPXCHG_BUGCHECK_DECL
 
 	do {
 		CMPXCHG_BUGCHECK(v);
-		old = atomic_read(v);
-		new = old - i;
-	} while (ia64_cmpxchg("acq", v, old, new, sizeof(atomic_t)) != old);
-	return new;
+		old_val = atomic_read(v);
+		new_val = old_val - i;
+	} while (ia64_cmpxchg("acq", v, old_val, new_val, sizeof(atomic_t)) != old_val);
+	return new_val;
 }
 
 /*

Gary> asm/atomic.h is not palatable to C++ due to it's use of the Gary> C++ keyword "new".

Eh, the kernel is written in C. If you have an application that includes a kernel header, fix the application---it's broken. (This has been Linus' edict for the last N years, for some N > 3...)

	--david

Oops, I must admit that my gray matter is definitely corrupted by working on systems where there was an effort to use #ifdef __KERNEL__ to keep all kernel-only code from being included in user-level application code.

Would it be okay in the Linux world for an application written in C++ to use a system call such as query_module(2)? If so, the application code would include <linux/module.h>. <linux/module.h> includes <asm/atomic.h> on a line which is not within an #ifdef __KERNEL__ region so the same C++ compile failure will occur.

Gary

Gary> Would it be okay in the Linux world for an application written Gary> in C++ to use a system call such as query_module(2)?

Of course.

Gary> If so,
Gary> the application code would include <linux/module.h>. Gary> <linux/module.h> includes <asm/atomic.h> on a line which is Gary> not within an #ifdef __KERNEL__ region so the same C++ compile Gary> failure will occur.

No, glibc needs to provide its own headers for this purpose.

	--david

Wrong. If you want this kind of functionality create your own module-dev package. It is unfortunate that we have any such header in glibc butnot changeable. I certainly will not add more.

---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Uli> Wrong. If you want this kind of functionality create your own Uli> module-dev package. It is unfortunate that we have any such Uli> header in glibc butnot changeable. I certainly will not add Uli> more.

So you're OK with glibc providing the syscall stubs for module*(), but not the header files required to use them?

	--david

Yes. There is no fundamental problems with this.

---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

David, did you mean to say "... in having glibc not provide ..."?

                                                ^^^

I notice that the *_module(2) man pages which advocate the use of #include <linux/module.h> are installed as part of the modutils package. Is is possibly "modutils" that should provide the header file that avoids sucking in the possibly problematic kernel-only code.

Gary

Uli> Yes. There is no fundamental problems with this.

I guess I don't really see the harm in having glibc provide a header for these system call, but as long as the syscall stubs are there, it's probably not a huge issue in practice.

	--david

David, you are around long enough to see the dangers. I don't want to have any dependencies on the kernel. Any change in the kernel interface would force me to make a new release which isn't going to happen.

---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Gary> David, did you mean to say "... in having glibc not provide Gary> ..."?

Nope. My preference would be for glibc to provide such a header. Though I see Uli's point about kernel changes.

Gary> I notice that the *_module(2) man pages which
Gary> advocate the use of #include <linux/module.h> are installed as Gary> part of the modutils package. Is is possibly "modutils" that Gary> should provide the header file that avoids sucking in the Gary> possibly problematic kernel-only code.

That certainly would work for me.

	--david

Old man pages (1996). They date from the time that the kernel and glibc shared the kernel headers via a symlink. Linus has changed his mind since then but the modutils man pages were never updated.

modutils provides include/module.h as part of the source package. That file is not installated anywhere, nobody outside modutils has required it. If you want to invoke the modutils syscalls yourself, take a copy of include/module.h from modutils into your source tree. But don't be surprised if the interface changes under you. modutils will know about any interface changes, other packages will have to cope with the version skew themselves.

FYI, I am not one of those outside of modutils that intends to use the modutils syscalls from either a C or C++ program. The information in the flawed man pages appeared inconsistent with the assertion that code in asm/atomic.h is always off-limits to applications. This prompted my questions which are now answered.

David/Ulrich/Keith, Thanks for the very informative discussion.

Gary