在64位内核上是否有任何替代非ISO gcc特定扩展 __attribute__ ？
__attribute__
我注意到的三种类型是：函数属性，类型属性和变量属性 .
例如 . 我想避免对通过网络传递的结构使用 __attribute__((__packed__)) ，即使一些基于gcc的代码确实使用它 .
__attribute__((__packed__))
有关如何在C系统/内核代码中使用 entirely avoid __attribute__ 的任何建议或指示？
谢谢赛菲 .
有关如何完全避免C系统/内核代码中的属性使用的任何建议或指示？
您可以逐个构建网络数据包，将每个数据元素复制到 char* 缓冲区中的正确位置 .
char*
优点：你通常是便携式的，特别是如果你使用 <stdint.h> 中的精确宽度整数类型
<stdint.h>
缺点：这很乏味且可能容易出错
我假设根据你的意见，你想要改变你的代码，而不是整个Linux内核（等） .
不确定函数属性等，但特别是对于属性打包，到目前为止我没有遇到任何问题 .
基本上不依赖于编译器打包，您可以使用手动填充字段和编译时断言 .
struct foo { u32 field1; u16 field2; u16 pad; // manual padding // continue for other fields that the compiler would automatically pad for you with attribute packed u32 field3; };
要检查结构，可以使用编译时断言，如下所示：
#define CASSERT(cond, name) typedef cassert__##name[cond ? 1 : -1] CASSERT(offsetof(foo, field1) == 0, field1_wrong); CASSERT(offsetof(foo, field2) == 4, field2_wrong);
当您的断言错误时，构建将失败并显示有用的错误和行号
2 回答
您可以逐个构建网络数据包，将每个数据元素复制到
char*缓冲区中的正确位置 .优点：你通常是便携式的，特别是如果你使用
<stdint.h>中的精确宽度整数类型缺点：这很乏味且可能容易出错
我假设根据你的意见，你想要改变你的代码，而不是整个Linux内核（等） .
不确定函数属性等，但特别是对于属性打包，到目前为止我没有遇到任何问题 .
基本上不依赖于编译器打包，您可以使用手动填充字段和编译时断言 .
要检查结构，可以使用编译时断言，如下所示：
当您的断言错误时，构建将失败并显示有用的错误和行号