指针赋予了C编程最大的灵活性;结构体使得C程序整齐而紧凑;联合体在某些要求注重效率的场合有精彩的表现.这三个要素是C语言的精华.
然而精华并不意味着完美。C语言在赋予程序员足够的灵活性的同时，也给了程序员许多犯错的机会。所以，有必要关注指针，结构体和联合体的实现细节，从而保障程序的安全性。
在此，第一部分介绍MISRA-C:2004中与指针相关的部分规则，第二部分讲解结构体和联合体的操作
规范。下文凡是未加特别说明的都是 强制(required)规则，个别推荐(advisory)规则则加了“推荐”的提示.
指针的安全规范
MISRA-C:2004关于指针的规范主要分为三个部分：指针的类型转换规则,指针运算的规则和指针的有效性规则。
指针的类型转换
指针类型转换是个高风险的操作，所以应该尽量避免进行这个操作。MISRA-C对其中可能造成严重错误的情况做了严格的限定，选择其中两条做简要分析。
规则11.4(推荐) 指向不同数据类型的指针之间不能相互转化。 考察下面的程序
uint8_t * p1;
uint32_t * p2;
p2 = (uint32_t *)p1;
/* 注: uint8_t 表示8位无符号整型，uint32_t 表示32位无符号整型 */
程序员希望将从p1单元开始的4个字节组成一个32位的整型来参与运算.
如果CPU允许各种数据对象存放在任意的存储单元，则以上转换没有问题。但某些CPU对某些(种)数据
类型加强了对齐限制，要求这些数据对象占用一定的地址空间，比如某些字节寻址的CPU会要求32位
（4字节)整型存放在4的整数倍地址上(也就是所谓的address alighment地址对齐).在这个前提下
,思考程序中的指针转化，假设p1一开始指向的是0x0003单元(对uint8_t型的整数没有对齐要求),则
执行最后一行强制转换后，p2到底指向哪个单元就无法预料了.
规则11.5 指针转换过程中不允许丢失指针的const volatile属性 按照如下定义指针
uint16_t x;
uint16_t * const cpi = &x; /* const 指针 */
unit16_t * const *pcpi ; /* 指向const指针的指针 */
const uint16_t * *ppci ; /* 指向const整数指针的指针 */
uint16_t * * ppi;
const uint16_t * pci; /* 指向const整型的指针 */
volatile uint16_t * pvi; /* 指向volatile整型的指针 */
unit16_t *pi;
则一下指针转换是允许的
pi = cpi;
以下指针转换是不允许的
pi = (uint16_t *) pci;
pi = (uint16_t *) pvi;
ppi = (uint16_t **)pcpi;
ppi = (uint16_t **)ppci;
以上非法指针类型转换将会丢失const 或者 volatile 类型。丢失const属性
将有可能导致在对只读内容进行写操作，编译器不会发出警告，编译器将对不具有
volatitle属性的变量做优化;丢失volatile属性,编译器的优化可能导致程序员
预先设计的硬件时序操作失效，这样的错误很难发现。关于const和volatile
关键字的详细左右，读者可参考ISO C获取更多信息.
指针的运算
ISO C标准中，对指向数组成员的指针运算（包括算术运算，比较等）作了规范定义，除此以外的
指针运算属于未定义(undifined）范围,具体实现有赖于具体编译器件，其安全性无法得到保障，
MISRA-C中对指针运算的合法范围作了如下限定.
规则17.1 只有指向数组的指针才允许进行算术运算。(注:其实此处的算术运算子仅仅有限定于指针加减某个整数，比如ppoint = point -5,
ppoint++等)
规则17.2 只有指向同一个数组的两个指针才允许相减.(两个指针 可指向 同一数组的不同成员)
规则17.3 只有指向同一个数组的两个指针才允许用>, >=, < , <=等关系运算符进行比较。为了尽可能减少直接进行指针运算带来的隐患，尤其是程序动态运行时可能发生的数组越界等问题，MISRA-C对指针运算作了更为严格的规定。
规则17.4 只允许用数组索引做指针运算。按照如下方式定义数组和指针:
uint8_t a[10];
unit8_t *p;
p = a;
则*(p+5) = 0是不允许的，而p[5] = 0 则是允许的，尽管就这段程序而言，二者等价。
以下给出一段程序，读者可参照相应程序行的注释，细细品位上述规则的含义。
void my_fun(uint * _t * p1, uint8_t p2[])
{
uint8_t index = 0;
uint8_t *p3;
uint8_t *p4;
*p1 = 0;
p1 ++; /* 不允许, p1不是指向数组的指针 */
p1 = p1 +5; /* 不允许, p1不是指向数组的指针 */
p1[5] = 0; /* 不允许, p1不是指向数组的指针 */
p3 = &p1[5];
p2[0] = 0;
index ++;
index = index + 5;
p2[index] = 0; /*允许*/
*(p2+index) = 0; /* 不允许 */
p4 = &p2[5]; /*允许*/
}
1.3 指针的有效性
下面介绍MISRA-C:2004 中关于指针有效性的规则
规则 17.6 动态分配对象的地址栏不允许在本对象消亡后传给另外一个对象 这条规则的实际意义上是 不允许将栈对象的地址 传给外部作用域的对象
请看下面这段程序:
#include "stdio.h"
char * getm(void)
{
char p[] = "hello world";
return p;
}
int main()
{
char *str = NULL;
str = getm();
printf(str);
}
程序员希望最后的输出结果是"hello world"这个字符串，然而实际运行时，却出现乱码(具体内容依赖于编译运行环境).
简单分析以下，由于char p[] = "hello,world"这条语句是在栈中分配空间存储"hello world"这个字符串，当函数getm()返回的时候，已分配的空间将会被释放（但内容并不会被销毁），而printf(str)涉及系统调用，有数据压栈，会修改从当前分配给数组p[]存储空间的内容，导致程序无法得到预期的结果.
倘若将getm()函数体中的char p[] = "hello world"程序行改成char *q = "hello world",则执行main()的时候就可以正确输出"hello world".这事因为这样的方式，q指向的是静态数据区，而非栈中的某个单元(也就是说hello world分配到bss区中了而不是栈中)
所以，数组名是指针不假，但在实现细节上还是有很大的差异，程序员在使用指针的时候必须慎之又慎
结构体 联合体的安全规范
规则 18.4 不允许使用联合体这事一个不太近情理的规定，在具体阐述为何MISRA-C:2004如此痛恨联合体之前，首先需要明确与联合体相关的细节:
1)联合体的末尾有多少个填充单元
2）联合体的各个成员如何对齐
3）多字节的数据类型高低字节如何排放顺序
4）如果包含位字段 (bit-field)，各位如何排放
针对细节3举个例子
程序段2.1
typedef union{
uint32_t word;
uint8_t bytes[4];
}word_msg_t;
uint32_t read_msg(void)
{
word_msg_t tmp;
/* tmp.byte[0] 对应于tmp.word的高8位
tmp.byte[1]对应于tmp.word的次高8位,依此类推 */
tmp.bytes[0] = read_byte();
tmp.bytes[1] = read_byte();
tmp.bytes[2] = read_byte();
tmp.bytes[3] = read_byte();
return (tmp.word);
}
以上代码在各种通信协议中使用的频率很高，接收端接收到的数据一般都以字节为单位存放，主控程序需要根据相应的协议将接受到的多个字节进行组合。为了实现相同的功能,MISRA-C:2004推荐恶劣read_msg()函数的另外一种写法.
程序段2.2
uint32_t read_msg(void)
{
uint32_t word;
word = ((uint32_t)read_byte() ) << 24;
word = word | (((uint32_t)read_byte()) << 16);
word = word | (((uint32_t)read_bytes()) << 8);
word = word | ((uint32_t)read_byte());
return (word);
}
无论从程序的可读性还是从执行效率来讲，程序段2.1都要优于程序段2.2。然而，程序段2.1在Intel 80x86/Pentium体系(little-endian,存储多字节整数的时候低位字节存放在低地址)CPU和在Motorola 68K体系(big-endian)中的执行结果完全不一样。假设read_byte()函数返回的数据依次是0x01,0x02,0x03,0x04,则在Intel体系中，程序段2.1 read_msg返回的值是0x4321,在Motorola体系中，返回的则是0x1234. 无论在Intel体系还是在Motorola体系中,程序段 2.2 中read_msg的返回值都是0x1234
以上是联合体中多字节整型字节排放顺序不定导致漏洞的一个例子。倘若不明确联合体末尾填充的细节，或者不清楚联合体成员的对齐方式，或者不注意联合体中位字段成员的位排列次序，都有可能导致错误。作为将安全性放在第一位的C标准，MISRA_C禁止使用联合体并非不可理喻
然而，联合体毕竟是C语言的一个重要元素，所以MISRA_C主张禁止使用联合体的同时，也为效率和资源要求比较苛刻的情况开了一扇们，程序员在明确联合体各个实现细节的前提下，在万不得已的时候，仍可以谨慎使用联合体，在不同体系的CPU间移植程序时也要注意做相应的修改.此外，MISRA-C:2004中也对结构体和联合体的编程风格作了限定
规则18.1所有结构体和联合体的定义必须保证完整性 由于涉及ISO C中类型定义完整性等概念，碍于篇幅的原因，此处不再赘述，读者可以参阅MISRA-C:2004一书，和ISO C标准以了解更多信息，完善自己的编程风格
小结
总而言之，对于C程序总最灵活的指针，结构体和联合体，程序员不仅仅要关注其定义和操作的一般方法,更要注意实现细节。由于指针 联合体的功能性错误一般都可以逃过编译器的检查，所以稍有疏忽，就可能导致程序在运行的时候出现严重错误，程序员必须以严禁甚至苛刻的态度对待指针，结构体和联合体
