printf("%d",float)

[candy_init]

Hi all,
I just came across the following program:

#include <stdio.h>
int main()
{
float a = 12.5;
printf("%d\n", a);
printf("%d\n", *(int *)&a);
return 0;
}

The program prints 0 and 1095237362. However, in my opinion it should
print 12 at both the places. Can anybody tell me where I am wrong?

[Richard Heathfield]

ca********@yahoo.com said:

Hi all,
I just came across the following program:

#include <stdio.h>
int main()
{
float a = 12.5;
printf("%d\n", a);
printf("%d\n", *(int *)&a);
return 0;
}

The program prints 0 and 1095237362. However, in my opinion it should
print 12 at both the places. Can anybody tell me where I am wrong?

You are wrong in thinking that %d is the appropriate format specifier for a
float, and you are wrong in thinking that you can meaningfully cast the
address of a float into the address of an int.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[santosh]

ca********@yahoo.com wrote:

Hi all,
I just came across the following program:

#include <stdio.h>
int main()
{
float a = 12.5;
printf("%d\n", a);

printf expects and treats the corresponding argument as a signed int,
while you've passed it a float value.

printf("%d\n", *(int *)&a);

Same as above and an additional problem:

Pointers values of different types need not be compatible in C, except
that a conversion of any pointer to void * and back again shall be
okay.

return 0;
}

The program prints 0 and 1095237362. However, in my opinion it should
print 12 at both the places. Can anybody tell me where I am wrong?

Yes. You've written an incorrect program, so incorrect results are to be
expected.

Read:

<http://www.c-faq.com/>

[andreyvul]

On Oct 30, 8:48 pm, [e-mail] wrote:

Hi all,
I just came across the following program:

#include <stdio.h>
int main()
{
float a = 12.5;
printf("%d\n", a);
printf("%d\n", *(int *)&a);
return 0;
}

The program prints 0 and 1095237362. However, in my opinion it should
print 12 at both the places. Can anybody tell me where I am wrong?

Pointer casting does not convert values of one type to another. Your
code is sort of like this:
struct {
char a;
} A ;
struct {
float b;
} B;
printf("%c", ((A*)&B)->a);
OR
printf("%f", ((B*)&A)->a);
The latter will segfault/crash.
If sizeof(int) != sizeof(float) your code would have *very* likely
crashed. This is one of the reasons why you should be *very* careful
with pointers and never do anything fancy when working with pointers
UNLESS YOU COMPLETELY KNOW WHAT IT DOES, WHY IT DOES THAT, AND ANY
SIDE-EFFECTS. Be very careful, *especially* when you need to pass
void* arguments and struct-cast the pointer to get the data.

Getting back to the different number,
float = [sign bit] [7 exponent bits] [23 mantissa bits]
12.5 = 0 10000010 10010000000000000000000
= 0x41480000
= 1095237632
That's where your number came from.
Source: http://en.wikipedia.org/wiki/Single_precision

[ming li]

On 10 31 , 8 48 , [e-mail] wrote:

Hi all,
I just came across the following program:

#include <stdio.h>
int main()
{
float a = 12.5;
printf("%d\n", a);
printf("%d\n", *(int *)&a);
return 0;
}

The program prints 0 and 1095237362. However, in my opinion it should
print 12 at both the places. Can anybody tell me where I am wrong?

hi, I help this test program will help you!

#include <stdarg.h>
#include <stdio.h>

// printf's action is like this
void test(char *fmt, ...)
{
int i;
float j;

va_list ap, app;

va_start(ap, fmt);
app = ap;

i = va_arg(ap, int); // when you call like printf("%d\n", i);
this line while be called

j = va_arg(app, double); // when you call like printf("%f\n", i);
this line while be called
// and you can't call it like j = va_arg(app,
float), because gcc compiler will complain

va_end(ap);

printf("if the args interpret as int, you get %d\n", i);
printf("it should interpret as double, the right answer is %f\n",
j);
}

int main(void)
{
float a = 12.5;

test("%d", a);

return 0;
}
below is define of va_arg, you can find it in <stdarg.h>

typedef char * va_list;

#define va_start _crt_va_start
+-- #define va_arg _crt_va_arg
| #define va_end _crt_va_end
|
| #define _crt_va_start(ap,v) ( ap = (va_list)_ADDRESSOF(v) +
_INTSIZEOF(v) )
+-#define _crt_va_arg(ap,t) ( *(t *)((ap += _INTSIZEOF(t)) -
_INTSIZEOF(t)) )
#define _crt_va_end(ap) ( ap = (va_list)0 )

