difference between scanf("%i") and scanf("%d") ??? perhaps bug inVS2005?

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Hi,

Today I got a really strange problem... I've made myself a data-file and
I read in data from that file....

When I read something like this line:

03 04 05, 00 04 01, 05 03 07, 08 03 00, 09 06 03 ... etc.

with something like scanf("%i %i %i, ", &var1, &var2, &var3);

then it stopped reading data starting with "08", "09" etc... But
everything such as "07" and below worked...

Then I tried scanf("%d %d %d, ", &var1, &var2, &var3);

And the program WORKED!?!!?

Why?

I looked in my C-book and it says absolutetly the same about using %i as
%d.... I'm too tired to cut down my progrm and post a small version of
it now, and it might be that's even unnecessary because somebody know
what's happening...

Compiler: Visual studio 2005, windows xp. I suspect perhaps it's a bug,
if my C book is right that there isn't any difference between %i and %d?


Best regards / Med venlig hilsen
Martin Jørgensen

 

[P.J. Plauger]

Today I got a really strange problem... I've made myself a data-file and I
read in data from that file....

When I read something like this line:

03 04 05, 00 04 01, 05 03 07, 08 03 00, 09 06 03 ... etc.

with something like scanf("%i %i %i, ", &var1, &var2, &var3);

then it stopped reading data starting with "08", "09" etc... But
everything such as "07" and below worked...

Then I tried scanf("%d %d %d, ", &var1, &var2, &var3);

And the program WORKED!?!!?

Why?

I looked in my C-book and it says absolutetly the same about using %i as
%d.... I'm too tired to cut down my progrm and post a small version of it
now, and it might be that's even unnecessary because somebody know what's
happening...

Compiler: Visual studio 2005, windows xp. I suspect perhaps it's a bug, if
my C book is right that there isn't any difference between %i and %d?

%d effectively calls strtol with a base of 10, so it assumes all numbers
it reads are decimal. %d effectively calls strtol with a base of 0, so it
adapts the base according to any prefix (0, 0x, or 0X) it sees. Thus 08
is an ill formed octal integer.

HTH,

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Ben C]

Hi,

Today I got a really strange problem... I've made myself a data-file and
I read in data from that file....

When I read something like this line:

03 04 05, 00 04 01, 05 03 07, 08 03 00, 09 06 03 ... etc.

with something like scanf("%i %i %i, ", &var1, &var2, &var3);

then it stopped reading data starting with "08", "09" etc... But
everything such as "07" and below worked...

Then I tried scanf("%d %d %d, ", &var1, &var2, &var3);

And the program WORKED!?!!?

Why?

Maybe it's something to do with octal? A leading 0 is sometimes used for
octal (in C for example) 01 .. 07 are valid octal, 08 isn't.

 

[Robert Gamble]

%d effectively calls strtol with a base of 10, so it assumes all numbers
it reads are decimal. %d effectively calls strtol with a base of 0, so it
adapts the base according to any prefix (0, 0x, or 0X) it sees. Thus 08
is an ill formed octal integer.

Your second %d should be a %i.

Robert Gamble

 

[Keith Thompson]

Today I got a really strange problem... I've made myself a data-file and I
read in data from that file....

When I read something like this line:

03 04 05, 00 04 01, 05 03 07, 08 03 00, 09 06 03 ... etc.

with something like scanf("%i %i %i, ", &var1, &var2, &var3);

then it stopped reading data starting with "08", "09" etc... But
everything such as "07" and below worked...

Then I tried scanf("%d %d %d, ", &var1, &var2, &var3);

And the program WORKED!?!!?

