在debian4.3.5上 测试结果: u_int64_t:头文件 stdlib.h uint64_t:头文件 stdint.h --------------------------------------------------我是分割线------------------------------------ 一、数据类型特别是int相关的类型在不同位数机器的平台下长度不同。C99标准并不规定具体数据类型的长度大小,只规定级别。作下比较:
16位平台
char
short int long 指针 32位平台 char short int long long long 8个字节 指针 64位平台 char short int long long long 8个字节 指针 二、编程注意事项 为了保证平台的通用性,程序中尽量不要使用long数据库型。可以使用固定大小的数据类型宏定义: typedef signed char typedef short int typedef int # if __WORDSIZE == 64 typedef long int # else __extension__ typedef long long int #endif 三、使用int时也可以使用intptr_t来保证平台的通用性,它在不同的平台上编译时长度不同,但都是标准的平台长度,比如64位机器它的长度就是8字节,32位机器它的长度是4字节,定义如下: #if __WORDSIZE == 64 typedef long int #else typedef int #endif 编程中要尽量使用sizeof来计算数据类型的大小 以上类型定义都有相应的无符号类型。 另外还有ssize_t和size_t分别是sign size_t和unsigned signed size of computerwordsize。它们也是表示计算机的字长,在32位机器上是int型,在64位机器上long型,从某种意义上来说它们等同于intptr_t和uintptr_t。它们在stddef.h里面定义。需要注意的是socket的accept函数在有些操作系统上使用size_t是不正确的,因为accept接收的int*类型,而size_t可能是long int 类型。后来BSD使用sock_t来替代它。 |
一般来说,一个C的工程中一定要做一些这方面的工作,因为你会涉及到跨平台,不同的平台会有不同的字长,所以利用预编译和typedef可以让你最有效的维护你的代码。为了用户的方便,C99标准的C语言硬件为我们定义了这些类型,我们放心使用就可以了。
按照posix标准,一般整形对应的*_t类型为: 1字节 uint8_t 2字节 uint16_t 4字节 uint32_t 8字节 uint64_t
Specifier | Common Equivalent | Signing | Bits | Bytes | Minimum Value | Maximum Value |
---|---|---|---|---|---|---|
int8_t | signed
char | Signed | 8 | 1 | −128 | 127 |
uint8_t | unsigned
char | Unsigned | 8 | 1 | 0 | 255 |
int16_t | short | Signed | 16 | 2 | −32,768 | 32,767 |
uint16_t | unsigned
short | Unsigned | 16 | 2 | 0 | 65,535 |
int32_t | int | Signed | 32 | 4 | −2,147,483,648 | 2,147,483,647 |
uint32_t | unsigned
int | Unsigned | 32 | 4 | 0 | 4,294,967,295 |
int64_t | long
long | Signed | 64 | 8 | −9,223,372,036,854,775,808 | 9,223,372,036,854,775,807 |
uint64_t | unsigned
long long | Unsigned | 64 | 8 | 0 | 18,446,744,073,709,551,615 |
上面是一些与平台无关的数据类型,由于在32位机器和64位机器中,long占据不同的字节数,所以推荐使用上面的类型。。上面的类型的头文件是stdint.h
当Linux内核在体系结构差异较大的平台之间移植时,会产生与数据类型相关的问题。在编译内核时使用 -Wall -Wstrict-prototypes选项,可以避免很多错误的发生。
内核使用的基本数据类型主要有:
ØØ int 标准C语言整数类型;
ØØ u32 32位整数类型;
ØØ pid_t 特定内核对象pid的类型。
在不同的CPU体系结构上,C语言的数据类型所占空间不一样。下面是在x86下数据类型所占的字节数:
arch | char | short | int | long | ptr | long-long | u8 | u16 | u32 | u64 |
i686 | 1 | 2 | 4 | 4 | 4 | 8 | 1 | 2 | 4 | 8 |
下面是在其他平台上的数据类型所占的字节数:
arch | char | short | int | long | ptr | long-long | u8 | u16 | u32 | u64 |
i386 | 1 | 2 | 4 | 4 | 4 | 8 | 1 | 2 | 4 | 8 |
alpha | 1 | 2 | 4 | 8 | 8 | 8 | 1 | 2 | 4 | 8 |
armv4l | 1 | 2 | 4 | 4 | 4 | 8 | 1 | 2 | 4 | 8 |
ia64 | 1 | 2 | 4 | 8 | 8 | 8 | 1 | 2 | 4 | 8 |
m68k | 1 | 2 | 4 | 4 | 4 | 8 | 1 | 2 | 4 | 8 |
mips | 1 | 2 | 4 | 4 | 4 | 8 | 1 | 2 | 4 | 8 |
ppc | 1 | 2 | 4 | 4 | 4 | 8 | 1 | 2 | 4 | 8 |
sparc | 1 | 2 | 4 | 4 | 4 | 8 | 1 | 2 | 4 | 8 |
sparc64 | 1 | 2 | 4 | 4 | 4 | 8 | 1 | 2 | 4 | 8 |
其中基于sparc64平台的Linux用户空间可以运行32位代码,用户空间指针是32位宽的,但内核空间是64位的。
内核中的地址是unsigned long类型,指针大小和long类型相同。
内核提供下列数据类型。所有类型在头文件<include/asm/types.h>中声明,这个文件又被头文件<Linux/types.h>所包含。下面是include/asm/types.h文件。这是对ARM体系结构中 /asm/types.h文件中的一些定义: 因为我是对arm体系结构进行了配置
|
使用有前缀的类型用于将变量显露给用户空间,如_ _u8类型。例如:一个驱动程序通过ioctl函数与运行在用户空间的程序交换数据,应该用_ _u32来声明32位的数据类型。
有时内核使用C语言的类型,如unsigned int,这通常用于大小独立于体系结构的数据项。 内核中许多数据类型由typedef声明,这样方便移植。如使用pid_t类型作为进程标志符(pid)的类型,而不是int类型,pid_t屏蔽了在不同平台上的实际数据类型的差异。
如果不容易选择合适的类型,就将其强制转换成最可能的类型(long或unsigned long)。
如上面所说,在<include/linux/types.h>中又把你所配置的体系结构中定义的类型的类型定义
<include/asm/types.h>包含进去了:下面把<include/linux/types.h>这个文件贴出来,我的内核版本是2.6.16.28。
|
这里面我以可以看到一些自定义类型,如loff_t,size_t等。
typedef __kernel_uid_t uid_t; typedef __kernel_gid_t gid_t;
typedef __kernel_loff_t loff_t;
这样就将loff_t类型定义为__kernel_loff_t这个类型了,uid_t类型定义了__kernel_uid_t类型了,但是现在__kernel_loff_t __kernel_uid_t这种类型是很明显地与体系结构是相关的,对于arm的体系结构,则定义在<include/asm-arm/posix_types.h>,代码如下:
/*
* linux/include/asm-arm/posix_types.h
*
* Copyright (C) 1996-1998 Russell King.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
* Changelog:
* 27-06-1996 RMK Created
*/
#ifndef __ARCH_ARM_POSIX_TYPES_H
#define __ARCH_ARM_POSIX_TYPES_H
/*
* This file is generally used by user-level software, so you need to
* be a little careful about namespace pollution etc. Also, we cannot
* assume GCC is being used.
*/
typedef unsigned long __kernel_ino_t;
typedef unsigned short __kernel_mode_t;
typedef unsigned short __kernel_nlink_t;
typedef long __kernel_off_t;
typedef int __kernel_pid_t;
typedef unsigned short __kernel_ipc_pid_t;
typedef unsigned short __kernel_uid_t;
typedef unsigned short __kernel_gid_t;
typedef unsigned int __kernel_size_t;
typedef int __kernel_ssize_t;
typedef int __kernel_ptrdiff_t;
typedef long __kernel_time_t;
typedef long __kernel_suseconds_t;
typedef long __kernel_clock_t;
typedef int __kernel_timer_t;
typedef int __kernel_clockid_t;
typedef int __kernel_daddr_t;
typedef char * __kernel_caddr_t;
typedef unsigned short __kernel_uid16_t;
typedef unsigned short __kernel_gid16_t;
typedef unsigned int __kernel_uid32_t;
typedef unsigned int __kernel_gid32_t;
typedef unsigned short __kernel_old_uid_t;
typedef unsigned short __kernel_old_gid_t;
typedef unsigned short __kernel_old_dev_t;
#ifdef __GNUC__
typedef long long __kernel_loff_t;
#endif
typedef struct {
#if defined(__KERNEL__) || defined(__USE_ALL)
int val[2];
#else /* !defined(__KERNEL__) && !defined(__USE_ALL) */
int __val[2];
#endif /* !defined(__KERNEL__) && !defined(__USE_ALL) */
} __kernel_fsid_t;
#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)
#undef __FD_SET
#define __FD_SET(fd, fdsetp) /
(((fd_set *)(fdsetp))->fds_bits[(fd) >> 5] |= (1<<((fd) & 31)))
#undef __FD_CLR
#define __FD_CLR(fd, fdsetp) /
(((fd_set *)(fdsetp))->fds_bits[(fd) >> 5] &= ~(1<<((fd) & 31)))
#undef __FD_ISSET
#define __FD_ISSET(fd, fdsetp) /
((((fd_set *)(fdsetp))->fds_bits[(fd) >> 5] & (1<<((fd) & 31))) != 0)
#undef __FD_ZERO
#define __FD_ZERO(fdsetp) /
(memset (fdsetp, 0, sizeof (*(fd_set *)(fdsetp))))
#endif
#endif