Subj : Re: Any help on why? To : borland.public.cpp.borlandcpp From : Stan DeGroff Date : Wed Jul 07 2004 04:48 pm 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 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 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" wrote in message news:3d8ne01afvj3q4ph7s71lklv2ej45c90gl@4ax.com... > Stan DeGroff wrote: > > > for (i=0; 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 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? > > .