[snip

%d effectively calls strtol with a base of 10, so it assumes all numbers
it reads are decimal. %d effectively calls strtol with a base of 0, so it
adapts the base according to any prefix (0, 0x, or 0X) it sees. Thus 08
is an ill formed octal integer.

And with %d, "010" has the value 8, not 10.

Decide whether you want numbers with leading '0' to be treated as
octal or decimal.

 

[Robert Gamble]

Today I got a really strange problem... I've made myself a data-file and I
read in data from that file....

When I read something like this line:

03 04 05, 00 04 01, 05 03 07, 08 03 00, 09 06 03 ... etc.

with something like scanf("%i %i %i, ", &var1, &var2, &var3);

then it stopped reading data starting with "08", "09" etc... But
everything such as "07" and below worked...

Then I tried scanf("%d %d %d, ", &var1, &var2, &var3);

And the program WORKED!?!!?

[snip

%d effectively calls strtol with a base of 10, so it assumes all numbers
it reads are decimal. %d effectively calls strtol with a base of 0, so it
adapts the base according to any prefix (0, 0x, or 0X) it sees. Thus 08
is an ill formed octal integer.

And with %d, "010" has the value 8, not 10.

No, with %d, "010" has the value 10. With %i, "010" has the value 8.

Decide whether you want numbers with leading '0' to be treated as
octal or decimal.

Robert Gamble

 

[Ben Pfaff]

When I read something like this line:

03 04 05, 00 04 01, 05 03 07, 08 03 00, 09 06 03 ... etc.

with something like scanf("%i %i %i, ", &var1, &var2, &var3);

then it stopped reading data starting with "08", "09" etc... But
everything such as "07" and below worked...

Then I tried scanf("%d %d %d, ", &var1, &var2, &var3);

%d reads a decimal integer.
%i reads a C-like integer, so that a leading 0 means "octal".
Your reference manual should have told you this.

 

[Keith Thompson]

No, with %d, "010" has the value 10. With %i, "010" has the value 8.

Whoops! You're right, of course. Thanks for catching my error.

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

%d reads a decimal integer.
%i reads a C-like integer, so that a leading 0 means "octal".
Your reference manual should have told you this.

Now I double-checked my book: "C primer plus, 5th edition".

It simply *doesn't* tell this... What a piece of junk...


It says (table 4.6, p.117):

%d = interpret input as a signed decimal integer
.. . .
%i = interpret input as a signed decimal integer
%o = interpret input as a signed octal integer
%x = interpret input as a signed hexadecimal integer


So the above is wrong?

And what are %o and %x for if you can do exactly the same with %0i and
probably %x-something? ? ?



Best regards / Med venlig hilsen
Martin Jørgensen

 

[John Bode]

Now I double-checked my book: "C primer plus, 5th edition".

It simply *doesn't* tell this... What a piece of junk...


It says (table 4.6, p.117):

%d = interpret input as a signed decimal integer
. . .
%i = interpret input as a signed decimal integer

%i will interpret the input as either a signed decimal, octal, or
hexadecimal integer based on the input format.

If the input has a leading 0, it will attempt to interpret it as an
octal value, and if the input has a leading 0x, it will attempt to
interpret it as a hexadecimal value.

Time for a new reference manual, I think. I use Harbison & Steele's
"C: A Reference Manual", currently at 5th edition.

%o = interpret input as a signed octal integer
%x = interpret input as a signed hexadecimal integer


So the above is wrong?

And what are %o and %x for if you can do exactly the same with %0i and
probably %x-something? ? ?

%i is useful when you don't necessarily know ahead of time if your
input is going to be formatted as decimal, octal, or hex, and you want
to be able to handle it correctly. You'd use %d, %o, and %x when you
know the input is always supposed to be formatted in one particular way
(i.e., you're *only* reading hex-formatted input).

 

[Keith Thompson]

Now I double-checked my book: "C primer plus, 5th edition".

It simply *doesn't* tell this... What a piece of junk...


It says (table 4.6, p.117):

%d = interpret input as a signed decimal integer
. . .
%i = interpret input as a signed decimal integer
%o = interpret input as a signed octal integer
%x = interpret input as a signed hexadecimal integer


So the above is wrong?

Yes.

John Bode recommended Harbison&Steele, _C: A Reference Manual_, 5th
Edition; so do I, it's excellent. You *might* consider the standard
itself (the most recent draft is n1124.pdf); it's definitely not for
beginners, but with some effort it can answer these questions for you.

And what are %o and %x for if you can do exactly the same with %0i and
probably %x-something? ? ?

scanf() reads integer literals with the same syntax used by strtoul();
the use of %d vs %i vs %o vs %x changes the base.

For "%d", the input is assumed to be decimal. A "0x" or "0X" prefix
is not allowed, and a leading 0 doesn't make the number octal.
(Actually, if you have a leading "0x" or "0X", it just reads the "0",
and the "x" or "X" and everything following it is left in the input
stream.)

For "%i", the input looks like an integer literal in a C program (with
an optional sign). A leading "0" makes it octal, and a leading "0x"
or "0X" makes it hexadecimal. "123" yields 123, "0123" yields 83, and
"0x123" yields 291. Use this only if you expect the input to use a
leading "0", "0x", or "0X" to indicate the base. If you're getting
interactive input from a user, this probably isn't what you want
(unless you expect the user to be familiar with C syntax).

For "%o", the input is assumed to be octal, even if it doesn't have a
leading "0". For example, either "123" or "0123" yields the integer
value 83. A leading "0x" or "0X" is not allowed (sort of; see above).

For "%x", the input is assumed to be hexadecimal. A leading "0x" or
"0X" is allowed, but ignored. For example, either "123", "0x123", or
"0123" yields the integer value 291.

 

[regis]

scanf() reads integer literals with the same syntax used by strtoul();
the use of %d vs %i vs %o vs %x changes the base.
[...]

For "%o", the input is assumed to be octal, even if it doesn't have a
leading "0". For example, either "123" or "0123" yields the integer
value 83. A leading "0x" or "0X" is not allowed (sort of; see above).

For "%x", the input is assumed to be hexadecimal. A leading "0x" or
"0X" is allowed, but ignored. For example, either "123", "0x123", or
"0123" yields the integer value 291.

I found this in N869:
o,u,x are stated to all match optionally signed integers
but expect arguments as pointers to unsigned integers.
This seems rather inconsistent.
A contrario, my man pages state that o,u,x match unsigned integers
and also expect arguments as unsigned integers.

Is it a "cut and paste" typo in N869 ?

From page 322, section 7.19.6.2 The fscanf function:

o Matches an optionally signed octal integer, whose
format is the same as expected for the subject
sequence of the strtoul function with the value 8
for the base argument. The corresponding argument
shall be a pointer to unsigned integer.

u Matches an optionally signed decimal integer, whose
format is the same as expected for the subject
sequence of the strtoul function with the value 10
for the base argument. The corresponding argument
shall be a pointer to unsigned integer.

x Matches an optionally signed hexadecimal integer,
whose format is the same as expected for the subject
sequence of the strtoul function with the value 16
for the base argument. The corresponding argument
shall be a pointer to unsigned integer.

 

[Keith Thompson]

scanf() reads integer literals with the same syntax used by strtoul();
the use of %d vs %i vs %o vs %x changes the base.
[...]

For "%o", the input is assumed to be octal, even if it doesn't have a
leading "0". For example, either "123" or "0123" yields the integer
value 83. A leading "0x" or "0X" is not allowed (sort of; see above).
For "%x", the input is assumed to be hexadecimal. A leading "0x" or
"0X" is allowed, but ignored. For example, either "123", "0x123", or
"0123" yields the integer value 291.

I found this in N869:
o,u,x are stated to all match optionally signed integers
but expect arguments as pointers to unsigned integers.
This seems rather inconsistent.
A contrario, my man pages state that o,u,x match unsigned integers
and also expect arguments as unsigned integers.

[...]

It's not really inconsistent. The phrase "optionally signed" refers
to the optional '+' or '-' character preceding the integer literal in
the input. This needs to be specified because, in a C program, "-1"
isn't an integer literal; it's a unary "-" operator followed by a
literal "1". If there's a '-', the result is negated (which is well
defined for both signed and unsigned types).

For example, this:

#include <stdio.h>
int main(void)
{
char *s = "-1";
unsigned int x;
int count;

count = sscanf(s, "%o", &x);
printf("count = %d, x = %u\n", count, x);

return 0;
}

prints this:

count = 1, x = 4294967295

where 4294967295 is UINT_MAX on the system where I ran it.

Here's what N1124 says about 'u':

Matches an optionally signed decimal integer, whose format is the
same as expected for the subject sequence of the strtoul function
with the value 10 for the base argument. The corresponding
argument shall be a pointer to unsigned integer.

The wording is similar for 'o' and 'x'.

 

[regis]

It's not really inconsistent. The phrase "optionally signed" refers
to the optional '+' or '-' character preceding the integer literal in
the input. This needs to be specified because, in a C program, "-1"
isn't an integer literal; it's a unary "-" operator followed by a
literal "1". If there's a '-', the result is negated (which is well
defined for both signed and unsigned types).

Ok, now I understand.
Thank you for your explanations.

( I find both the wording of N869 and the wording of the man pages
misleading on this subject.

Also, as far as *text* representation of unsigned integers
are concerned, I wonder if accepting negatives representations
of unsigned integers as input at the sight of format "%u"
is a desirable feature. IMHO, since input functions are
the interface with the user, it have been more useful if
such negatives representations made the conversion fail, and only
canonical positive representations made the conversion succeed. )

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Yes.

John Bode recommended Harbison&Steele, _C: A Reference Manual_, 5th
Edition; so do I, it's excellent. You *might* consider the standard
itself (the most recent draft is n1124.pdf); it's definitely not for
beginners, but with some effort it can answer these questions for you.




scanf() reads integer literals with the same syntax used by strtoul();
the use of %d vs %i vs %o vs %x changes the base.

For "%d", the input is assumed to be decimal. A "0x" or "0X" prefix
is not allowed, and a leading 0 doesn't make the number octal.
(Actually, if you have a leading "0x" or "0X", it just reads the "0",
and the "x" or "X" and everything following it is left in the input
stream.)

For "%i", the input looks like an integer literal in a C program (with
an optional sign). A leading "0" makes it octal, and a leading "0x"
or "0X" makes it hexadecimal. "123" yields 123, "0123" yields 83, and
"0x123" yields 291. Use this only if you expect the input to use a
leading "0", "0x", or "0X" to indicate the base. If you're getting
interactive input from a user, this probably isn't what you want
(unless you expect the user to be familiar with C syntax).

For "%o", the input is assumed to be octal, even if it doesn't have a
leading "0". For example, either "123" or "0123" yields the integer
value 83. A leading "0x" or "0X" is not allowed (sort of; see above).

For "%x", the input is assumed to be hexadecimal. A leading "0x" or
"0X" is allowed, but ignored. For example, either "123", "0x123", or
"0123" yields the integer value 291.

Thanks a lot.


Best regards / Med venlig hilsen
Martin Jørgensen

 

[P.J. Plauger]

Ok, now I understand.
Thank you for your explanations.

( I find both the wording of N869 and the wording of the man pages
misleading on this subject.

Also, as far as *text* representation of unsigned integers
are concerned, I wonder if accepting negatives representations
of unsigned integers as input at the sight of format "%u"
is a desirable feature. IMHO, since input functions are
the interface with the user, it have been more useful if
such negatives representations made the conversion fail, and only
canonical positive representations made the conversion succeed. )

Negating an unsigned integer is well defined. Some of us find it
useful. In recent years compilers have taken to issuing warnings
about this operation on the assumption that some programmers will
be surprised that the result of any negation is still non-negative.
(I like the ones that complain about -x yet quietly accept 0-x.
Go figure.) But that don't make it wrong.

I, for one, think -1 is a great shorthand for the largest
representable unsigned value. You don't get tired of writing 'f's,
and you don't have to know how many to write.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[regis]

Negating an unsigned integer is well defined. Some of us find it
useful. In recent years compilers have taken to issuing warnings
about this operation on the assumption that some programmers will
be surprised that the result of any negation is still non-negative.
(I like the ones that complain about -x yet quietly accept 0-x.
Go figure.) But that don't make it wrong.

I, for one, think -1 is a great shorthand for the largest
representable unsigned value. You don't get tired of writing 'f's,
and you don't have to know how many to write.

Sure. On the programmer side, it is useful:

size_t k, n= strlen (text);
for (k= n-1; k != (size_t)-1; k--) { ... }

My remark was about *text* representations that the user deals with:

int i; scanf ("%i", & i);
The user types "1", he gets 1.
The user types "-1", he gets -1.

unsigned u; scanf ("%u", & u);
The user types "1", he gets 1.
The user types "-1", he gets something that might be different
on different machines...

 

[Keith Thompson]

My remark was about *text* representations that the user deals with:

int i; scanf ("%i", & i);
The user types "1", he gets 1.
The user types "-1", he gets -1.

unsigned u; scanf ("%u", & u);
The user types "1", he gets 1.
The user types "-1", he gets something that might be different
on different machines...

One solution to this might be to add a syntax that specifies that a
leading sign is not allowed. For example, with scanf("%u", &u), if
the user enters "-1", UINT_MAX is stored in u. With scanf("%+u", &u),
"-1" would be invalid (though "+1" might be ok).

In the absence of such a language change, if you read the line into a
string to be processed with sscanf() (which is the recommended
practice anyway), you can check for a sign character before calling
sscanf().

 

[Richard Bos]

Sure. On the programmer side, it is useful:

size_t k, n= strlen (text);
for (k= n-1; k != (size_t)-1; k--) { ... }

My remark was about *text* representations that the user deals with:

int i; scanf ("%i", & i);
The user types "1", he gets 1.
The user types "-1", he gets -1.

unsigned u; scanf ("%u", & u);
The user types "1", he gets 1.
The user types "-1", he gets something that might be different
on different machines...

Then again, it is dubitable whether using scanf() itself for user input
is a good idea.

Richard