在查看Ｃ/Ｃ++源代码时，经常遇到这样的情况：使用了某个struct，确不知道它的确切定义，查起来又不好查。下面就提供2种查找定义的方法：

最近在想如果Ｃ/Ｃ++能实现python中的yield就好了，因为写包分析的代码十分需要这个。于是在coolshell查到了。另外还有这篇C++中的yield和fork也不错可以参考，深深感觉到了神牛的牛掰之处。“其实说白了 C 语言就是脱胎于汇编语言的，switch-case 跟 if-else 一样，无非就是汇编的条件跳转指令的另类实现而已”语出惊人令人叹服。废话不多说，下面上博文。容我再跪一会儿。

当程序运行的过程中异常终止或崩溃，操作系统会将程序当时的内存状态记录下来，保存在一个文件中，这种行为就叫做Core Dump（中文有的翻译成“核心转储”)。我们可以认为 core dump 是“内存快照”，但实际上，除了内存信息之外，还有些关键的程序运行状态也会同时 dump 下来，例如寄存器信息（包括程序指针、栈指针等）、内存管理信息、其他处理器和操作系统状态和信息。core dump 对于编程人员诊断和调试程序是非常有帮助的，因为对于有些程序错误是很难重现的，例如指针异常，而 core dump 文件可以再现程序出错时的情景。

一、字节对齐基本概念

    现代计算机中内存空间都是按照byte划分的，从理论上讲似乎对任何类型的变量的访问可以从任何地址开始，但实际情况是在访问特定类型变量的时候经常在特 定的内存地址访问，这就需要各种类型数据按照一定的规则在空间上排列，而不是顺序的一个接一个的排放，这就是对齐。 对齐的作用和原因：各个硬件平台对存 储空间的处理上有很大的不同。一些平台对某些特定类型的数据只能从某些特定地址开始存取。比如有些架构的CPU在访问一个没有进行对齐的变量的时候会发生 错误,那么在这种架构下编程必须保证字节对齐.其他平台可能没有这种情况，但是最常见的是如果不按照适合其平台要求对数据存放进行对齐，会在存取效率上带 来损失。比如有些平台每次读都是从偶地址开始，如果一个int型（假设为32位系统）如果存放在偶地址开始的地方，那 么一个读周期就可以读出这32bit，而如果存放在奇地址开始的地方，就需要2个读周期，并对两次读出的结果的高低字节进行拼凑才能得到该32bit数 据。显然在读取效率上下降很多。

昨天做了华为的一个OJ练习题，题目本身没什么难度，但是自己仍然执着地犯了典型的错误（-.- 又放水了哎）。错误的大概内容在指针的加减运算这一块。

昨天写了个简单的C程序parse收到的pcap文件，因为是csi tool injection的包，所以找现有的库去拆包分析可能比较麻烦（资源似乎比较少），想着自己parse一下也不是多麻烦的事（后来花了一上午时间找问题，=。= 我太水了哎）。

动手后发现memcpy(rtap_header,pkt_data,sizeof(rtap_header));后，rtap_header里的data rate打印出来总是不对，(GDB)x/14xb rtap_header看了一下结构体的前14个字节也完全符合wireshark上打印的数据，可是(GDB)p/x rtap_header->data_rate看到的却完全不对。短暂的懵逼后(￣(●●)￣) ，想到了是不是自己印象中struct的存储方式不对，然后果了个然。

===============华丽的分割线===============

转自：http://c.biancheng.net/cpp/html/469.html

转自:http://www.turbolinux.com.cn/turbo/wiki/doku.php?id=libpcap%E5%87%BD%E6%95%B0%E5%BA%93