scanf pushes back two chars?

[Steve Kobes]

I ran the following program on gcc:

#include <stdio.h>

int main(void)
{
unsigned int i;
char c;

if (scanf("%x", &i) == 1)
printf("i = %u\n", i);

if (scanf("%c", &c) == 1)
printf("c = %c\n", c);

return 0;
}

I gave it the following input:

0xg

I expected the first scanf call to fail, since 'g' is not a hex digit
and "0x" is not a hex number. The 'g' would then be pushed back onto
the input stream, and the only output would be:

c = g

Instead, I got the following output:

i = 0
c = x

Is this output correct? It seems like the first scanf call must have
pushed *two* characters ('x' and 'g') back onto the input stream. Was
it supposed to?

--Steve

[Jack Klein]

On 5 Sep 2004 21:24:07 -0700, st*********@hotmail.com (Steve Kobes)
wrote in comp.lang.c:

I ran the following program on gcc:

#include <stdio.h>

int main(void)
{
unsigned int i;
char c;

if (scanf("%x", &i) == 1)
printf("i = %u\n", i);

if (scanf("%c", &c) == 1)
printf("c = %c\n", c);

return 0;
}

I gave it the following input:

0xg

I expected the first scanf call to fail, since 'g' is not a hex digit
and "0x" is not a hex number. The 'g' would then be pushed back onto
the input stream, and the only output would be:

c = g

Instead, I got the following output:

i = 0
c = x

Is this output correct? It seems like the first scanf call must have
pushed *two* characters ('x' and 'g') back onto the input stream. Was
it supposed to?

--Steve

What makes you think it pushed back two characters? There are several
other possible explanations.

There have been implementations of scanf() that do not handle a "0x"
prefix properly, yours could be one. Have you verified the results
when you enter "0xfg"?

In any case, you have a defect in your library's implementation of the
function, which is a library problem, not a gcc problem. I suggest
you contact the source of the library.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Martin Ambuhl]

Steve Kobes wrote:

I ran the following program on gcc:

#include <stdio.h>

int main(void)
{
unsigned int i;
char c;

if (scanf("%x", &i) == 1)
printf("i = %u\n", i);

if (scanf("%c", &c) == 1)
printf("c = %c\n", c);

return 0;
}

I gave it the following input:

0xg

I expected the first scanf call to fail, since 'g' is not a hex digit
and "0x" is not a hex number. The 'g' would then be pushed back onto
the input stream, and the only output would be:

c = g

Instead, I got the following output:

i = 0
c = x

To add to your puzzlement, with gcc 3.41 I get
i = 0
c = g

Your result seems right and mine wrong. Since the specification for
strtoul reads

If the value of base is 16, the characters 0x or 0X may optionally
precede the sequence of letters and digits, following the sign if
present.

4 The subject sequence is defined as the longest initial subsequence
of the input string, starting with the first non-white-space
character, that is of the expected form. The subject sequence contains
no characters if the input string is empty or consists entirely of
white space, or if the first non-white-space character is other than a
sign or a permissible letter or digit.

The longest subsequence of the expected form is '0', with the next tail
beginning with 'x'. Note that the '0x' is optional, so '0' *is* of the
expected form.

[Chris Torek]

In article <news:2q************@uni-berlin.de>
Martin Ambuhl <ma*****@earthlink.net> wrote:

... the specification for strtoul reads

If the value of base is 16, the characters 0x or 0X may optionally
precede the sequence of letters and digits, following the sign if
present.

4 The subject sequence is defined as the longest initial subsequence
of the input string, starting with the first non-white-space
character, that is of the expected form. The subject sequence contains
no characters if the input string is empty or consists entirely of
white space, or if the first non-white-space character is other than a
sign or a permissible letter or digit.

The longest subsequence of the expected form is '0', with the next tail
beginning with 'x'. Note that the '0x' is optional, so '0' *is* of the
expected form.

The scanf() specification in the ANSI/ISO C standard -- at least the
original C89 one -- is confusing.

When I wrote the scanf engine for 4.4BSD, I decided that input of
the form:

4.123e+oops

