2.2.18 asm-alpha/system.h has a problem

Hi, all.

I encounterd the problem that 'cdrdao' is not compilable in 2.2.18 on Alpha. And I researched a little.
So, then new code added in include/asm-alpha/system.h on 2.2.18 has a problem in C++. The 'new' may be the reserved word in C++. And I send its patch.

Regards
Daiki Matsuda

@@ -390,7 +390,7 @@
 #define __HAVE_ARCH_CMPXCHG 1
 
 extern __inline__ unsigned long
-__cmpxchg_u32(volatile int *m, int old, int new)
+__cmpxchg_u32(volatile int *m, int old_val, int new_val)
 {
 	unsigned long prev, cmp;
 

@@ -409,13 +409,13 @@
 	"3:	br 1b\n"
 	".previous"
 	: "=&r"(prev), "=&r"(cmp), "=m"(*m)
-	: "r"((long) old), "r"(new), "m"(*m) : "memory");
+	: "r"((long) old_val), "r"(new_val), "m"(*m) : "memory");
 
 	return prev;
 }
 
 extern __inline__ unsigned long
-__cmpxchg_u64(volatile long *m, unsigned long old, unsigned long new)
+__cmpxchg_u64(volatile long *m, unsigned long old_val, unsigned long new_val)
 {
 	unsigned long prev, cmp;
 

@@ -434,7 +434,7 @@
 	"3:	br 1b\n"
 	".previous"
 	: "=&r"(prev), "=&r"(cmp), "=m"(*m)
-	: "r"((long) old), "r"(new), "m"(*m) : "memory");
+	: "r"((long) old_val), "r"(new_val), "m"(*m) : "memory");
 
 	return prev;
 }

@@ -444,16 +444,16 @@
 extern void __cmpxchg_called_with_bad_pointer(void);
 
 static __inline__ unsigned long
-__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size)
+__cmpxchg(volatile void *ptr, unsigned long old_val, unsigned long new_val, int size)
 {
 	switch (size) {
 		case 4:
-			return __cmpxchg_u32(ptr, old, new);
+			return __cmpxchg_u32(ptr, old_val, new_val);
 		case 8:
-			return __cmpxchg_u64(ptr, old, new);
+			return __cmpxchg_u64(ptr, old_val, new_val);
 	}
 	__cmpxchg_called_with_bad_pointer();
-	return old;
+	return old_val;
 }
 
 #define cmpxchg(ptr,o,n)						 \

[Daiki Matsuda]

Then cdrdao has a problem. It should not be including kernel headers directly. You are changing perfectly legal C.

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

You're right that's not kernel issue and patch can be rejected, but he's not really changing anything :). If changing that helps then it's a compiler bug.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

[Peter Samuelson]

[Andrea Arcangeli]

Not a compiler bug, a source bug of assuming a C header file can be included by a C++ program. The right solution, as always, is to make a copy of the header (assuming you really do need it) and edit the copy as necessary. This is a simple variation on the #ifdef __KERNEL__ issue.

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

** Reply to message from Peter Samuelson <[email protected]> on Mon, 18 Dec 2000 09:03:00 -0600 (CST)

That just creates more maintenance problems. What if the kernel header file changes? Then he'll have to change his copy as well. He'll forever need to check changes in that kernel header file, or risk having an obscure bug that's otherwise hard to track.

Yes, it's perfectly valid C, but so what? That doesn't mean that it's a good idea. It does no harm to make a minor change to the header file to allow a C++ compiler to digest it. I consider it to be a "professional courtesy" of a C programmer for a C++ programmer. All the C programmer needs to do is acknowledge that someone might want to use a C++ compiler on the code, and just make a few minor changes that have no negative affect at all.

Timur Tabi - [email protected]
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please direct the reply to the mailing list only.  Don't send another copy to me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

All C++ folks need to do is to use

extern "C" {
#include "macrosforthestuffthecplusplusstandardspeoplegotwrong.h" #include "cheaderfile"
#include "nowmakethemacrosgoaway.h"
}

where those redefine new private etc

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

C++ obviously doesn't care about the name of parameters in a function too.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

[Andrea Arcangeli]

Sure it does when they are language keywords. In this case he is trying to change the parameter name "new".

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Ok ;)

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

In article <[email protected]>,

No, in fact that is the desired behaviour. If the kernel include files change, chances are very big that the source of the utility (or library) needs adjustments as well. In fact if you simply recompile the old source with the new header files you might get unwanted and unexpected behaviour, whereas if you recompile with the older header defs you'll simply use an advertized api that might not be the latest but works

Mike.

RAND USR 16514
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/