c.lang.myself@gmail.com wrote:
Quote:
#include <stdio.h>
>
float puzzle( float inp )
{
const float ths = 1.5F;
const long k = 21*76069667;
>
float a, b;
int c;
>
a = inp * 0.5F;
b = inp;
c = *( long *) &b;
The conversion has behavior that is undefined if b doesn't happen to
be aligned correctly to store a long integer; this is unlikely, but
entirely possible. The only thing that the standard guarantees about
the resulting pointer is that if it is converted back to float*, it
will compare equal to &b (6.3.2.3p7).
For an object of type float, "long" is not one of the types listed in
section 6.5p7; therefore, trying to access an object of type float
using an lvalue of type "long" violates a "shall" occuring outside of
a Constraints section - the behavior of this code is undefined.
Even if right hand side of that expression had precisely the behavior
that the author expected it to have, there would be no guarantee that
the resulting value is within the range of an 'int'. Therefore, when
that value is implicitly converted to 'int' before assigning it to c,
"... either the result is implementation-defined or an implementation-
defined signal is raised." (6.3.1.3p3).
Quote:
c = k - ( c >1 ) ;
Even on a system where the value of c is precisely what the author of
this code probably expected it to be, there's no guarantee that c is
positive. That being the case, the result of the shift operation is
implementation-defined (6.5.7p5).
Quote:
b = *( float *) &c;
This statement has all of the same problems as the calculation of 'c',
except that section 6.3.1.3p3 will not be an issue unless INT_MAX >
FLT_MAX; this is extremely unlikely, but is technically a possibility.
Therefore, the correct answer to your question is "this function could
do anything". Even if the undefined behavior could be avoided, the
correct answer would still depend upon which implementation was used
to translate and execute this code. You haven't identified the
implementation, so the question could not be answered, even in that
case.
