根据7.5章节的要求，[errno]是一个int类型的可修改的lvalue（可以通过多个库函数设置为正数错误码），其值由宏或具有外部链接的标识符定义。如果禁止宏定义以访问实际对象，或程序定义了名为errno的标识符，则行为未定义。
注175：宏errno不一定是对象的标识符。它可能扩展为可修改的lvalue，这来自于函数调用的结果（例如， *errno（））。
不清楚是否有足够的理由要求&errno不违反约束条件。C语言有lvalue（例如寄存器存储类变量；但这些只能是自动的，因此不能将errno定义为此类变量），对于其中的&运算符是约束条件的违规。
如果&errno是合法的C语言，是否需要是常量？
所以§6.5.3.2p1指定：
一元&运算符的操作数必须是函数设计器、[]或一元*运算符的结果，或者指定一个不是位域并且没有使用寄存器存储类说明符声明的对象的左值。
我认为可以理解为&lvalue适用于那两个类别之外的任何左值。正如您所提到的，errno不能使用寄存器存储类说明符声明，并且我认为（尽管现在不会追查参考文献），您不能拥有具有纯整型类型的位域。
因此，我认为规范要求&(errno)是合法的 C。
如果&errno是合法的C，它是否需要是常量？
据我所知，允许errno成为宏（以及其在例如glibc中的原因）的部分原因是允许它成为对线程本地存储的引用，在这种情况下，它肯定不会跨线程保持不变。 我没有看到任何理由要求它必须是常量。只要errno的值保留指定的语义，我认为一个歪曲的C库可以更改&errno以在程序的执行过程中引用不同的内存地址 - 例如，每次设置errno时释放并重新分配后备存储。
您可以想象维护由库设置的最后N个errno值的环形缓冲区，并且使&errno始终指向最新的值。我认为它不会特别有用，但是我看不到它违反规范的任何方法。
errno。例如，如果您有一个函数void print_int_at(int *p);，那么调用print_int_at(&errno)来打印errno的值是否有效，或者在函数读取它之前errno是否会移动到另一个地址（在这种情况下，您需要将其存储在临时变量中，或者执行类似于print_int_at((int[]){errno});的操作）？ - R.. GitHub STOP HELPING ICEint 类型；只是语言没有定义它是有符号还是无符号类型（当应用于位域时）。因此，给定 struct b { int b0 : 1; }，不清楚该位域的可接受值是什么。 - Jonathan Leffler我很惊讶没有人引用C11规范。抱歉引用了这么长的内容，但我认为它是相关的。
7.5 错误
头文件<errno.h>定义了几个宏...
...以及errno
errno扩展为一个可修改的lvalue(201)，其类型为int并具有线程本地存储期，多个库函数会将其值设置为正错误号码。如果压制宏定义以访问实际对象，或者程序定义了名称为errno的标识符，则行为是未定义的。
在程序启动时，初始线程中errno的值为零（其他线程中errno的初始值为不确定值），但是任何库函数都不会将其设置为零。(202)即使没有错误，库函数调用也可能将errno的值设置为非零值，前提是该函数的描述中未记录使用errno。
(201) 宏errno不必是对象的标识符。它可以扩展为从函数调用中得到的可修改的lvalue（例如*errno()）。
(202) 因此，对于使用errno进行错误检查的程序，应在调用库函数之前将其设置为零，然后在随后的库函数调用之前检查它。当然，库函数可以在进入时保存errno的值，然后将其设置为零，只要在返回之前如果errno的值仍然为零，则恢复原始值即可。
register 不再使用。 类型 int 意味着位域不再使用（依我看）。 因此，&errno 在我看来是合法的。&errno 是非常数的。 我想人们可以想象一种实现，在特定线程内 &errno 不是常量，但为了按照脚注所说的方式使用它（设置为零，然后在调用库函数后检查），必须是有意对抗的，并且可能需要专门的编译器支持才能对抗。&errno，我认为这不是故意的。register int errno asm ("r37"); // line R
errno为一个在寄存器r37中保持的全局值。显然，它将是一个可修改的线程本地lvalue。那么，符合C实现能像这样声明errno吗？long long long __Foo_e!r!r!n!o()blurfl??/**
register已经被淘汰了，因为它只能用于自动存储期。但是GCC作为扩展有全局register，并且它们始终是（固有的）线程本地的。这样实现errno是否合法？ - R.. GitHub STOP HELPING ICEerrno本身必须在标准描述的语言中实现。另一方面，取地址操作中的register例外应该是针对规范的程序而言的……难道不是吗？整个问题都非常棒。 - Nemoerrno并没有被声明。规范实现中，该宏展开为一个表达式，通过使用*运算符在函数返回的地址上进行求值，从而得到一个lvalue。因此，我不知道声明如何涉及其中。 - R.. GitHub STOP HELPING ICEerrno的声明，而是这里相关的errno 对象 的声明。）“已声明”一词意味着“声明”。我将重新表述我的更新以明确这一点。 - Nemoerrno的最初实现是作为全局int变量，各种标准C库组件用它来指示错误值，如果它们遇到错误。然而，即使在那些日子里，人们也必须小心可重入代码或使用库函数调用时可能将errno设置为不同的值，因为您正在处理一个错误。通常，如果需要长时间使用错误代码，则会将该值保存在临时变量中，因为某些其他函数或代码片段可能会将errno的值显式地或通过库函数调用进行设置。#define errno (*myErrno())
typedef struct {
// various memory areas for thread local stuff
int myErrNo;
// more memory areas for thread local stuff
} ThreadLocalData;
ThreadLocalData *getMyThreadData () {
ThreadLocalData *pThreadData = 0; // placeholder for the real thing
// locate the thread local data for the current thread through some means
// then return a pointer to this thread's local data for the C run time
return pThreadData;
}
int *myErrno () {
return &(getMyThreadData()->myErrNo);
}
errno的地址，以减少每次调用库函数时进行某种线程本地查找的开销。errno的地址作为常量也提供了与旧版源代码的向后兼容性，这些代码使用了errno.h包含文件（请参见此linux上关于errno的man页面，其中明确警告不要像旧时代那样使用extern int errno;）。extern int errno;当使用errno时，并允许旧的用法，以便为不支持多线程的嵌入式设备的某种交叉编译器提供支持。然而，由于使用了宏定义，因此语法可能类似，因此不应使用旧式快捷方式声明，因为该声明不是实际errno的真实情况。int，所以errno可以是位域。在这种情况下，&errno将无效。标准的行为在于不明确地说明您可以编写&errno，因此未定义行为的定义适用于此处。
C11(n1570), § 4.一致性
在本国际标准中，通过‘‘undefined behavior’’一词或省略任何明确的行为定义来表明未定义行为。
int 还是 "int 位域，宽度为 n"? - R.. GitHub STOP HELPING ICE这似乎是一个有效的实现，其中&errno将是一个约束违规：
struct __errno_struct {
signed int __val:12;
} *__errno_location(void);
#define errno (__errno_location()->__val)
所以我认为答案很可能是否定的...
int类型，但当然这似乎不太合理。这就是问题的关键所在。 - R.. GitHub STOP HELPING ICE
(union {signed int x:32;}){0}.x的类型是什么？（假设32是int的宽度；根据需要进行替换）。 - R.. GitHub STOP HELPING ICEregister存储类别获取变量的地址，但它们仍然可以用作lvalue。 - Kerrek SB