[Keith Thompson]

santosh <sa*********@gmail.comwrites:

ca********@yahoo.com wrote:

>I just came across the following program:

#include <stdio.h>
int main()
{
float a = 12.5;
printf("%d\n", a);

printf expects and treats the corresponding argument as a signed int,
while you've passed it a float value.

> printf("%d\n", *(int *)&a);

Same as above and an additional problem:

[...]

Not quite. The argument is of type int, so "%d" is the correct
format. The problem, of course, is that obtaining the value of that
argument (evaluating ``*(int *)&a'') invokes undefined behavior.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Jack Klein]

On Wed, 31 Oct 2007 01:15:33 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote in comp.lang.c:

ca********@yahoo.com said:

Hi all,
I just came across the following program:

#include <stdio.h>
int main()
{
float a = 12.5;
printf("%d\n", a);
printf("%d\n", *(int *)&a);
return 0;
}

The program prints 0 and 1095237362. However, in my opinion it should
print 12 at both the places. Can anybody tell me where I am wrong?

You are wrong in thinking that %d is the appropriate format specifier for a
float, and you are wrong in thinking that you can meaningfully cast the
address of a float into the address of an int.

You were right in the first pronouncement, not necessarily so in the
second. The result of casting a pointer to an object or incomplete to
a pointer to any other object or incomplete type, is undefined if the
pointer is not suitably aligned for the second type, but well defined
if there is no alignment error. Of course, dereferencing that pointer
is completely undefined.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Richard Heathfield]

Jack Klein said:

On Wed, 31 Oct 2007 01:15:33 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote in comp.lang.c:

<snip>

>>
You are wrong in thinking that %d is the appropriate format specifier
for a float, and you are wrong in thinking that you can meaningfully
cast the address of a float into the address of an int.

You were right in the first pronouncement, not necessarily so in the
second. The result of casting a pointer to an object or incomplete to
a pointer to any other object or incomplete type, is undefined if the
pointer is not suitably aligned for the second type, but well defined
if there is no alignment error. Of course, dereferencing that pointer
is completely undefined.

Right, which is why I consider the conversion meaningless.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Peter Nilsson]

andreyvul <[e-mail]:

Pointer casting does not convert values of one type
to another.

Yes it does. Indeed, all conversions do precisely that.
Casting a pointer from one type to another converts the
pointer value from the original pointer type to a pointer
value of the cast type. Only certain conversions (and
chains thereof) are guaranteed to be lossless.

What you meant to say is that converting pointers does
not convert the value of the object being pointed to,
if any.

--
Peter

[Philip Potter]

Richard Heathfield wrote:

Jack Klein said:

>On Wed, 31 Oct 2007 01:15:33 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote in comp.lang.c:

<snip>

>>You are wrong in thinking that %d is the appropriate format specifier
for a float, and you are wrong in thinking that you can meaningfully
cast the address of a float into the address of an int.

You were right in the first pronouncement, not necessarily so in the
second. The result of casting a pointer to an object or incomplete to
a pointer to any other object or incomplete type, is undefined if the
pointer is not suitably aligned for the second type, but well defined
if there is no alignment error. Of course, dereferencing that pointer
is completely undefined.

Right, which is why I consider the conversion meaningless.

So conversion to void * is always meaningless, because no void * can be
dereferenced?

Phil

--
Philip Potter pgp <atdoc.ic.ac.uk

[Philip Potter]

ca********@yahoo.com wrote:

Hi all,
I just came across the following program:

#include <stdio.h>
int main()
{
float a = 12.5;
printf("%d\n", a);

This line is wrong because printf() expects an int but a is a float.
Note that because this is undefined behaviour (UB), this may cause a
crash on some C compilers - and even worse behaviour on others.

<OT>
To think about one reason this may crash on a machine with a stack, if
sizeof(float) != sizeof(int) then printf() will remove the wrong number
of bytes from the call stack, leaving the stack in an inconsistent state
after the call to printf().

A C compiler doesn't /need/ a reason like this to fail, however; if the
behaviour is undefined, it can do anything it likes for no reason at all.
</OT>

printf("%d\n", *(int *)&a);

I'm curious. Why did you write this instead of the correct (and simpler):

printf("%d\n", (int)a);

This converts the float value to an int value.

Your version takes the address of a to produce a 'float *', converts
that pointer to an 'int *', and dereferences that pointer. Converting a
float pointer to an int pointer isn't very meaningful.

--
Philip Potter pgp <atdoc.ic.ac.uk

[Richard Heathfield]

Philip Potter said:

Richard Heathfield wrote:

>Jack Klein said:

<snip>

>>Of course, dereferencing that pointer
is completely undefined.

Right, which is why I consider the conversion meaningless.

So conversion to void * is always meaningless, because no void * can be
dereferenced?

Um, er... :-)

