Bug#301631: linux-kernel-headers: type of __s64 and __u64 (from asm/types.h) on AMD64 should be long
On Tuesday 29 March 2005 17:01, Daniel Jacobowitz wrote: Can you explain why you want to make this change? Long long is still correct for these types, and consistent within the kernel. The kernel types don't need to match stdint.h. I got an error from #ifdef OS_Linux #include linux/version.h #include sys/types.h #ifndef __u64 #if LINUX_VERSION_CODE = KERNEL_VERSION(2,5,70) #include bits/wordsize.h #if __WORDSIZE == 64 typedef unsigned long __u64; #else typedef unsigned long long __u64; #endif #endif #endif #endif somewhere below asm/types.h is included which results in a type mismatch. I don't know why asm/types.h isn't included from sys/types.h but after I investigated some headers I found it confusing that c++ and c use just long (size_t and int64_t) and the kernel uses long long. Both represent 64 bit data but seems to be different types Cheers, André
Bug#301631: linux-kernel-headers: type of __s64 and __u64 (from asm/types.h) on AMD64 should be long
On Sun, Mar 27, 2005 at 12:17:08PM +0200, Andre Woebbeking wrote: Package: linux-kernel-headers Version: 2.5.999-test7-bk-17 Severity: normal Hi, on AMD64 sizeof(long) is already 8 bytes, there is no need for long long. Also int64_t from stdint.h (libc6-dev) is only long and IMHO both should match. The same applies to some other 64 bit types defined as long long. Can you explain why you want to make this change? Long long is still correct for these types, and consistent within the kernel. The kernel types don't need to match stdint.h. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301631: linux-kernel-headers: type of __s64 and __u64 (from asm/types.h) on AMD64 should be long
On Tue, Mar 29, 2005 at 05:30:00PM +0200, André Wöbbeking wrote: On Tuesday 29 March 2005 17:01, Daniel Jacobowitz wrote: Can you explain why you want to make this change? Long long is still correct for these types, and consistent within the kernel. The kernel types don't need to match stdint.h. I got an error from #ifdef OS_Linux #include linux/version.h #include sys/types.h #ifndef __u64 #if LINUX_VERSION_CODE = KERNEL_VERSION(2,5,70) #include bits/wordsize.h #if __WORDSIZE == 64 typedef unsigned long __u64; #else typedef unsigned long long __u64; #endif #endif #endif #endif somewhere below asm/types.h is included which results in a type mismatch. That's your bug. Don't do that. Don't mix glibc and kernel headers. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301631: linux-kernel-headers: type of __s64 and __u64 (from asm/types.h) on AMD64 should be long
On Tuesday 29 March 2005 17:37, Daniel Jacobowitz wrote: That's your bug. No not mine, it's KDE's one ;-) Don't do that. Don't mix glibc and kernel headers. Nevertheless IMHO it's at least strange if not even wrong to use different types for 64 bit data. But as this will probably not be fixed I'll try to fix it in KDE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301631: linux-kernel-headers: type of __s64 and __u64 (from asm/types.h) on AMD64 should be long
At Tue, 29 Mar 2005 23:39:13 +0200, Andr Wbbeking wrote: I'll try to fix it in KDE. Could you reassign this problem to the appropriate KDE package? Regards, -- gotom
Bug#301631: linux-kernel-headers: type of __s64 and __u64 (from asm/types.h) on AMD64 should be long
Package: linux-kernel-headers Version: 2.5.999-test7-bk-17 Severity: normal Hi, on AMD64 sizeof(long) is already 8 bytes, there is no need for long long. Also int64_t from stdint.h (libc6-dev) is only long and IMHO both should match. The same applies to some other 64 bit types defined as long long. Cheers, André -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.10-9-amd64-k8 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
