T
TTroy
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)
(e-mail address removed)
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)
(e-mail address removed)