Okay, so that's an exception. But I think that, in general terms, it's
still a reasonable rule of thumb.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ernie Wright]

ca********@yahoo.com wrote:

Hi all,
I just came across the following program:

#include <stdio.h>
int main()
{
float a = 12.5;
printf("%d\n", a);
printf("%d\n", *(int *)&a);
return 0;
}

The program prints 0 and 1095237362. However, in my opinion it should
print 12 at both the places. Can anybody tell me where I am wrong?

As others have said, or tried to say, using the "%d" format specifier in
printf() does not convert the value of (a) to an int, and casting the
pointer &a to an int * does not change the value stored there into an
int. In both cases, what (usually) happens is that the bit pattern is
interpreted as an int. In other words, instead of *translating* to an
int, these cases merely point to the bit pattern of a float and *say*
that it's an int.

To convert the value of (a), you'd use something like

printf( "%d\n", ( int ) a );

This explicitly tells the compiler that you want printf() to see the int
value 12, rather than the floating-point value 12.5, and the compiler
therefore inserts code to change the bit pattern accordingly, before
printf() interprets it.

The C standard can't tell you why you got the specific values you did,
since they depend on your implementation. But we can make some pretty
safe inferences, and this might help you understand what happened.

Based on your numbers, your implementation is little-endian, it has
4-byte ints and floats and 8-byte doubles, and it uses IEEE floating-
point representation. Windows is the most common environment where
these conditions are true.

In the first case,

printf("%d\n", a);

(a) is promoted to a double, and printf() therefore receives the 8 bytes

00 00 00 00 00 00 29 40

When printf() encounters the "%d" format specifier, it looks at the next
four bytes in the argument list, because it's expecting an int to be
there. It sees 00 00 00 00, and prints "0".

In the second case,

printf("%d\n", *(int *)&a);

printf() receives the integer corresponding to the four bytes at the
address &a, which are

00 00 48 41

When interpreted as a little-endian 4-byte IEEE float, these bytes
represent the value 12.5. But when interpreted as a 4-byte int, they
represent the value you saw, 1095237632 decimal or 41480000 hex.

- Ernie http://home.comcast.net/~erniew

[andreyvul]

On Oct 31, 3:39 am, Peter Nilsson <[e-mail]:

andreyvul <[e-mail]:

Pointer casting does not convert values of one type
to another.

Yes it does. Indeed, all conversions do precisely that.
Casting a pointer from one type to another converts the
pointer value from the original pointer type to a pointer
value of the cast type. Only certain conversions (and
chains thereof) are guaranteed to be lossless.

What you meant to say is that converting pointers does
not convert the value of the object being pointed to,
if any.

--
Peter

You fixed my grammar typo. What I meant was *ptr being unconverted,
not ptr itself.

[vipvipvipvipvip.ru]

#include <stdio.h>
int main(void) {
float pi = 3.1415f;
printf("%d\n", (int)pi);
return 0;
}

simple

[andreyvul]

from c++ faq, section 27:
[27.11] Why do people worry so much about pointer casts and/or
reference casts?

Because they're evil! (Which means you should use them sparingly and
with great care.)

For some reason, programmers are sloppy in their use of pointer casts.
They cast this to that all over the place, then they wonder why things
don't quite work right. Here's the worst thing: when the compiler
gives them an error message, they add a cast to "shut the compiler
up," then they "test it" to see if it seems to work. If you have a lot
of pointer casts or reference casts, read on.

The compiler will often be silent when you're doing pointer-casts and/
or reference casts. Pointer-casts (and reference-casts) tend to shut
the compiler up. I think of them as a filter on error messages: the
compiler wants to complain because it sees you're doing something
stupid, but it also sees that it's not allowed to complain due to your
pointer-cast, so it drops the error message into the bit-bucket. It's
like putting duct tape on the compiler's mouth: it's trying to tell
you something important, but you've intentionally shut it up.

A pointer-cast says to the compiler, "Stop thinking and start
generating code; I'm smart, you're dumb; I'm big, you're little; I
know what I'm doing so just pretend this is assembly language and
generate the code." The compiler pretty much blindly generates code
when you start casting - you are taking control (and responsibility!)
for the outcome. The compiler and the language reduce (and in some
cases eliminate!) the guarantees you get as to what will happen.
You're on your own.

