Re：programi解析问题 [英] Re: programi parsing question
问题描述
Scott Lurndal写道：
Scott Lurndal wrote:
> if（（fd = open（_PATH_UTMP，O_RDONLY））< 0）
>if((fd = open(_PATH_UTMP, O_RDONLY)) < 0)
开放系统调用被定义为在失败时返回'-1'，而不是任何
负数。所以上面的检查是不正确的。这可能会导致mmap，lseek和其他系统调用出现问题，如果声明或转换为签名，则返回
值，而合法的则是负数。
mmap（）应始终针对MAP_FAILED进行检查，并且lseek返回
应始终与期望值（即SEEK_SET的偏差
arg）进行比较，以及其他SEEK_ *变体的预期偏移量）。
The open system call is defined to return ''-1'' on failure, not any
negative number. So the above check is incorrect. This can
cause problems with mmap, lseek and other system calls whose return
values, if declared or cast as signed, while legal are negative.
mmap() should always be checked against MAP_FAILED, and lseek return
should always be compared with the expected value (i.e. the offset
arg for SEEK_SET, and the expected offset for the other SEEK_* variants).
如果您的文件描述符围绕喇叭，并且
超出某些特定于平台的限制，它是否也会导致问题，比如0x80000000？他们会去b
当表示为有符号整数时......
Would it also cause a problem if your file descriptors go "around the horn", and
exceed some platform-specific limit, such as 0x80000000? They would "go
negative" when expressed as signed integers...
总是测试定义的返回码是好的做法
（大多数情况下） case是-1，而不是< 0）。
It''s good practice to always test for the defined return code
(which in most cases is -1, not < 0).
一些相对标准的.h文件是否在那里定义了一个好的常量？
-
Phlip
Does some relatively standard .h file define a good constant there?
--
Phlip
推荐答案
[由于此子线程正在获取特定于Unix的特征，因此需要跟进...
8月6，晚上8:08，Phlip< phlip2 ... @ gmail.comwrote：
[Followups to c.u.p since this subthread is getting Unix-specific]
On Aug 6, 8:08 pm, Phlip <phlip2...@gmail.comwrote:
Scott Lurndal写道：
Scott Lurndal wrote:
if（（fd = open（_PATH_UTMP，O_RDONLY））< 0）
if((fd = open(_PATH_UTMP, O_RDONLY)) < 0)
开放系统调用是定义为失败时返回'-1'，而不是任何
负数。所以上面的检查是不正确的。这可能会导致mmap，lseek和其他系统调用出现问题，如果声明或转换为已签名，则返回
值，而合法为负数。
The open system call is defined to return ''-1'' on failure, not any
negative number. So the above check is incorrect. This can
cause problems with mmap, lseek and other system calls whose return
values, if declared or cast as signed, while legal are negative.
mmap（）应始终针对MAP_FAILED进行检查，并且lseek返回
应始终与预期值进行比较（即SEEK_SET的偏移量
arg，以及其他SEEK_ *变体的预期偏移量。
mmap() should always be checked against MAP_FAILED, and lseek return
should always be compared with the expected value (i.e. the offset
arg for SEEK_SET, and the expected offset for the other SEEK_* variants).
如果您的文件描述符围绕号角，并且
超出某些特定于平台的限制，它是否也会导致问题，比如0x80000000？他们会去b
表示为有符号整数时...
Would it also cause a problem if your file descriptors go "around the horn", and
exceed some platform-specific limit, such as 0x80000000? They would "go
negative" when expressed as signed integers...
保证不会发生。文件描述符始终是非整数
负整数。因此，一台32位机器不会被允许超过2 ^ 31个打开文件描述符。
所以对于''open''特别是，测试< 0与测试
为-1相同，因为它承诺永远不会返回任何其他负值。
正如Scott正确指出的那样，还有其他功能
但事实并非如此，因此可以说最好是确保bb形成检查错误的习惯。值（通常是-1，但不是
总是）。
另一方面，测试< 0是相当惯用的。并且
另一个常见的约定（虽然不适用于Unix系统调用）是一个
函数，能够在出错时返回任何几个负值，
在这种情况下你必须测试<内核通常会使用这个约定，因为它们本身就是多线程的，并且不能使用像errno那样方便地使用
。返回
值是地址的情况会使这种方法复杂化。我相信Linux
内核通过保证地址空间永远不会映射的最高页面来处理这个问题，所以值为-1到
-4096可用于错误代码而不用担心与
地址冲突。
That''s guaranteed not to happen. A file descriptor is always a non-
negative integer. So a 32-bit machine wouldn''t be allowed to have
more than 2^31 open file descriptors.
So for ''open'' in particular, testing for < 0 is the same as testing
for -1, since it promises never to return any other negative value.
As Scott correctly points out, though, there are other functions for
which this is not the case, and so it can be argued it''s better to
form the habit of checking for the "error" value (usually -1, but not
always) specifically.
On the other hand, though, testing for < 0 is rather idiomatic. And
another common convention (though not for Unix system calls) is for a
function to be able to return any of several negative values on error,
in which case you must test for < 0. It is common for kernels to use
this convention, because they are inherently multi-threaded and can''t
conveniently use something like errno. The case where the return
value is an address can complicate this approach. I believe the Linux
kernel dealt with this issue by guaranteeing that the highest page of
the address space would never be mapped, so that the values -1 through
-4096 could be used for error codes without fear of conflicting with
addresses.
总是测试定义的返回码
（在大多数情况下为-1，不是< 0）是一种好习惯。
It''s good practice to always test for the defined return code
(which in most cases is -1, not < 0).
一些相对标准的.h文件是否定义了一个好的常量？
Does some relatively standard .h file define a good constant there?
我不相信。
I don''t believe so.
Phlip写道：
Phlip wrote:
Scott Lurndal写道：
Scott Lurndal wrote:
>> if（（fd = open） （_PATH_UTMP，O_RDONLY））< 0）
>>if((fd = open(_PATH_UTMP, O_RDONLY)) < 0)
.... snip ...
.... snip ...
>
>
>总是测试定义的返回码
（大多数情况下为-1，不是< 0）是一种好习惯。 。
>It''s good practice to always test for the defined return code
(which in most cases is -1, not < 0).
一些相对标准的.h文件是否定义了一个好的常量？
Does some relatively standard .h file define a good constant there?
请不要删除报价材料的归属。
没有标准的.h文件描述''打开'' ，因为open不是
标准C定义的例程。这不适用于fopen，
打开一个文件*。
-
[mail]：Chuck F（ maineline dot net的cbfalconer）
[page]：< http://cbfalconer.home.att.net>
尝试下载部分。
Please don''t delete attributions for quoted material.
No standard .h file describes ''open'', because open is not a
standard C defined routine. This does not apply to fopen, which
opens a FILE*.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
8月7日上午7:10，CBFalconer< cbfalco ... @ yahoo.comwrote：
On Aug 7, 7:10 am, CBFalconer <cbfalco...@yahoo.comwrote:
Phlip写道：
Phlip wrote:
Scott Lurndal写道：
Scott Lurndal wrote:
> if（（fd = open（_PATH_UTMP，O_RDONLY））< 0）
>if((fd = open(_PATH_UTMP, O_RDONLY)) < 0)
... snip ...
... snip ...
总是测试定义的返回代码是好的做法
（在大多数情况下是 - 1，不是< 0）。
It''s good practice to always test for the defined return code
(which in most cases is -1, not < 0).
一些相对标准的.h文件是否定义了一个好的常量？
Does some relatively standard .h file define a good constant there?
请不要删除引用材料的归属地。<br />
没有标准的.h文件描述''打开'' ，因为open不是
标准C定义的例程。这不适用于fopen，
打开一个FILE *。
Please don''t delete attributions for quoted material.
No standard .h file describes ''open'', because open is not a
standard C defined routine. This does not apply to fopen, which
opens a FILE*.
另请注意，_PATH_UTMP是标准C中的无效标识符，因为它是为实现保留的，所以它是
。
Also note that _PATH_UTMP is an invalid identifier in standard C,
since it''s reserved for the implementation.
这篇关于Re：programi解析问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
