sscanf and EOF vs error
David Mathog
error condition than I do.
Here's a bit of example code to demonstrate this:
# cat >foo.c <<EOD
#include <stdlib.h>
#include <stdio.h>
int main(void){
int val,retval;
retval=sscanf("123","%d",&val);
(void) fprintf(stdout,"123 -> %d %d\n",retval, val);
retval=sscanf("123.1","%d",&val);
(void) fprintf(stdout,"123.1 -> %d %d\n",retval, val);
retval=sscanf("blat","%d",&val);
(void) fprintf(stdout,"blat -> %d %d %d\n",retval, val, EOF);
}
# gcc -o foo foo.c
# ./foo
123 -> 1 123
123.1 -> 1 123
blat -> 0 123 -1
I had always thought that sscanf would return an EOF if it was fed an
input string
and a single format specifier, and it could not properly convert that
string using that
specifier. That is not what happens though (I only tested Solaris Forte
C, Solaris gcc, and
Linux gcc). Rather than coming back with a -1 for "blat"-> integer it
returns a 0. I've seen
an awful lot of code, including my own (unfortunately) that uses:
if(sscanf(string,"%d",&val)==EOF){
/* error condition */
}
else {
/* valid data in val */
}
Now it looks like all such code is going to just return whatever was in
"val", which is probably not what
was intended.
What am I missing? Why doesn't the %i conversion of "blat" to an
integer trigger an error condition???
Thanks,
David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech
willem veenhoven
>
> Today I discovered that sscanf seems to have a very different
> idea of an error condition than I do.
I don't understand this remark, because
> retval = sscanf("blat","%d",&val);
> fprintf(stdout, "blat -> %d %d %d\n", retval, val, EOF);
> blat -> 0 123 -1
is exactly what I would expect from the behaviour of sscanf.
It returns 0 meaning that none of the fields in the format string
had successfully been scanned, it prints 123 for val because that
just happened to be the value you put into it before you called
sscanf with this format string, and it prints -1 for EOF, because
that's the value EOF has been defined to have.
So what's the problem?
willem
Tobias Oed
sscanf returns the number of conversion specifiers that have been
successfully processed. So you want
if(sscanf(string,"%d",&val)!=1){
/* error */
}
More generally, you want to ensure that the return value is
equal to the number of conversion you want.
sscanf will return EOF only if it hits the terminating '\0' in the
input string before any conversion has been processes. Try
retval=sscanf("","%d",&val);
(void) fprintf(stdout,"\"\" -> %d %d %d\n",retval, val, EOF);
you'll get EOF in retval.
Tobias.
Mike Mccarty Sr
willem veenhoven <wil...@veenhoven.com> wrote:
)David Mathog wrote:
)>
)> Today I discovered that sscanf seems to have a very different
)> idea of an error condition than I do.
)
)I don't understand this remark, because
)
)> retval = sscanf("blat","%d",&val);
)> fprintf(stdout, "blat -> %d %d %d\n", retval, val, EOF);
)> blat -> 0 123 -1
)
)is exactly what I would expect from the behaviour of sscanf.
)
)It returns 0 meaning that none of the fields in the format string
)had successfully been scanned, it prints 123 for val because that
)just happened to be the value you put into it before you called
)sscanf with this format string, and it prints -1 for EOF, because
)that's the value EOF has been defined to have.
)
)So what's the problem?
The problem is that he hasn't read the spec on what sscanf() returns.
The sscanf() function *never* returns EOF, as he thinks.
--
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I can explain it for you, but I can't understand it for you.
I don't speak for Alcatel <- They make me say that.
Mark McIntyre
wrote:
>Today I discovered that sscanf seems to have a very different idea of an
>error condition than I do.
> retval=sscanf("blat","%d",&val);
> (void) fprintf(stdout,"blat -> %d %d %d\n",retval, val, EOF);
sscanf returns a count of the number of successful conversions. If it
can't convert a value, the contents of hte object that would have
received it are unchanged. So
>blat -> 0 123 -1
is exactly right because you converted zero objects, and val
contained 123 before.
>if(sscanf(string,"%d",&val)==EOF){
sscanf returns EOF only if it encounters an error before any
conversions are attempted
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
Floyd Davidson
>
>The problem is that he hasn't read the spec on what sscanf() returns.
>
>The sscanf() function *never* returns EOF, as he thinks.
7.19.6.7 The sscanf function
...
Returns
3 The sscanf function returns the value of the macro EOF
if an input failure occurs before any conversion.
Otherwise, the sscanf function returns the number of input
items assigned, which can be fewer than provided for, or
even zero, in the event of an early matching failure.
--
Floyd L. Davidson <http://www.ptialaska.net/~floyd>
Ukpeagvik (Barrow, Alaska) fl...@barrow.com
Villy Kruse
Floyd Davidson <fl...@ptialaska.net> wrote:
>jmcc...@sun1307.ssd.usa.alcatel.com (Mike Mccarty Sr) wrote:
>>
>>The problem is that he hasn't read the spec on what sscanf() returns.
>>
>>The sscanf() function *never* returns EOF, as he thinks.
>
> 7.19.6.7 The sscanf function
>
> ...
>
> Returns
>
> 3 The sscanf function returns the value of the macro EOF
> if an input failure occurs before any conversion.
> Otherwise, the sscanf function returns the number of input
> items assigned, which can be fewer than provided for, or
> even zero, in the event of an early matching failure.
>
>
Where could an input failur occur for a function which only does incore
data manipulation? This is not scanf() nor fscanf().
Villy
Richard Heathfield
Just a guess: sscanf("3", "%c%c", &ch1, &ch2);
But I'm not a great fan of sscanf, so beware this guess with much
bewariness. :-)
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Floyd Davidson
An input failure occurs when the nul terminator is reached, for
example.
Hence
sscanf("", "%d", x);
returns EOF, and
sscanf("x", "%d", x);
returns 0.
Dan Pop
Compare
sscanf("", "%d", &i);
versus
sscanf("abc", "%d", &i);
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Dan Pop
>Villy Kruse wrote:
>>
>> On 31 Oct 2001 14:04:23 -0900,
>> Floyd Davidson <fl...@ptialaska.net> wrote:
>>
>> >jmcc...@sun1307.ssd.usa.alcatel.com (Mike Mccarty Sr) wrote:
>> >>
>> >>The problem is that he hasn't read the spec on what sscanf() returns.
>> >>
>> >>The sscanf() function *never* returns EOF, as he thinks.
>> >
>> > 7.19.6.7 The sscanf function
>> >
>> > ...
>> >
>> > Returns
>> >
>> > 3 The sscanf function returns the value of the macro EOF
>> > if an input failure occurs before any conversion.
>> > Otherwise, the sscanf function returns the number of input
>> > items assigned, which can be fewer than provided for, or
>> > even zero, in the event of an early matching failure.
>> >
>> >
>>
>> Where could an input failur occur for a function which only does incore
>> data manipulation? This is not scanf() nor fscanf().
>
>
>Just a guess: sscanf("3", "%c%c", &ch1, &ch2);
Bad guess. Your example *clearly* matches the second phrase of the
above quote.
Mike Mccarty Sr
Floyd Davidson <fl...@ptialaska.net> wrote:
)v...@pharmnl.ohout.pharmapartners.nl (Villy Kruse) wrote:
)> Floyd Davidson <fl...@ptialaska.net> wrote:
)>>jmcc...@sun1307.ssd.usa.alcatel.com (Mike Mccarty Sr) wrote:
)>>>
)>>>The problem is that he hasn't read the spec on what sscanf() returns.
)>>>
)>>>The sscanf() function *never* returns EOF, as he thinks.
)>>
)>> 7.19.6.7 The sscanf function
)>>
)>> ...
)>>
)>> Returns
)>>
)>> 3 The sscanf function returns the value of the macro EOF
)>> if an input failure occurs before any conversion.
)>> Otherwise, the sscanf function returns the number of input
)>> items assigned, which can be fewer than provided for, or
)>> even zero, in the event of an early matching failure.
)>>
)>
)>Where could an input failur occur for a function which only does incore
)>data manipulation? This is not scanf() nor fscanf().
)
)An input failure occurs when the nul terminator is reached, for
)example.
Please quote the Standard.
Here are every location in the C89 Standard where the phrase "input
failure" occurs:
--------------------------------
The //fscanf// function executes each directive of the format in
turn. If a directive fails, as detailed below, the //fscanf// function
returns. Failures are described as input failures (due to the
unavailability of input characters), or matching failures (due to
inappropriate input).
--------------------------------
If end-of-file is encountered during input, conversion is
terminated. If end-of-file occurs before any characters matching the
current directive have been read (other than leading white space, where
permitted), execution of the current directive terminates with an input
failure; otherwise, unless execution of the current directive is
terminated with a matching failure, execution of the following
directive (if any) is terminated with an input failure.
--------------------------------
The //fscanf// function returns the value of the macro EOF if an
input failure occurs before any conversion. Otherwise, the //fscanf//
function returns the number of input items assigned, which can be fewer
than provided for, or even zero, in the event of an early matching
failure.
--------------------------------
The //scanf// function returns the value of the macro EOF if an
input failure occurs before any conversion. Otherwise, the //scanf//
function returns the number of input items assigned, which can be fewer
than provided for, or even zero, in the event of an early matching
failure.
--------------------------------
The //sscanf// function returns the value of the macro EOF if an
input failure occurs before any conversion. Otherwise, the //sscanf//
function returns the number of input items assigned, which can be fewer
than provided for, or even zero, in the event of an early matching
failure.
--------------------------------
The only locations where there is a definition of the term "input
failure" is defined are either related to //fscanf//, or mention
"end-of-file", neither of which applies to sscanf(). Thus, the Standard
prohibits sscanf() to return EOF.
Mike
Richard Heathfield
Oops... Oh well. Just as well I stuck a caveat in there. Sorry about
that, Dan.
I really /must/ learn about *scanf one day soon...
Stephen Howe
>
> Here are every location in the C89 Standard where the phrase "input
> failure" occurs:
And that is no out of date.
Please quote the C99 Standard not the C89 Standard
Stephen Howe
krishna kumar rangan
> retval=sscanf("blat","%d",&val);
> (void) fprintf(stdout,"blat -> %d %d %d\n",retval, val, EOF);
> }
> blat -> 0 123 -1
>
> What am I missing? Why doesn't the %i conversion of "blat" to an
> integer trigger an error condition???
sscanf man page says that -sscanf() functions return the number of
success-fully matched and assigned input items. This number can be
0 (zero) if there was an early conflict between an input character and
the control string. If the input ends before the first conflict
or conversion, the functions return EOF.
Chris Torek
Mark McIntyre <ma...@garthorn.demon.co.uk> writes:
>sscanf returns EOF only if it encounters an error before any
>conversions are attempted
I think it is better to use the Standard's phrase, "input failure",
here, rather than "an error". As others have noted elsewhere in
this thread, "input failure" occurs if and when sscanf() reaches
the end of the string.
The scanf() family in general is rather ugly. It terminates on:
- exhaustion of the format, or
- input failure, or
- matching failure
whichever occurs first. It is difficult or impossible to distinguish
between certain classes of failures in some cases (although for
regular "FILE *" objects, "input failure" means that at least one
of feof() or ferror() will return a nonzero value). That, in turn,
means it is often impossible to tell what state the stream has.
This "failure to distinguish between kinds of failures" is not as
serious for sscanf(), since there is no stream-state to worry about.
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
El Cerrito, CA, USA Domain: to...@bsdi.com +1 510 234 3167
http://claw.eng.bsdi.com/torek/ (not always up) I report spam to abuse@.
Lew Pitcher
Sr) wrote:
[snip]
--------------------------------
>
> The //sscanf// function returns the value of the macro EOF if an
>input failure occurs before any conversion. Otherwise, the //sscanf//
>function returns the number of input items assigned, which can be fewer
>than provided for, or even zero, in the event of an early matching
>failure.
>
>--------------------------------
>
>The only locations where there is a definition of the term "input
>failure" is defined are either related to //fscanf//, or mention
>"end-of-file", neither of which applies to sscanf(). Thus, the Standard
>prohibits sscanf() to return EOF.
Assuming
int num;
What would
sscanf("","%d",&num);
return?
Lew Pitcher
IT Consultant, Development Services
Toronto Dominion Bank Financial Group
(Opinions expressed are my own, not my employers')
Larry Jones
Can you not read? The description of sscanf clearly says:
Reaching the end of the string is equivalent to encountering
end-of-file for the fscanf function.
-Larry Jones
Hello, I'm wondering if you sell kegs of dynamite. -- Calvin
Mark McIntyre
<bin...@eton.powernet.co.uk> wrote:
>Villy Kruse wrote:
>>
>> On 31 Oct 2001 14:04:23 -0900,
>> Floyd Davidson <fl...@ptialaska.net> wrote:
>>
>> >jmcc...@sun1307.ssd.usa.alcatel.com (Mike Mccarty Sr) wrote:
>> >>
>> >>The problem is that he hasn't read the spec on what sscanf() returns.
>> >>
>> >>The sscanf() function *never* returns EOF, as he thinks.
>> >
>> > 7.19.6.7 The sscanf function
>> >
>> > ...
>> >
>> > Returns
>> >
>> > 3 The sscanf function returns the value of the macro EOF
>> > if an input failure occurs before any conversion.
>> > Otherwise, the sscanf function returns the number of input
>> > items assigned, which can be fewer than provided for, or
>> > even zero, in the event of an early matching failure.
>> >
>> >
>>
>> Where could an input failur occur for a function which only does incore
>> data manipulation? This is not scanf() nor fscanf().
>
>
>Just a guess: sscanf("3", "%c%c", &ch1, &ch2);
No, that would work. My guess would be
char *foo = NULL;
sscanf(foo, "%f", &f);
which is probably as wrong
glen herrmannsfeldt
>Today I discovered that sscanf seems to have a very different idea of an
>error condition than I do.
>Here's a bit of example code to demonstrate this:
># cat >foo.c <<EOD
>#include <stdlib.h>
>#include <stdio.h>
>int main(void){
>int val,retval;
> retval=sscanf("123","%d",&val);
> (void) fprintf(stdout,"123 -> %d %d\n",retval, val);
> retval=sscanf("123.1","%d",&val);
> (void) fprintf(stdout,"123.1 -> %d %d\n",retval, val);
> retval=sscanf("blat","%d",&val);
> (void) fprintf(stdout,"blat -> %d %d %d\n",retval, val, EOF);
>}
># gcc -o foo foo.c
># ./foo
>123 -> 1 123
>123.1 -> 1 123
>blat -> 0 123 -1
>I had always thought that sscanf would return an EOF if it was fed an
>input string and a single format specifier, and it could not properly
>convert that string using that specifier.
I sometimes test that the return value is >= the number of conversion
I expect. Sometimes I initialize the variables to convenient values
and test for those values.
I have used sscanf to accept either a number or start:end range where
they should be non-negative. I set two variables to -1, then
sscanf(str,"%d:%d",&start,&end); If end is still -1 then I set
it to start.
The description is confusing because they describe scanf/fscanf/sscanf
all at once.
-- glen
glen herrmannsfeldt
>In v...@pharmnl.ohout.pharmapartners.nl (Villy Kruse) writes:
>> Floyd Davidson <fl...@ptialaska.net> wrote:
>>> 7.19.6.7 The sscanf function
>>>
>>> 3 The sscanf function returns the value of the macro EOF
>>> if an input failure occurs before any conversion.
>>> Otherwise, the sscanf function returns the number of input
>>> items assigned, which can be fewer than provided for, or
>>> even zero, in the event of an early matching failure.
>>
>>Where could an input failur occur for a function which only does incore
>>data manipulation? This is not scanf() nor fscanf().
>Compare
> sscanf("", "%d", &i);
>versus
> sscanf("abc", "%d", &i);
This still doesn't seem so obvious. The failure must occur before
any conversion, but does it look at the input string first or the
format string first. If it looks at the format string first, it
"begins conversion" then looks at the input string and finds no
characters to convert. When exactly does conversion begin?
Now, for the scanf/fscanf case it should return EOF if there are
no characters available before reaching EOF. If there are characters,
either that can be converted (digits for %d) or can't (letters, for
example) it won't return EOF. That might imply that it must test
the input string before the format, at least for scanf/fscanf.
Testing scanf/fscanf for EOF is a good way to get an infinite loop.
Testing < than the expected number of input values should not do that.
Note that while scanf/fscanf don't work well for interactive input,
used properly they aren't so bad for file input. That includes
doing the right test to exit any loops.
-- glen
Floyd Davidson
See above... That is a direct quote from the C99 document
(ISO/IEC 9899:1999 (E).
>Here are every location in the C89 Standard where the phrase "input
>failure" occurs:
[ 30 some lines deleted to get to the point ]
> The //sscanf// function returns the value of the macro EOF if an
>input failure occurs before any conversion. Otherwise, the //sscanf//
^^^^^^^^^^^^^
>function returns the number of input items assigned, which can be fewer
>than provided for, or even zero, in the event of an early matching
>failure.
>
>--------------------------------
>
>The only locations where there is a definition of the term "input
>failure" is defined are either related to //fscanf//, or mention
>"end-of-file", neither of which applies to sscanf(). Thus, the Standard
>prohibits sscanf() to return EOF.
Actually your quote of the C89 Standard actually says exactly
the same thing as the C99 Standard that I quoted, and in fact
does say that sscanf() returns EOF in one specific instance.
CBFalconer
>
... snip ...
>
> Note that while scanf/fscanf don't work well for interactive input,
> used properly they aren't so bad for file input. That includes
> doing the right test to exit any loops.
Exception:
int getnum(FILE *f, int *value) {
return (1 == fscanf(f, "%d", value));
}
...
if (!getnum(f, i)) {
badentry();
}
else {
allswell();
}
works just fine as an interactive routine. No buffers needed.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:u...@ftc.gov (for spambots to harvest)
glen herrmannsfeldt
>glen herrmannsfeldt wrote:
>... snip ...
>>
>> Note that while scanf/fscanf don't work well for interactive input,
>> used properly they aren't so bad for file input. That includes
>> doing the right test to exit any loops.
>Exception:
>int getnum(FILE *f, int *value) {
> return (1 == fscanf(f, "%d", value));
>}
(snip)
>works just fine as an interactive routine. No buffers needed.
There are so many posts here about not using fscanf() that I
didn't want to start too much discussion on it. Yes, it does
work, but you have to be darn careful. What if someone types
YES in answer to your question?
Do you use getnum() in a loop, and when do you exit the loop?
-- glen
CBFalconer
You get back false, and the 'YES' is still in the input stream.
When it gets a number, it return true.
int array[MAX];
int i = 0;
while ((i < MAX) & getnum(f, &array[i])) i++;
/* now i is count of numbers entered, and they are in array */
reads happily from:
1 2 3
4
5
done
and the input will next read the "done" or whatever terminated the
string of numbers. getnum does what it says - it gets a number and
reports success/failure. Nothing more.
Gergo Barany
> glen herrmannsfeldt wrote:
> > Note that while scanf/fscanf don't work well for interactive input,
> > used properly they aren't so bad for file input. That includes
> > doing the right test to exit any loops.
>
> Exception:
>
> int getnum(FILE *f, int *value) {
>
> return (1 == fscanf(f, "%d", value));
> }
This does not help against overflow; the behavior is undefined if
the result of the conversion cannot be represented in an int.
Gergo
--
Signs of crime: screaming or cries for help.
-- The Brown University Security Crime Prevention Pamphlet
Dan Pop
>> Please quote the Standard.
>>
>> Here are every location in the C89 Standard where the phrase "input
>> failure" occurs:
>
>And that is no out of date.
Yet, it is the standard actually implemented.
>Please quote the C99 Standard not the C89 Standard
Why? Does it have *any* relevance at all to the existing implementations?
CBFalconer
>
> CBFalconer <cbfal...@yahoo.com> wrote:
> > glen herrmannsfeldt wrote:
> > > Note that while scanf/fscanf don't work well for interactive input,
> > > used properly they aren't so bad for file input. That includes
> > > doing the right test to exit any loops.
> >
> > Exception:
> >
> > int getnum(FILE *f, int *value) {
> >
> > return (1 == fscanf(f, "%d", value));
> > }
>
> This does not help against overflow; the behavior is undefined if
> the result of the conversion cannot be represented in an int.
The whole land of C is unprotected against overflow, in 9 out of
10 implementations. Maybe 99 out of 100. BUT, if you use the
above, you can always replace it with an equivalent routine that
does object.
Dan Pop
>Gergo Barany wrote:
>>
>> CBFalconer <cbfal...@yahoo.com> wrote:
>> > glen herrmannsfeldt wrote:
>> > > Note that while scanf/fscanf don't work well for interactive input,
>> > > used properly they aren't so bad for file input. That includes
>> > > doing the right test to exit any loops.
>> >
>> > Exception:
>> >
>> > int getnum(FILE *f, int *value) {
>> >
>> > return (1 == fscanf(f, "%d", value));
>> > }
>>
>> This does not help against overflow; the behavior is undefined if
>> the result of the conversion cannot be represented in an int.
>
>The whole land of C is unprotected against overflow, in 9 out of
>10 implementations. Maybe 99 out of 100.
In this particular context, C provides overflow-safe conversion routines:
the strto* functions.
Floyd Davidson
>"Stephen Howe" <SPAMstephe...@tnsofres.com> writes:
>
>>> Please quote the Standard.
>>>
>>> Here are every location in the C89 Standard where the phrase "input
>>> failure" occurs:
>>
>>And that is no out of date.
>
>Yet, it is the standard actually implemented.
>
>>Please quote the C99 Standard not the C89 Standard
>
>Why? Does it have *any* relevance at all to the existing implementations?
But a moot point in this case. They both use identical wording.
Larry Jones
>
> sscanf returns a count of the number of successful conversions. If it
> can't convert a value, the contents of hte object that would have
> received it are unchanged.
There is no such guarantee in the standard.
-Larry Jones
You just can't ever be too careful. -- Calvin