Just pasted your code in. Same result.... (I just pipe the output to a TXT
file, copy & paste)
--------------------------------
GIven an argument: 1.5
The number of arguments is : 1
0 0, 3FF80000
The result returned bu AddDouble() is: 1.5
Given arguments: 1.5 and 2.5
The number of arguments is : 2
0 0, 3FF80000
1 0, 40040000
The result returned by AddDouble() is 4.0
Given arguments: 1.5, 2.5 and 3.5
The number of arguments is : 3
0 0, 3FF80000
1 0, 40040000
2 0, 400C0000
The result returned by AddDouble() is 7.5
Given arguments: 1.5, 2.5, 3.5 and 4.5
The number of arguments is : 4
0 0, 3FF80000
1 0, 40040000
2 0, 400C0000
3 0, 40120000
The result returned by AddDouble() is 12.0
GIven an argument: 1.5
The number of arguments is : 1
0 0, 3FF80000
The result returned bu AddDouble() is: 1.5
Given arguments: 1.5 and 2.5
The number of arguments is : 2
0 0, 3FF80000
1 0, 40040000
The result returned by AddDouble() is 4.0
Given arguments: 1.5, 2.5 and 3.5
The number of arguments is : 3
0 0, 3FF80000
1 0, 40040000
2 0, 400C0000
The result returned by AddDouble() is 7.5
Given arguments: 1.5, 2.5, 3.5 and 4.5
The number of arguments is : 4
0 0, 3FF80000
1 0, 40040000
2 0, 400C0000
3 0, 40120000
The result returned by AddDouble() is 12.0
-----------------------------------
I think the optimize has something to do with it. BUT, this seems to
indicate otherwise.
I would be tempted to say the %X is not mapping the full floating point
number correctly, however,
The "result" value does.
=====================
Ok now, I tried something which does verify that %X does NOT map correctly
on float, infact it messes up the next number as well.
--------
#include <stdio>
main()
{
float x;
float *ptr_x;
x = 1.5;
ptr_x = &x;
printf("%f = %X\n %p, %p\n", x, x, ptr_x, &x);
return 0;
}
----------
result :
1.500000 = 0
3FF80000, 0012FF88
notice that the second "x" didn't print correctly nor did the following
ptr_x.
Now I'll type cast the second "x" as a long integer so they'll map to the
same length:
---------
#include <stdio>
main()
{
float x;
float *ptr_x;
x = 1.5;
ptr_x = &x;
printf("%f = %X\n %p, %p\n", x, (long int) x, ptr_x, &x);
return 0;
}
--------
result:
1.500000 = 1
0012FF88, 0012FF88
Notice the ptr_x found the correct orientation!
the second "x" did not give the hex listing , but we now know Wayne was
RIGHT!
Next, How can we get the hexadecimal format for a float???
I tried using %LX. Here's result:
1.500000 = 3FF8000000000000
0012FF88, 0012FF88
looks closer, except for verifing tha 3FF8 0000 is indead 1.5
Question: In fortran I can map an array of integers on top of an array of
floating point.
This allows me to gain access to the data in multiplt formats. This is done
by using the
"equate" operand.
Is there a similar operation within C ???
"Bob Gonder" <
XXXX@XXXXX.COM >wrote in message
Quote
Stan DeGroff wrote:
>for (i=0; i<x; i++){
>xresult = double va_arg(arglist, double);
>result += xresult;
>printf("%d %X, %X\n", i, xresult, result);
>}
>That prints the
>variable "xresult" resulted in printing 0x0000. However the variable
>"result" printed ok. Any ideas why the compiler forgets xresult?
I know this sounds weird, but try this.
for (i=0; i<x; i++){
xresult = double va_arg(arglist, double);
printf("%d %X, %X\n", i, xresult, result);
result += xresult;
}
I think that because xresult isn't needed later, it is optimised away.
If xresult were global, or used later, it would be made "real".
(Apparantly, being inside a printf is being invisible.)
There's a bug in the optimizer.
BTW, which compiler are you using?
