Re: Good 'C Question' | pointer problem

On Jan 30, 1:22 am, rake <t.sathyanaraya...@xxxxxxxxx> wrote:
#include <stdio.h>
#include <stdlib.h>

int main() {
void *ptr;
int *pi;
float *fp;

ptr = (void *) malloc(100);

This allocates an array of 100 chars and putting the result in ptr.
Or it might give you NULL. You didn't check for this, but lets ignore
that for now.

pi = (int *)ptr;

This forces a the (void *) pointer ptr to become compatible with an
(int *) and assign it to pi. However the storage on the other end of
ptr was relative to bytes, not ints. In a normal system that means
that you have allocated space for an array of 100/sizeof (int) ints
and made that storage available to pi.

*pi = 500;

Or pi[0] = 500. Ok, so you've assumed that sizeof(int) < 100 which is
fine.

*(pi + 1) = 1000;

Or pi[1] = 1000. That's fine so long as 2 * sizeof(int) < 100 .

printf("\nTwo int numbers %d , %d", *pi, *(pi + 1));

%d corresponds to int, so that's great.

fp = (float *)ptr;

Alright so now you are reinterpreting the storage for ptr to be
accessible by fp. This will give you 100/sizeof (float) entries.

printf("\nTwo float numbers %f , %f\n", *fp, *(fp + 1));

Alright, from a "C language" point of view, this is off into outer
space. You did not store any floating point values at fp[0] or fp
[1]. Pointer coercion through casting is not the same thing as value
coercion through explicit conversion. The two values that you stored
as integers only make sense as integers. Re-interpreting the
resultant storage to be floating point is meaningless.

return 0;

}

Output:

Two int numbers 500, 1000,
Two float numbers 0.0000, 0.0000

Why the Output for Float is 0.00000,0.0000 instead of 500.000,
1000.000.

Although Integer and float are 4 Bytes ( 32bit Machine), though i
typecast (float *) to print float, it gives the same output,

Well, what is happening is not defined by the C standard. In
particular its implementation defined, and what actually happens is up
to the compiler developer.

If you are truly trying to do this kind of weird byte-level
reinterpretation you need to understand two things. 1) What is the
endianness of integers vs the endianness of floating point on the
machine you are using. 2) What is the floating point and integer
representation on the machine you are using. Most use IEEE-754 and 2s
complement respectively.

On an Intel machine using a typical 32 bit compiler (gcc, Microsoft,
Watcom, Borland, Intel, etc), for example, you will find that the high
bits set the biased exponent and sign of the number for floating
point. In this case, the numbers you are storing a low integers, and
so will affect the low bits of the floating point pattern, while the
high bits are all zero. If I recall correctly, that will force the
numbers either to be 0 or very small denormals. Some systems, like
the DEC Alpha and PowerPC, (I think) and AMD's old 3DNow! on their
K6-2's have a non-IEEE floating point format in which "denormals" are
all interpreted as 0 (for speed reasons -- but it leads to a
discontinuity and other lost properties).

In any event, then comes the question of how your system prints out a
floating point with %f. The numbers should have been very small
numbers, but instead they are showing 0. Perhaps you have one of the
weird systems I described above, or your standard library just writes
denormals as 0 (which is not a very good standard library behavior).

Any one can throw wisdom, what is happening actually on assignment

pi = (int *)ptr;
fp = (float *)ptr;

The pointer values are just set to be the same, causing them to point
to the same storage (the result of your malloc(100), which might be
NULL by the way). You can argue that this is sort of ok (though it
looks suspicious -- most pointer casts that change the type of the
dereference are). The question is how you use the pointers after this
point.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
.