FCLOSE（0） [英] fclose(0)

问题描述

这个简短的节目：


#include< stdio.h>

#include< stdlib.h>

int main（无效）{

int status;


status = fclose（0）;


printf（" fclose（0）status：％d \ n"，status）;


}


崩溃我试过的前两个实现。然后我尝试了DMC并且

给出了预期的EOF状态。


鉴于强调这组中的错误检查，它似乎令人惊讶

库函数（每个文件最多执行一次）不能这样做

初步检查它的参数。


（它可能fopen（）返回零FILE *句柄，但文件有

因其他原因被关闭，然后才能被应用程序检查。）


我不走运或C库函数如此脆弱是否正常？


- Bart

解决方案

Bartc说：

这个简短的程序：


#include< stdio.h>

#include< stdlib.h>


int main（无效）{

int status;


status = fclose（0）;


printf（" fclose（0）status：％d \ n"，status）;


}

在我尝试的前两个实现上崩溃了。

标准要求您传递fclose指向流对象的指针
$ B $类型为FILE。你没有这样做。 （0并不指向任何对象，

更不用说一个流对象。）你违反了规则，所以所有的赌注都关闭了。


< snip>

鉴于强调这个组中的错误检查，库函数（执行时）似乎令人惊讶

大多数一次每个文件）不能这样做

初步检查它的参数。

嗯，当然可以，但是没有义务。实现

的方法之一可以让你惊人的表现是将

的错误检查降到最低，相信你可以做任何

必须自己检查（因为替代方法是进行检查，

即使*你*知道他们不需要）。

我不走运或者C库函数如此脆弱是否正常？

C信任你。值得信任，或使用其他语言。


-

Richard Heathfield< http://www.cpax.org.uk>

电子邮件：-http：// www。 + rjh @

谷歌用户：< http://www.cpax.org.uk/prg/writings/googly.php>

Usenet是一个奇怪的放置" - dmr 1999年7月29日

Bartc写道：

这个简短的节目：

#include< stdio.h>

#include< stdlib.h>


int main（void）{

int status;


status = fclose（0）;


printf（" fclose（0）status：％ d\ n，状态;


}


在我尝试的前两个实现中崩溃了。然后我尝试了DMC和

，它们给出了预期的EOF状态。


鉴于强调这个组中的错误检查，似乎是

令人惊讶的是库函数（每个文件最多执行一次）

不能对它的参数进行基本检查。


（它可能fopen（）返回零FILE *句柄，但是文件

必须在其可以被

应用程序检查之前因其他原因而关闭。）


我运气不好或C库函数是否正常如此

脆弱？

根据标准fclose必须返回EOF，如果错误是

检测到。然而，它没有说明可能的错误范围。

如果操作无法关闭具有否则

完全有效的FILE *参数的文件，这是一个错误吗？根据标准答案

是明确的。如果fclose的参数是非法或无效的指针值，那么它也是一个错误吗？该标准没有明确地解决这个问题，但我认为其目的是将非法的

指针值（基本上是NULL和其他陷阱表示）视为

失败，因此返回EOF。 OTOH一个无效的指针值不能被大多数fclose的实现检测到，并且我认为它调用了

未定义的行为，其结果可能是从崩溃到

返回EOF。


因此对于有问题的代码我会说符合规范的编译器允许做任何事情，因为行为是在给fclose一个非法的

参数时，未定义（未明确

标准，但推断）。所以它变成了一个QoI问题，看起来DigitalMars的测试集的最佳行为是

。

" Bartc" ; < [e-mail]：

这个简短的程序：


#include< stdio.h>

#include< stdlib.h>


int main（void）{

int status;

status = fclose（0）;


printf（" fclose（0）status：％d \ n"，status）;


}


在我尝试的前两个实现上崩溃了。然后我尝试了DMC，并且

给出了预期的EOF状态。


鉴于强调这个组中的错误检查，似乎是

令人惊讶

库函数（每个文件最多执行一次）不能这样做

初步检查它的参数。


（fopen（）可能返回零FILE *句柄，但文件有

因其他原因被关闭，然后才能通过

申请。）

错误。阅读手册。

>

我是不是运气不好或C库函数如此脆弱是否正常？


- Bart

我喜欢它们崩溃的时候。这意味着我没有必要检查返回代码

