err = func_1(..argList_1..);if(err != 0){ perror("func(..argList..)"); return ((1u << 8) | errno);}//..//.. some more funcs//..err = func_n(..argList_n..);if(err != 0){ perror("func(..argList_n..)"); return (((unsigned)n << 8) | errno);}
这里的问题是安全的假设.
现实:errno被声明为extern int errno;在errno.h里面
假设1:errno的值始终小于255.
假设2:错误总是积极的.
根据errno.h中定义的所有错误常量(EAGAIN等),这些假设目前都是正确的.这些可以假设在未来也是如此吗?
P.S.:我不想依赖perror()来确定退出点.
解决方法 程序的退出状态限制为0..255,因此如果这些返回语句来自main()程序,则高位不相关.C标准(ISO / IEC 9899:2011§7.5错误< errno.h>)说:
errno
which expands to a modifiable lvalue201) that has type int and thread local storage
duration,the value of which is set to a positive error number by several library functions.201) The macro
errno
need not be the IDentifIEr of an object. It might expand to a modifiable lvalue
resulting from a function call (for example,*errno()
).
C标准预计错误是正面的. POSIX(IEEE Std 1003.1,2013版)声明为<errno.h>
:
The
<errno.h>
header shall define the following macros which shall expand to integer constant Expressions with typeint
,distinct positive values (except as noted below),and which shall be suitable for use in#if
preprocessing directives: …
因此,您可以合理安全地假设(系统生成的)错误编号为正,但您的代码可能设置为errno为负(或为零).目前,没有POSIX系统产生的错误数量高于200以下,所以假设它们将被限制在255,在短期内是安全的,但可能不是长期的.他们没有理由这么受限制.
您声称的“现实”仅适用于非线程程序.如果您正在编译线程支持,那么errno不会简单地声明为extern int errno;在任何情况下你都不应该为自己申报errno.声明它的唯一安全方法是通过< errno.h>头.
总结以上是内存溢出为你收集整理的c – 假设errno总是积极的是否安全?全部内容,希望文章能够帮你解决c – 假设errno总是积极的是否安全?所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)