By way of analogy, even if it's legal to juggle chainsaws, it's
stupid. If something goes wrong, don't bother complaining to the
chainsaw manufacturer - you did something they didn't guarantee would
work. You're on your own.

(To be completely fair, the language does give you some guarantees
when you cast, at least in a limited subset of casts. For example,
it's guaranteed to work as you'd expect if the cast happens to be from
an object-pointer (a pointer to a piece of data, as opposed to a
pointer-to-function or pointer-to-member) to type void* and back to
the same type of object-pointer. But in a lot of cases you're on your
own.)

[pete]

andreyvul wrote:

>
from c++ faq, section 27:
[27.11] Why do people worry so much about pointer casts and/or
reference casts?

Because they're evil! (Which means you should use them sparingly and
with great care.)

For some reason, programmers are sloppy in their use of pointer casts.
They cast this to that all over the place, then they wonder why things
don't quite work right. Here's the worst thing: when the compiler
gives them an error message, they add a cast to "shut the compiler
up," then they "test it" to see if it seems to work. If you have a lot
of pointer casts or reference casts, read on.

The compiler will often be silent when you're doing pointer-casts and/
or reference casts. Pointer-casts (and reference-casts) tend to shut
the compiler up. I think of them as a filter on error messages: the
compiler wants to complain because it sees you're doing something
stupid, but it also sees that it's not allowed to complain due to your
pointer-cast, so it drops the error message into the bit-bucket. It's
like putting duct tape on the compiler's mouth: it's trying to tell
you something important, but you've intentionally shut it up.

A pointer-cast says to the compiler, "Stop thinking and start
generating code; I'm smart, you're dumb; I'm big, you're little; I
know what I'm doing so just pretend this is assembly language and
generate the code." The compiler pretty much blindly generates code
when you start casting - you are taking control (and responsibility!)
for the outcome. The compiler and the language reduce (and in some
cases eliminate!) the guarantees you get as to what will happen.
You're on your own.

By way of analogy, even if it's legal to juggle chainsaws, it's
stupid. If something goes wrong, don't bother complaining to the
chainsaw manufacturer - you did something they didn't guarantee would
work. You're on your own.

(To be completely fair, the language does give you some guarantees
when you cast, at least in a limited subset of casts. For example,
it's guaranteed to work as you'd expect if the cast happens to be from
an object-pointer (a pointer to a piece of data, as opposed to a
pointer-to-function or pointer-to-member) to type void* and back to
the same type of object-pointer.

That's true, but a cast to type (void*)
is hardly ever applied to an object pointer in C.
An object pointer value can be assigned
to a (void*) object without a cast.

Casting an object pointer to type (char*) on the other hand,
gets you the address of the lowest addressable byte of the object.

But in a lot of cases you're on your own.)

--
pete

[vipvipvipvipvip.ru]

On Nov 1, 2:22 am, pete <[e-mail]:

That's true, but a cast to type (void*)
is hardly ever applied to an object pointer in C.
An object pointer value can be assigned
to a (void*) object without a cast.

Casting an object pointer to type (char*) on the other hand,
gets you the address of the lowest addressable byte of the object.

In value context, yes. In size context, no.

char *p;
char *s = (char*)(void*)p;

Consider the case where char * is 48 bits and void * is 32 bits. Or
two differend sizes anyway.
void * is only guaranteed to fit any pointer value.

[christian.bau]

On Nov 1, 1:10 am, [e-mail] wrote:

Consider the case where char * is 48 bits and void * is 32 bits. Or
two differend sizes anyway.
void * is only guaranteed to fit any pointer value.

That is not possible, since all variants of char* and void* are
guaranteed to have the same representation.

[CBFalconer]

vi****************@gmail.com wrote:

>
#include <stdio.h>
int main(void) {
float pi = 3.1415f;
printf("%d\n", (int)pi);
return 0;
}

simple

Simpler:
#include <stdio.h>
int main(void) {
puts("3");
return 0;
}
:-)

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

[Charlie Gordon]

"Jack Klein" <ja*******@spamcop.neta écrit dans le message de news:
rf********************************@4ax.com...

On Wed, 31 Oct 2007 01:15:33 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote in comp.lang.c:

>ca********@yahoo.com said:

Hi all,
I just came across the following program:

#include <stdio.h>
int main()
{
float a = 12.5;
printf("%d\n", a);
printf("%d\n", *(int *)&a);
return 0;
}

The program prints 0 and 1095237362. However, in my opinion it should
print 12 at both the places. Can anybody tell me where I am wrong?

You are wrong in thinking that %d is the appropriate format specifier for
a
float, and you are wrong in thinking that you can meaningfully cast the
address of a float into the address of an int.

