我编写的 C 代码对实现做出了某些假设，例如:
char是 8 位。- 有符号整数类型是二进制补码。
>>>对有符号整数进行符号扩展。- 整数除法将负商舍入为零。
double是 IEEE-754 double，可以在uint64_t之间进行类型转换，得到预期的结果。- 涉及 NaN 的比较总是计算为 false。
- 空指针是全零位。
- 所有数据指针都具有相同的表示形式，并且可以在不丢失信息的情况下转换为
size_t并再次返回。 char*上的指针运算与size_t上的普通运算相同。- 函数指针可以转换为
void*并再次转换回来而不会丢失信息。
现在，所有这些都是 C 标准不能保证的，所以严格来说我的代码是不可移植的。然而，它们恰好适用于我目前所针对的架构和 ABI，经过仔细考虑后，我决定他们无法坚持我将来需要针对的某些架构的风险是可以接受的低与我现在做出假设所获得的实际好处相比。
问题是:我如何最好地记录这个决定？我的许多假设实际上是每个人都做出的(非八位字节 chars？还是带符号的整数？ future 的商业成功架构？)。其他人更有争议——最危险的可能是关于函数指针的。但是，如果我只是列出所有我认为超出标准给我的内容，读者的眼睛就会呆滞，他可能不会注意到真正重要的内容。
那么，是否有一些关于成为“有点正统”的架构的众所周知的假设集，我可以通过引用将其合并，然后只明确记录我超越的地方？ (实际上，这样的“配置文件”将定义一种新语言，它是 C 的超集，但它可能不会在这么多词中承认这一点——而且它也可能不是一种实用的思考方式)。
澄清:我正在寻找一种速记方式来记录我的选择，而不是寻找一种自动测试给定编译器是否符合我的期望的方式。后者显然也很有用，但并不能解决所有问题。例如，如果业务合作伙伴联系我们说，“我们正在制造基于 Google 新 G2015 芯片的设备；您的软件可以在上面运行吗？” -- 那么能够回答“我们还没有使用那个架构，但如果它有一个满足这样那样的 C 编译器，那应该不是问题”。
进一步澄清，因为有人投票关闭“没有建设性”:我不是在这里寻找讨论，只是为了指向实际的、现有的、正式的文档，这些文档可以通过以下方式简化我的文档以引用方式并入。
最佳答案
我会引入一个 STATIC_ASSERT 宏并将您的所有假设放入此类断言中。
关于c - 是否有众所周知的 C 标准 "profiles"？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7176507/