Problem: scanf used for double

[Frank Chow]

Please see the following code:

/* main.c */

#include <stdio.h>

int main()
{
double d;
scanf("%f", &d);
printf("%g\n", d);
}

The problem is, whatever I input to stdin (even an illegal data), the
program just print a number that seems to be a data from "raw memory",
ie uninitialized memory (for example: "5.35162e-315").

And if I replace the statement "double d" with "double d = 3.14", then
I'll always get the output "3.14" for whatever I input (even an
illegal data).

Then I may get the conclusion that the "scanf" statement never does
its job. And I have tried this under 3 compilers and none of them give
the right result.

Please give me some explanation about this.

Thanks.

 

[Eric Sosman]

Please see the following code:

/* main.c */

#include <stdio.h>

int main()
{
double d;
scanf("%f", &d);

scanf("%lf", &d)

See Question 12.13 in the comp.lang.c Frequently Asked
Questions (FAQ) list

http://www.eskimo.com/~scs/C-faq/top.html

 

[Christopher Benson-Manica]

#include <stdio.h>

int main()
{
double d;
scanf("%f", &d);
printf("%g\n", d);
}

If you had your compiler warnings turned on, you probably would have gotten
something like

test.c:6: warning: float format, double arg (arg 2)

The correct conversion specifier for doubles is %lf when using scanf. Also,
should return a value from main, a la

return( EXIT_SUCCESS );

 

[Irrwahn Grausewitz]

Also,
should return a value from main, a la

return( EXIT_SUCCESS );

after inclusion of stdlib.h, of course; alternatively

return 0;

is fine, too.

 

[Dan Pop]

Please see the following code:

/* main.c */

#include <stdio.h>

int main()
{
double d;
scanf("%f", &d);
printf("%g\n", d);
}

The problem is, whatever I input to stdin (even an illegal data), the
program just print a number that seems to be a data from "raw memory",
ie uninitialized memory (for example: "5.35162e-315").

Where did you get the idea that %f is the right conversion specifier for
a double? If you needed a float instead, what would you use?

For obvious reasons, scanf is not a perfect mirror of printf.

Dan

 

[Christopher Benson-Manica]

return 0;
is fine, too.

I thought it was non-portable

 

[Irrwahn Grausewitz]

I thought it was non-portable

Nope, according to ISO/IEC 9899:1999 5.1.2.2.3 and 7.20.4.3#5
it is perfectly portable.

Regards

 

[Glen Herrmannsfeldt]

Please see the following code:

/* main.c */

#include <stdio.h>

int main()
{
double d;
scanf("%f", &d);
printf("%g\n", d);
}

The problem is, whatever I input to stdin (even an illegal data), the
program just print a number that seems to be a data from "raw memory",
ie uninitialized memory (for example: "5.35162e-315").

Others have said that %f is wrong for double, which is true.

Note that if scanf() doesn't find valid data to convert to a number it
doesn't store anything. Also, it returns the number of valid conversions,
which you can check.

-- glen

 

[Martin Ambuhl]

Please see the following code:

/* main.c */

#include <stdio.h>

int main()
{
double d;
scanf("%f", &d);

You mean scanf("%lf", &d);

 

[Frank Chow]

Thank you all. And indeed I should first read the C-faq to avoid such
a naive mistake.

 

[Christopher Benson-Manica]

Nope, according to ISO/IEC 9899:1999 5.1.2.2.3 and 7.20.4.3#5
it is perfectly portable.

<dumb>So if 0 is portable, why the EXIT_SUCCESS macro?</dumb>

 

[Irrwahn Grausewitz]

<dumb>So if 0 is portable, why the EXIT_SUCCESS macro?</dumb>

Because it's more descriptive and has a portable(!) and descriptive
counter-part, EXIT_FAILURE.

ISO/IEC 9899:1999 7.20.4.3
5 [...] If the value of status is zero or EXIT_SUCCESS, an
implementation-defined form of the status successful termination is
returned. If the value of status is EXIT_FAILURE, an implementation-
defined form of the status unsuccessful termination is returned.
Otherwise the status returned is implementation-defined.

Regards

 

[Christopher Benson-Manica]

Because it's more descriptive and has a portable(!) and descriptive
counter-part, EXIT_FAILURE.

So it's kind of like the unary + thing, symmetry and all? I dunno, I always
thought the l337-ness of C code was directly related to how obfuscated it
looked

 

[Irrwahn Grausewitz]

So it's kind of like the unary + thing, symmetry and all?

Hm, well, yes and no. I can remember a discussion about this in c.l.c
or c.s.c, where the claim was made that in the context of program exit
codes 0 may describe a kind of successful termination different from
what EXIT_SUCCESS results in. Whatever that means, practically.

I dunno, I always
thought the l337-ness of C code was directly related to how obfuscated it
looked

Regards

 

[Dan Pop]

So it's kind of like the unary + thing, symmetry and all?

Exactly.

Dan

 

[Dan Pop]

Hm, well, yes and no. I can remember a discussion about this in c.l.c
or c.s.c, where the claim was made that in the context of program exit
codes 0 may describe a kind of successful termination different from
what EXIT_SUCCESS results in. Whatever that means, practically.

Nothing at all, in the context of portable programming. Furthermore, the
most natural interpretation of the standard is that both are mapped to
the *same* form of successful termination.

5 Finally, control is returned to the host environment. If the
value of status is zero or EXIT_SUCCESS, an implementation-defined
^^
form of the status successful termination is returned.

The standard talks about a *single* "implementation-defined form of
the status successful termination".

Dan

 

[Irrwahn Grausewitz]

Nothing at all, in the context of portable programming. Furthermore, the
most natural interpretation of the standard is that both are mapped to
the *same* form of successful termination.

5 Finally, control is returned to the host environment. If the
value of status is zero or EXIT_SUCCESS, an implementation-defined
^^
form of the status successful termination is returned.

The standard talks about a *single* "implementation-defined form of
the status successful termination".

It's the most natural interpretation, I agree. I just remembered the
discussion, not the outcome...