windows.h会检测是否包含了winsock类头文件，如果没有包含的话会自动包含进winsock.h头文件，如果一个c文件同时包含了windows.h和winsock2.h，此时有可能会出现网络相关函数重复定义的错误。这主要是由于windows.h在前的关系，windows.h先自动包含了winsock.h头文件，然后include的时候又重复包含了一次。这时文件中实际上同时存在winsock.h和winsock2.h两个同类的头文件，这两个文件对一些函数产生了重复定义导致错误。

解决方法就是记住同时包含着两个头文件的时候一定要保证
#include winsock2.h
#include windows.h
这样的顺序，就不会导致重复定义的问题了。

"GRL0000: Assertion 't3rt_bstring_iter_remaining_room(iter, context) >= n_bits' failed at Src/t3rts_binarystrings.c:691"W

前两天改了tri里面的send和recv函数，本来可以成功交互的的两个testcase突然老是出现上面的那个错误。害得我一直以为是编解码哪里又出了问题呢，但是一直也挺纳闷，为什么以前可以，现在没有改编解码却出问题了呢？

为这个还郁闷了好几天，今天终于找到原因了，出现这个错误的原因在于：在所使用的alt循环里面没有相应的解码语句。因为以前使用的是tcp连接，应该是延时比较有保证，所以各个端口里面没有堆积太多的缓存下来的数据帧；但是改成ethernet封装以后，每个端口堆积了没有来得及处理的延时帧，这样导致了alt进行解码的时候实际上解的数据帧是上一个状态或者上上一个状态里可能出现的数据帧，而此时该alt中没有对应上面类型的解码处理语句，这样就导致了解码错误，即上面的那个错误。（因为读取数据的过程实际上是从队列中顺序读取的过程）

结论就是，用ttcn-3编写信令交互流程时要注意考虑到时延导致的信令帧随机到达、缓存队列大小等情况。

在标准C语言中，下面的语句是合法的 struct test{ int a:3; }; 这样定义的a在赋值后只取最后的3bit，即转换为-4到3 之间的数值。比如： 赋值 -5 -4 -3 -2 2 3 4 5 实际值 3 -4 -3 -2 2 3 -4 -3 如果 a 为无符号型，则会转换为 0 到 7 之间。且同样适用于非 i

【static全局变量】只能在该文件中使用,就算其它文件用extern来声明也不能用,
而【非static全局变量】在外部文件中可以通过extern来声明引用它。

这两天在学习获取本地mac地址的时候发现需要这个头文件和库，结果上网搜了下，发现可以下的地方不多。csdn上的可以用，我的就是这里下的，但是的注册，还要下载分。最关键的是校园网有时候很难打开，我把自己下下来的上传到这里，方便一下大家。
ps：解压后有不止一个头文件，它们是需要被Iphlpapi.h调用的，使用的时候最好一起考过去。