would match %f (and similar) specifications through the "4.123"
but not the "e+oops" part, and thus leave "e+oops" unread in the
stream, available for subsequent input operations (scanf %c
conversions, getc(), etc.).

Since then, I have been told that scanf is supposed to be highly
destructive and discard some or all of the unusable "e+oops" because
it *begins* with a legitimate sequence, but is not actually one.
(Compare 4.123e+oops with 4.123e+17andtrailingstuff, for instance.)

A few example of just what is to be matched, what is to be discarded,
and what is to be left behind in the input stream, on various inputs
for various formats, would help implementors a great deal, I think.
(It certainly would have helped me.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[CBFalconer]

Chris Torek wrote:

.... snip ...
Since then, I have been told that scanf is supposed to be highly
destructive and discard some or all of the unusable "e+oops" because
it *begins* with a legitimate sequence, but is not actually one.
(Compare 4.123e+oops with 4.123e+17andtrailingstuff, for instance.)

A few example of just what is to be matched, what is to be discarded,
and what is to be left behind in the input stream, on various inputs
for various formats, would help implementors a great deal, I think.
(It certainly would have helped me.)

Most, if not all, of these anomalies could be handled in one swell
foop by increasing the pushback limit of ungetc to 3.

--
"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - Bush.
"If I knew then what I know today, I would still have invaded
Iraq. It was the right decision" - G.W. Bush, 2004-08-02

[Old Wolf]

Martin Ambuhl <ma*****@earthlink.net> wrote:

if (scanf("%x", &i) == 1)
printf("i = %u\n", i);

if (scanf("%c", &c) == 1)
printf("c = %c\n", c);

I gave it the following input:

0xg

Instead, I got the following output:

i = 0
c = x

To add to your puzzlement, with gcc 3.41 I get
i = 0
c = g

Your result seems right and mine wrong.

Isn't this a feature of glibc rather than gcc ?

[Steve Kobes]

Martin Ambuhl wrote:

Steve Kobes wrote:

I expected the first scanf call to fail, since 'g' is not
a hex digit and "0x" is not a hex number. The 'g' would
then be pushed back onto the input stream, and the only
output would be:

c = g

Instead, I got the following output:

i = 0
c = x

To add to your puzzlement, with gcc 3.41 I get
i = 0
c = g

Your result seems right and mine wrong.
[snip strtoul spec]

In scanf,

"An input item is defined as the longest sequence of input characters
(up to any specified maximum field width) which is an initial
subsequence of a matching sequence." (C89)

"An input item is defined as the longest sequence of input characters
which does not exceed any specified field width and which is, or is a
prefix of, a matching input sequence." (C99, AFAICT trying to say the
same thing more clearly)

And in the next paragraph:

"If the input item is not a matching sequence, the execution of the
directive fails: this condition is a matching failure." (C89 and C99)

This sounds pretty clear to me: given 0xg with %x, "0x", not "0", is
the input item, and it is a matching failure because "0x" is not a
matching input sequence. And there's no reason to think that the 'x'
should be pushed back onto the input stream.

Same with 4.123e+oops and %f... the input item is "4.123e+" (the
longest sequence that COULD begin a match), all of which is read and
discarded.

This means GCC gets it wrong for both Martin and me (in two different
ways, which I don't understand since I'm also using 3.4.1). Visual
C++ 6 seems to do it correctly.

[Keith Thompson]

ol*****@inspire.net.nz (Old Wolf) writes:

Martin Ambuhl <ma*****@earthlink.net> wrote:

>
> if (scanf("%x", &i) == 1)
> printf("i = %u\n", i);
>
> if (scanf("%c", &c) == 1)
> printf("c = %c\n", c);
>
> I gave it the following input:
>
> 0xg
>
> Instead, I got the following output:
>
> i = 0
> c = x

To add to your puzzlement, with gcc 3.41 I get
i = 0
c = g

Your result seems right and mine wrong.

Isn't this a feature of glibc rather than gcc ?

Yes. More precisely, it's a feature of whatever C library you happen
to be using. (gcc is commonly used with libraries other than glibc.)

<OT>
There's no gcc 3.41, at least not yet; the latest release is 3.4.1.
</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.