fgets，EOF在行中间，不会导致错误 [英] fgets, EOF in middle of line, does not cause error
问题描述
您好，
我在fgets运行时库中发现了一些奇怪的行为
函数用于我的编译器/ OS /平台（Dev C ++ / XP / P4） - 制作一个C
控制台程序（在CMD.exe shell中运行）。
标准说关于fgets：
概要
#include< stdio.h>
char * fgets（char * s，int n，FILE * stream）;
description
"如果成功，fgets函数返回s。如果遇到文件结尾为
并且没有字符读入数组，则数组的内容保持不变，并返回空指针。 />
如果在操作期间发生读取错误，则数组内容为
indeterminate并返回空指针。
我遇到的问题是，如果EOF是在另一个角色之后提供的，
fgets根本不会返回NULL来标记错误，所以我的错误捕获
code找不到任何东西。另外，对于我来说，行中的EOF，所有它都会导致fgets忽略EOF -AND-也会忽略所有内容，而不是在EOF之后的所有内容，包括第一次看到换行。
如果我提供EOF，那么fgets就会挂起，因为它基本上会丢弃EOF条件以及它之后的所有字符，包括
下一个换行符（通常会告诉fgets停止，但在这种情况下它是
只丢弃并忽略它）。所以我发现自己不得不再次打新线
来制作fgets -unblock-或wahtever你想要调用它。
例如，我跑了这个测试代码：
#include< stdio.h>
#include< stdlib.h>
#define MAXINPUT 30
int
main（无效）
{
char sample [MAXINPUT ];
if（！fgets（sample，MAXINPUT，stdin））
{
fprintf（stderr，" \\ \\ nffs（）错误，程序退出\ n"）;
退出（1）;
}
printf（ " sample =％s \ n"，sample）;
返回0;
}
我的输入是：
-------------
你好[EOF]白痴[\ n] [太空]世界[\ n]
我的输出是（不包括回声）：
--------------------------- ----------
sample =你好世界[\ n] [\ n]
- 请注意有两个输出中的换行符是因为fgets商店
a换行和我的printf格式字符串也有一个
正如你所看到的，所有fgets确实忽略了从EOF到
的所有内容
并包括下一个换行符。它肯定忽略了这个换行符，
因为fgets保持阻塞 - 并且程序仍在等待我的
输入（好像它需要另一个换行符） - 所以我键入了一个空间和
''world'然后点击输入（这个输入/换行正确注册并且
fgets unblocks）和fgets假设它输入{hello world \ n }和
只是忽略/丢弃中间部分：{[EOF] idiot \ n} - 忽略
括号，它们仅用作分隔符。
如果fgets返回一个类似
标准的空指针，那就不会打扰我了，因为我真的很想陷入这种类型
愚蠢的用户输入并处理它，但我甚至不能这样做。
有人可以在他们的系统上测试这个程序或者告诉我我是什么m $ / b $ b缺少？难道不应该返回空指针吗？
非常感谢每个人，
Tinesan Troy，B.Eng（mech）
ti*****@gmail.com
TTroy在12/03/05写道：
[目标新闻组修剪为clc]
问题我有，如果EOF是在另一个角色之后提供的，
你是如何通过键盘提供的？
-
Emmanuel
C-FAQ： http://www.eskimo.com/~scs/C-faq/faq.html
C库： http://www.dinkumware.com/refxc.html
C是一个锋利的工具
2005年3月11日21:59:05 -0800，在co mp.lang.c，TTroy < ti ***** @ gmail.com>
写道：
我遇到的问题是，如果是EOF在另一个角色之后提供，
fgets根本不会返回NULL来标记错误，所以我的错误捕获代码没有找到任何东西。
如果您正确阅读标准，您会看到如果fgets在
字符串中遇到eof，它将返回到目前为止读取的字符串。如果遇到
文件结束或错误，它只返回EOF。
-
Mark McIntyre
CLC FAQ< http://www.eskimo.com/~scs/C-faq/top.html>
CLC自述文件：< http://www.ungerhu.com/ jxh / clc.welcome.txt>
---- ==通过Newsfeeds.Com发布 - 无限制 - 未经审查 - 安全使用网新闻== ----
< a rel =nofollowhref =http://www.newsfeeds.comtarget =_ blank> http://www.newsfeeds.com 世界排名第一的新闻组服务！ 120,000多个新闻组
---- =东海岸和西海岸服务器农场 - 通过加密实现全面隐私= ----
我删除了来自新闻组列表的comp.std.c
星期五，2005年3月11日21:59:05 -0800，TTroy写道：
您好，
我在fgets运行时库中发现了一些奇怪的行为，我的编译器/ OS /平台（Dev C ++ / XP / P4） - 制作一个C />控制台程序（其中）在CMD.exe shell中运行。
标准说关于fgets：
概要
#include< stdio.h>
char * fgets（char * s，int n，FILE * stream）;
描述
"如果成功，fgets函数返回s。如果遇到文件结尾并且没有字符被读入数组，则数组的内容保持不变并返回空指针。
如果在读取错误期间发生读取错误操作，数组内容是不确定的，并返回一个空指针。
我遇到的问题是，如果EOF是在另一个角色之后提供的，
fgets根本不会返回NULL来标记错误，所以我的错误捕获代码没有找到任何东西。此外，对于我来说，行中的EOF，它都会导致fgets忽略EOF -AND-也会忽略EOF之后的所有内容，包括第一个看到的换行符。
首先，您在上面提供的标准报价不包括在读取某些字符后遇到EOF的
情况，这是
你感兴趣的案例。
其次，EOF之后怎么可能有什么东西？如果您在文本模式下打开它后正在阅读
二进制文件，那么我不得不说，
不要这样做。如果你认为它是一个文本文件，并以文本
模式打开它，但它有一个EOF字符其次是别的东西，然后呢
并不是真正的文本文件。如果你有一个以二进制
模式打开的二进制文件，我相信在EOF之后真的不可能有任何东西。但是你不应该在二进制文件上使用fgets。
如果你正在从控制台阅读（看起来是这样），你应该知道控制台输入通常由操作系统进行行缓冲，然后你的程序才能看到它。我想在
FAQ列表中有一些相关内容（您可能希望阅读）。您还应该知道，操作系统从控制台线路通信EOF的确切方式因操作系统而不同于操作系统，并且超出了C编程语言的范围。任何事件。
使用getc（）或
getchar（）写一个简单的十六进制转储程序可能很有启发性，并找出你的程序到底是什么当你在控制台中键入
各种东西时会看到。
如果我提供一个EOF，那么fgets会挂起，因为它基本上会丢弃EOF条件而且全部丢弃之后的字符包括
下一个换行符（通常告诉fgets停止，但在这种情况下它只是丢弃并忽略它）。所以我发现自己不得不再次打到换行符来制作fgets -unblock-或者你想要调用它。
[snip]
如果fgets返回一个像
标准那样的空指针，这就不会打扰我了，因为我会真的很喜欢陷入这种类型的愚蠢的用户输入并处理它，但我甚至不能这样做。
你在上面发布的标准引用了不要说fgets
在读取至少一个字符后遇到EOF时返回NULL。
如果你认为标准在某个地方说了，请发布它。
有人可以在他们的系统上测试这个程序或者告诉我我错过了什么吗？是不是应该返回一个空指针？
如果它读取一些
字符然后遭遇，则不应返回空指针一个EOF。
非常感谢每个人，
Tinesan Troy，B.Eng（mech）
ti ***** @ gmail.com
--Mac
Hello,
I have found some peculiar behaviour in the fgets runtime library
function for my compiler/OS/platform (Dev C++/XP/P4) - making a C
console program (which runs in a CMD.exe shell).
The standard says about fgets:
synopsis
#include <stdio.h>
char *fgets(char *s, int n, FILE *stream);
description
"The fgets function returns s if successful. If end-of-file is
encountered and no characters have been read into the array, the
contents of the array remain unchanged and a null pointer is returned.
If a read error occurs during the operation, the array contents are
indeterminate and a null pointer is returned."
The problem I''m having is, if EOF is provided after another character,
fgets simply doesn''t return NULL to flag an error, so my error catching
code is not finding anything. Also, the EOF in the line, for me, all
it does it causes fgets to ignore the EOF -AND- also ignore everything
after the EOF upto and including the first seen newline.
So fgets hangs if I provide it with an EOF, because it basically
discards the EOF condition and all characters after it including the
next newline(which normally tells fgets to stop, but in this case it
just discards and ignores it). So I find myself having to hit newline
again to make fgets -unblock- or wahtever you want to call it.
For example, I ran this test code:
#include <stdio.h>
#include <stdlib.h>
#define MAXINPUT 30
int
main(void)
{
char sample[MAXINPUT];
if(!fgets(sample, MAXINPUT, stdin))
{
fprintf(stderr, "\nfgets() error, program quitting\n");
exit(1);
}
printf("sample = %s\n", sample);
return 0;
}
My input was:
-------------
hello[EOF]idiot[\n][space]world[\n]
My output was (not including echoes):
-------------------------------------
sample = hello world[\n][\n]
- notice that there are two newlines in the output because fgets stores
a newline and my printf format string also has one
As you can see, all fgets did was ignore everything from the EOF upto
and including the next newline. It definitely ignored this newline,
because fgets stayed -blocked- and the program was still waiting for my
input (as if it required another newline) - so I typed a space and
''world'' then hit enter (this enter/newline registered properly and
fgets unblocks) and fgets assumed it go the input {hello world\n} and
just ignored/discarded the middle part: {[EOF]idiot\n} - ignore the
braces, they are used as delimitters only.
This wouldn''t bother me if fgets returned a null pointer like the
standard said it would, because I would really like to trap this type
of stupid user input and deal with it, but I can''t even do that.
Can someone test this program on their system or tell me what I''m
missing? Isn''t fgets supposed to return a null pointer?
thanking everyone very much,
Tinesan Troy, B.Eng (mech)
ti*****@gmail.com
TTroy wrote on 12/03/05 :
[destination newsgroups trimmed to clc]
The problem I''m having is, if EOF is provided after another character,
How did you provide it from the keyboard ?
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
On 11 Mar 2005 21:59:05 -0800, in comp.lang.c , "TTroy" <ti*****@gmail.com>
wrote:
The problem I''m having is, if EOF is provided after another character,
fgets simply doesn''t return NULL to flag an error, so my error catching
code is not finding anything.
If you read the standard correctly, you''ll see that if fgets encounters eof in a
string, it returns the string read so far. It only returns EOF if it encounters
end-of-file or an error.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
I deleted comp.std.c from the newsgroups list.
On Fri, 11 Mar 2005 21:59:05 -0800, TTroy wrote:
Hello,
I have found some peculiar behaviour in the fgets runtime library
function for my compiler/OS/platform (Dev C++/XP/P4) - making a C
console program (which runs in a CMD.exe shell).
The standard says about fgets:
synopsis
#include <stdio.h>
char *fgets(char *s, int n, FILE *stream);
description
"The fgets function returns s if successful. If end-of-file is
encountered and no characters have been read into the array, the
contents of the array remain unchanged and a null pointer is returned.
If a read error occurs during the operation, the array contents are
indeterminate and a null pointer is returned."
The problem I''m having is, if EOF is provided after another character,
fgets simply doesn''t return NULL to flag an error, so my error catching
code is not finding anything. Also, the EOF in the line, for me, all
it does it causes fgets to ignore the EOF -AND- also ignore everything
after the EOF upto and including the first seen newline.
First of all, the standard quote you provided above does not cover the
case where EOF is encountered after some characters are read, which is the
case you are interested in.
Second, how can there possibly be anything after EOF? If you are reading a
binary file after opening it in text mode, then I would have to say,
"Don''t do that." If you think it is a text file, and open it up in text
mode, but it has an "EOF character" followed by something else, then it
isn''t really a text file. And if you have a binary file opened in binary
mode, I believe it is truly impossible to have anything after an EOF. But
you shouldn''t really use fgets on a binary file.
If you are reading from the console (as appears to be the case), you
should be aware that console input is often line buffered by the OS before
your program even sees it. I think there is something about this in the
FAQ list (which you might want to read). You should also be aware that the
exact way the OS communicates EOF from the console line varies from OS to
OS, and is outside the scope of the C programming language in any event.
It may be enlightening to write a simple hex dump program using getc() or
getchar(), and find out exactly what your program sees when you type
various things into the console.
So fgets hangs if I provide it with an EOF, because it basically
discards the EOF condition and all characters after it including the
next newline(which normally tells fgets to stop, but in this case it
just discards and ignores it). So I find myself having to hit newline
again to make fgets -unblock- or wahtever you want to call it.
[snip]
This wouldn''t bother me if fgets returned a null pointer like the
standard said it would, because I would really like to trap this type of
stupid user input and deal with it, but I can''t even do that.
The quote from the standard you posted above does not say that fgets
returns NULL when EOF is encountered after reading at least one character.
If you think the standard says that somewhere, please post it.
Can someone test this program on their system or tell me what I''m
missing? Isn''t fgets supposed to return a null pointer?
No. fgets is not supposed to return a null pointer if it reads some
characters then encounters an EOF.
thanking everyone very much,
Tinesan Troy, B.Eng (mech)
ti*****@gmail.com
--Mac
这篇关于fgets，EOF在行中间，不会导致错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
