是否有众所周知的“个人资料”？ C标准的？

Question

我编写的 C 代码对实现做出了某些假设，例如：

• char 是 8 位。
• 有符号整数类型是二进制补码。
• >> 对有符号整数进行符号扩展。
• 整数除法将负商舍入为零。
• double 是 IEEE-754 双精度数，可以在 uint64_t 之间进行类型双关，并获得预期的结果。
• 涉及 NaN 的比较始终评估为 false。
• 空指针的位全部为零。
• 所有数据指针都具有相同的表示形式，并且可以转换为 size_t 并再次转换回来，而不会丢失信息。
• char* 上的指针算术与 size_t 上的普通算术相同。
• 函数指针可以转换为 void* 并再次转换回来，而不会丢失信息。

现在，所有这些都是 C 标准无法保证的，所以严格来说我的代码是不可移植的。然而，它们恰好适用于我当前目标的架构和 ABI，经过仔细考虑，我决定它们无法保留我未来需要目标的某些架构的风险是可以接受的低与我现在做出假设所带来的实际好处相比。

问题是：我如何最好地记录这个决定？我的许多假设几乎是每个人都做出的（非八位字节char？或符号数值整数？关于未来商业上成功的架构？）。其他的则更有争议——最危险的可能是关于函数指针的。但是，如果我只是列出我认为超出标准的所有内容，读者的眼睛就会变得呆滞，他可能不会注意到真正重要的内容。

那么，是否存在一些关于成为“有点正统”架构的众所周知的假设，我可以通过引用将其纳入其中，然后仅明确记录我超出的范围？ （实际上，这样的“概要文件”将定义一种新语言，它是 C 的超集，但它可能不会用这么多字来承认这一点 - 并且它可能也不是一种实用的思考方式）。

澄清：我正在寻找一种记录我的选择的简便方法，而不是自动测试给定编译器是否符合我的期望的方法。后者显然也很有用，但并不能解决所有问题。例如，如果业务合作伙伴联系我们说：“我们正在制造一款基于 Google 新 G2015 芯片的设备；你们的软件可以在上面运行吗？” ——那么如果能够回答“我们还没有使用过那个架构，但如果它有一个满足此类要求的 C 编译器，那应该不是问题”。

进一步澄清，因为有人投票结束为“没有建设性”：我不是在这里寻求讨论，只是为了指向实际的、现有的、正式的文档，这些文档可以通过合并来简化我的文档参考。

Answer 1

我将引入一个 STATIC_ASSERT 宏并将所有假设放入此类断言中。

Answer 2

不幸的是，不仅缺乏结合了 20 世纪 90 年代事实上的标准的扩展的 C 方言标准（补码、通用排名指针等），而且编译器的趋势正朝着相反的方向发展。方向。给定函数的以下要求：

* Accept int parameters x,y,z:
* Return 0 if x-y is computable as "int" and is less than Z
* Return 1 if x-y is computable as "int" and is not less than Z
* Return 0 or 1 if x-y is not computable */

20 世纪 90 年代的绝大多数编译器都允许：

int diffCompare(int x, int y, int z)
{ return (x-y) >= z; }

在某些平台上，如果 xy 之间的差异无法计算为 int，则计算速度会更快xy 的“包装”二进制补码值并进行比较，而在其他情况下，使用大于 int 的类型执行计算并进行比较会更快。然而，到 20 世纪 90 年代末，几乎每个 C 编译器都会实现上述代码，以使用其中一种在其硬件平台上更高效的方法。

然而，自 2010 年以来，编译器编写者似乎采取了这样的态度：如果计算溢出，编译器不应该以其平台正常的任何方式执行计算并让发生的事情发生，也不应该进行可识别的陷阱（这会破坏一些代码） ，但可以防止某些类型的错误程序行为），但相反，它们应该以溢出为借口来否定时间和因果律。因此，即使程序员对 20 世纪 90 年代的编译器产生的任何行为都非常满意，程序员也必须用以下内容替换代码：

{ return ((long)x-y) >= z; }

这会大大降低许多平台上的效率，或者

{ return x+(INT_MAX+1U)-y >= z+(INT_MAX+1U); }

需要程序员指定一堆计算实际上并不希望优化器会忽略它们（使用有符号比较来使它们变得不必要），并且会降低许多平台（尤其是 DSP）的效率，其中使用 (long) 会更有效率。

如果有标准的配置文件可以让程序员避免使用 INT_MAX+1U 来避免像上面那样令人讨厌的可怕的组装，那将会很有帮助，但如果趋势继续下去，它们将变得越来越必要。

Answer 3

大多数编译器文档都包含一个描述依赖于实现的功能的特定行为的部分。您能指出 gcc 或 msvc 文档的那一部分来描述您的假设吗？

Answer 4

您可以编写一个头文件“document.h”，在其中收集所有假设。
然后，在您知道做出非标准假设的每个文件中，您可以#include这样的文件。
也许 "document.h" 根本没有真正的句子，而只有注释文本和一些宏。

   // [T] DOCUMENT.H
   //

   #ifndef DOCUMENT_H
   #define DOCUMENT_H 
   // [S] 1. Basic assumptions.
   // 
   // If this file is included in a compilation unit it means that
   // the following assumptions are made:
   //      [1] A char has 8 bits.
   // [#]

   #define MY_CHARBITSIZE 8

   //      [2] IEEE 754 doubles are addopted for type: double.
   // ........
   // [S] 2. Detailed information
   //
   #endif

括号中的标签： [T] [S] [#] [1] [2] 代表：

* [T]: Document Title
* [S]: Section
* [#]: Print the following (non-commented) lines as a code-block.
* [1], [2]: Numbered items of a list.

现在，这里的想法是以不同的方式使用文件“document.h”：

• 解析文件，以便将“document.h”中的注释转换为某些可打印文档或一些基本 HTML。

因此，标签 [T] [S] [#] 等旨在由解析器解释，该解析器将任何注释转换为 HTML 文本行（例如），并生成

< /h1>、（或任何你想要的），当标签出现时。

如果您将解析器保留为一个简单的小程序，这可以让您快速处理此类文档。