int * vs float * type

Question

Given the following snippet of code:

int *iptr;
float *fptr;
float fval;
fval = 0.0;
fptr = &fval;
iptr = fptr;
printf("%d \n", *iptr);
fval = 1.0;
printf("%d \n", *iptr);

The output is:

0
1065353216

Why does the first print statement at least approximately match the value associated with *iptr (0.0), yet the second print statement doesn't?

Read up on the representation of float. Then you will understand. — RedX, Apr 11 '14 at 08:19
A good beginner's reference for floating-point representation can be found here: http://floating-point-gui.de. — Richard J. Ross III, Apr 11 '14 at 08:20

score 12 · Accepted Answer · edited Apr 11 '14 at 08:28

12

When you write printf("%d \n", *iptr);, you are asking printf to interpret the value pointed to by iptr as an integer.

It just so happens that float version of 0 is represented by the same bits of the int version of 0. In particular, the bits are all 0.

However, an arbitrary float, such as 1.0 will have a different bit representation (as defined by IEEE Standards) which will make little sense when interpreted as an int.

This Wikipedia article explains how a float is represented as bits.

edited Apr 11 '14 at 08:28

ajay

9,402
8
44
71

answered Apr 11 '14 at 08:20

merlin2011

71,677
44
195
329

@merlin2011: is strict aliasing not an issue here? (e.g., here: http://stackoverflow.com/questions/98650/what-is-the-strict-aliasing-rule, "So basically if you have an int* and a float* they are not allowed to point to the same memory location. If your code does not respect this, then the compiler's optimizer will most likely break your code." – Apr 11 '14 at 08:51
@dmcr_code It definitely is. That's why I added my own answer. – ajay Apr 11 '14 at 08:58
1

@ajay: Yes, I think it has to be mentioned; (unfortunately) C has many "nasty" details which one needs to know(I myself got acquainted with some of them recently, like this one, or signed/unsigned mixing, etc.) – Apr 11 '14 at 09:02
@dmcr_code Writing safe, standards compliant C code is far from a trivial task and requires serious effort. I myself am learning it the hard way. – ajay Apr 11 '14 at 09:11
@ajay: standards compliance is smth I haven't "considered" so far, I usually try to write with what I have learned (e.g., using books), and not reinvent the wheel and try to avoid some cryptic expressions, etc. and watch for pitfalls like this one for example – Apr 11 '14 at 09:19
@ajay, Thanks for supplementing this answer with your own. Strict aliasing is certainly an issue, but that was not the first thing that came to mind when I saw this question. :) – merlin2011 Apr 11 '14 at 16:57

Bathsheba · Answer 2 · 2014-04-11T08:27:00.247

3

The statement iptr = fptr; will invoke undefined behaviour.

There is not much point in speculating about the outcome therefore.

edited Apr 11 '14 at 08:27

answered Apr 11 '14 at 08:18

Bathsheba

231,907
34
361
483

Why is it *Undefined Behavior* – 0xF1 Apr 11 '14 at 08:19
1

Because you're effectively doing a cast to an unrelated pointer type. – Bathsheba Apr 11 '14 at 08:20
@Bathsheba can you quote the relevant portion from the standard please, which explains this? – ajay Apr 11 '14 at 08:21
I'm in a coffee shop so can't. But it's rather like doing `(int*)(void*)(float*)&fval` which, we all know is UB. – Bathsheba Apr 11 '14 at 08:23

score 3 · Answer 3 · edited May 23 '17 at 12:13

@merlin has explained the output of your code very nicely and clearly. However, there's more to it so I will add it here. Your code violates the strict aliasing rule and invokes undefined behaviour. Strict aliasing rule means different pointer types should not point to the same memory location.

iptr = fptr;

iptr is of type int * and fptr is of type float *. This statement assigns fptr to iptr - a different type - which means both now point to fval. This breaks the strict aliasing rule. This causes undefined behaviour which means unpredictable behaviour. The standard imposes no requirements on the implementation to deal which such cases. In short, you should avoid code which causes undefined behaviour.

Rahul Tripathi · Answer 4 · 2014-04-11T08:25:30.960

2

Its an undefined behavior: iptr = fptr;. You cannot print a float as an int, floats are stored in IEEE754 format

You need to try this:

printf("%d", fval);

edited Apr 11 '14 at 08:25

answered Apr 11 '14 at 08:19

Rahul Tripathi

168,305
31
280
331

score 1 · Answer 5 · answered Apr 11 '14 at 08:19

1

A zero floating point number consists of zeroes. Any other number is not just the number but an exponent and a mantissa - of course neither of them is just your number.

answered Apr 11 '14 at 08:19

ThiefMaster

310,957
84
592
636

score 1 · Answer 6 · answered Apr 11 '14 at 08:24

Floats are stored in IEEE754 format, in which the value of a number such as 1.0 is quite different to 1 (it is offset to allow for negative numbers and exponents). You cannot print a float as an int and have the result resemble the number assigned to the float.

int * vs float * type

6 Answers6