You were right in the first pronouncement, not necessarily so in the
second. The result of casting a pointer to an object or incomplete to
a pointer to any other object or incomplete type, is undefined if the
pointer is not suitably aligned for the second type, but well defined
if there is no alignment error. Of course, dereferencing that pointer
is completely undefined.

Is this true for ``printf("%u\n", *(unsigned char*)&a);'' ?

--
Chqrlie.

[Keith Thompson]

pete <pf*****@mindspring.comwrites:
[...]

Casting an object pointer to type (char*) on the other hand,
gets you the address of the lowest addressable byte of the object.

Casting to unsigned char* is probably better.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[pete]

vi****************@gmail.com wrote:

>
On Nov 1, 2:22 am, pete <[e-mail]:

That's true, but a cast to type (void*)
is hardly ever applied to an object pointer in C.
An object pointer value can be assigned
to a (void*) object without a cast.

Casting an object pointer to type (char*) on the other hand,
gets you the address of the lowest addressable byte of the object.

In value context, yes. In size context, no.

char *p;
char *s = (char*)(void*)p;

I don't know what you mean
or what your code example is supposed to be showing.

Consider the case where char * is 48 bits and void * is 32 bits.
Or two differend sizes anyway.

There is no such case.

N869
6.2.5 Types
[#27] A pointer to void shall have the same representation
and alignment requirements as a pointer to a character type.

--
pete

[pete]

Charlie Gordon wrote:

>
"Jack Klein" <ja*******@spamcop.neta écrit dans le message de news:
rf********************************@4ax.com...

The result of casting a pointer to an object or incomplete to
a pointer to any other object or incomplete type, is undefined
if the pointer is not suitably aligned for the second type,
but well defined if there is no alignment error.
Of course, dereferencing that pointer is completely undefined.

Is this true for ``printf("%u\n", *(unsigned char*)&a);'' ?

No. As long as the (unsigned char *) value,
points to an object, it can be dereferenced.
Indeterminate unsigned char values,
are merely unspecified, not undefined.

--
pete

[vipvipvipvipvip.ru]

http://groups.google.com/group/comp....b88c1a001346b7
A char * can be more or less bits than a void *.

[Justin Spahr-Summers]

On Nov 1, 8:54 am, [e-mail] wrote:

http://groups.google.com/group/comp....d/thread/650ec...
A char * can be more or less bits than a void *.

You really should stop snipping all the context of your post. It makes
it hard to follow in certain newsreaders.

As regards your link, a Usenet post that may or may not be correct and
may or may not have anything to do with what you're trying to prove
anyways is not more authoritative than the text from the standard that
pete quoted.

[Philip Potter]

vi****************@gmail.com wrote:

http://groups.google.com/group/comp....b88c1a001346b7
A char * can be more or less bits than a void *.

That Usenet article precedes the C89 standard by 9 months.

--
Philip Potter pgp <atdoc.ic.ac.uk

[CBFalconer]

vi****************@gmail.com wrote:

>
A char * can be more or less bits than a void *.

You snipped Petes reply, which included the following:

There is no such case.

N869

6.2.5 Types
[#27] A pointer to void shall have the same representation
and alignment requirements as a pointer to a character type.

Obviously you are attempting to get PLONKED as an erroneous source.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[pete]

vi****************@gmail.com wrote:

Casting an object pointer to type (char*) on the other hand,
gets you the address of the lowest addressable byte of the object.

In value context, yes. In size context, no.

I'm not making this stuff up.

N869
6.3.2.3 Pointers
[#7] When a pointer to an
object is converted to a pointer to a character type, the
result points to the lowest addressed byte of the object.

--
pete

[Chris Torek]

In article <11**********************@o3g2000hsb.googlegroups. com>
<vi****************@gmail.comwrote:

>http://groups.google.com/group/comp....b88c1a001346b7
A char * can be more or less bits than a void *.

No, it must be the same size.

The URL above appears to refer to an article I wrote in 1989,
quoting something I wrote in 1988; both articles were written before
the original C standard was final (which was in December 1989, if
I remember right; the actual publication did not take place until
early 1990).

In any case, I was simply covering all possible bases when I said,
in effect, "if (void *) is the same as (char *), then call B is
wrong; but if it *not* the same as (char *), then call A is wrong".
The 1989 C Standard pinned down the details, which have not changed
since then: "void *" and "char *" have the same representation, so
they have the number of bits, and the same meaning for any
"non-padding" bits. So now we can say that it would have been call
B that would have been wrong. :-)
--
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.