的错误条件，我的调试器直接告诉我

坏了。


为什么我希望这些库能够掩盖我的草率错误？


过多的错误检查以覆盖懒惰的程序员可能会增加

不必要的开销。 />

This short program:

#include <stdio.h>
#include <stdlib.h>

int main(void) {
int status;

status=fclose(0);

printf("fclose(0) status: %d\n",status);

}

crashes on the first two implementations I tried. Then I tried DMC and that
gave the expected EOF status.

Given the emphasis on error-checking in this group, it seems astonishing
that a library function (executed at most once per file) cannot do this
elementary check on it''s parameter.

(It''s possible a zero FILE* handle is returned by fopen() but the file has
to be closed for other reasons before it can checked by the application.)

Was I unlucky or is it normal for C library functions to be so fragile?

-- Bart

解决方案

Bartc said:

This short program:

#include <stdio.h>
#include <stdlib.h>

int main(void) {
int status;

status=fclose(0);

printf("fclose(0) status: %d\n",status);

}

crashes on the first two implementations I tried.

The Standard requires that you pass to fclose a pointer to a stream object
of type FILE. You did not do this. (0 doesn''t point to any object at all,
let alone a stream object.) You broke the rules, so all bets are off.

<snip>

Given the emphasis on error-checking in this group, it seems astonishing
that a library function (executed at most once per file) cannot do this
elementary check on it''s parameter.

Well, of course it could, but it isn''t obliged to. One of the ways an
implementation can hand you astounding performance is to keep the
error-checking down to an absolute minimum, trusting you to do any
necessary checks yourself (because the alternative is to do the checks,
even when *you* know they''re not needed).

Was I unlucky or is it normal for C library functions to be so fragile?

C trusts you. Be worthy of that trust, or use a different language.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Bartc wrote:

This short program:

#include <stdio.h>
#include <stdlib.h>

int main(void) {
int status;

status=fclose(0);

printf("fclose(0) status: %d\n",status);

}

crashes on the first two implementations I tried. Then I tried DMC and
that gave the expected EOF status.

Given the emphasis on error-checking in this group, it seems
astonishing that a library function (executed at most once per file)
cannot do this elementary check on it''s parameter.

(It''s possible a zero FILE* handle is returned by fopen() but the file
has to be closed for other reasons before it can checked by the
application.)

Was I unlucky or is it normal for C library functions to be so
fragile?

According to the standard fclose must return EOF if "errors were
detected". However it says nothing about the range of possible errors.
Is it an error if the operation fails to close a file with an otherwise
perfectly valid FILE * parameter? According to the standard the answer
is a clear yes. Is it also an error if the argument to fclose is an
illegal or invalid pointer value? The standard doesn''t explicitly
address this issue, but I think the intent is to treat an illegal
pointer value (basically NULL and other trap representations) as a
failure, and hence return EOF. OTOH an invalid pointer value cannot be
detected by most implementations of fclose and I think it invokes
undefined behaviour, whose result might be anything from a crash to
returning EOF.

So for the code in question I''d say that conforming compilers are
allowed to do anything since the behaviour is undefined (not explicitly
stated in the standard, but inferred) upon giving fclose an illegal
argument. So it becomes a QoI issue and it seems that DigitalMars has
the best behaviour of your test set.

"Bartc" <[e-mail]:

This short program:

#include <stdio.h>
#include <stdlib.h>

int main(void) {
int status;

status=fclose(0);

printf("fclose(0) status: %d\n",status);

}

crashes on the first two implementations I tried. Then I tried DMC and that
gave the expected EOF status.

Given the emphasis on error-checking in this group, it seems
astonishing
that a library function (executed at most once per file) cannot do this
elementary check on it''s parameter.

(It''s possible a zero FILE* handle is returned by fopen() but the file has
to be closed for other reasons before it can checked by the
application.)

Error. Read the manual.

>
Was I unlucky or is it normal for C library functions to be so fragile?

-- Bart

I like it when they crash. It means I dont have to check the return code
for error conditions and my debugger tells me straightaway where it
broke.

Why would I want the libraries to cover up my sloppy mistakes?

Excessive error checking to cover for lazy programmers might well add
unnecessary overheads.

这篇关于FCLOSE（0）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！