Is this code ANSI-compliant?

[ais523]

I have some code, which I know will not work (I haven't included
<math.h>, so sqrt will be assumed to return an int). What I want to
know is, is an ANSI-compliant implementation required to produce an
executable as output (even if the actual output is undefined)?

#include <stdio.h>
/*#include <math.h>*/

int main()
{
float a=36.0;
a=sqrt(a);
printf("%f; %d; %d; %d",a,sizeof(int),sizeof(float),sizeof(double));
getchar();
return 0;
}

(I use the printf line to see how various implementations treat the
code. I have compiled this code under 4 different implementations; in
each case, the code runs, but only under gcc has it produced the answer
6.0. In most cases, the compiler interprets the bit-pattern of the
double 6.0 as an int, converts that to a float, and then prints it.)

Thanks in advance.

 

[Keith Thompson]

I have some code, which I know will not work (I haven't included
<math.h>, so sqrt will be assumed to return an int). What I want to
know is, is an ANSI-compliant implementation required to produce an
executable as output (even if the actual output is undefined)?

No. It's not just the output that's undefined; the *behavior* is
undefined.

#include <stdio.h>
/*#include <math.h>*/

int main()
{
float a=36.0;
a=sqrt(a);
printf("%f; %d; %d; %d",a,sizeof(int),sizeof(float),sizeof(double));
getchar();
return 0;
}

The assignment "a=sqrt(a);" invokes undefined behavior. The standard
says (C99 3.4.3p2):

NOTE Possible undefined behavior ranges from ignoring the
situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
characteristic of the environment (with or without the issuance of
a diagnostic message), to terminating a translation or execution
(with the issuance of a diagnostic message).

 

[Randy Howard]

Keith Thompson wrote

No. It's not just the output that's undefined; the *behavior* is
undefined.


The assignment "a=sqrt(a);" invokes undefined behavior.

Might also mention that sizeof yields a size_t, which may or may
not fit in a %d format specifier on the platform.

Also, math.h shouldn't be commented out.

No newline in the printf().

No reason not to use double instead of float in 2006 either.

 

[Jordan Abel]

No. It's not just the output that's undefined; the *behavior* is
undefined.


The assignment "a=sqrt(a);" invokes undefined behavior. The standard
says (C99 3.4.3p2):

Actually, the expression sqrt(a) invokes undefined behavior. The
original question, though, was whether this is undefined behavior at
compile-time or at run-time.

 

[Thomas Maier-Komor]

No reason not to use double instead of float in 2006 either.

One reason comes to my mind. Try this:

#include <stdio.h>

double i = 1.7;

int main()
{
printf("%6g\n",((double)(10.0)*i));
printf("%6d\n",(int)((double)(10.0)*i));
return 0;
}

Try this on an x86 machine, then on another with IEEE compliant
rounding. This does not happen if you use float variables instead.

On x86:
17
16

On SPARC
17
17


Cheers,
Tom

 

[Grumble]

One reason comes to my mind. Try this:

#include <stdio.h>

double i = 1.7;

int main()
{
printf("%6g\n",((double)(10.0)*i));
printf("%6d\n",(int)((double)(10.0)*i));
return 0;
}

Try this on an x86 machine, then on another with IEEE compliant
rounding. This does not happen if you use float variables instead.

On x86:
17
16

You might want to come and discuss this in comp.lang.asm.x86

I suspect you'd want to tweak the precision control field and/or the
rounding control field.

<quote>
The default precision is double-extended precision. Selecting double
precision or single precision reduces the size of the significand to 53
bits or 24 bits, respectively, to satisfy the IEEE standard for these
floating-point types. This allows exact replication, on different
IEEE-compliant processors, of calculations done using these
lower-precision data types. When using reduced precision, rounding
clears the unused bits on the right of the significand to 0s.
</quote>

 

[Thomas Maier-Komor]

You might want to come and discuss this in comp.lang.asm.x86

I suspect you'd want to tweak the precision control field and/or the
rounding control field.

<quote>
The default precision is double-extended precision. Selecting double
precision or single precision reduces the size of the significand to 53
bits or 24 bits, respectively, to satisfy the IEEE standard for these
floating-point types. This allows exact replication, on different
IEEE-compliant processors, of calculations done using these
lower-precision data types. When using reduced precision, rounding
clears the unused bits on the right of the significand to 0s.
</quote>

I don't really discuss workarounds. I just wanted to state that there
are situations that might be a valid reason not to use double.

It is sad, but it is a problem of the x86 processor implementation. Not
all processors are effected from this issue.
BTW: this is one of the most often reported non-bugs of gcc.
Look here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323


Cheers,
Tom

 

[tedu]

Actually, the expression sqrt(a) invokes undefined behavior. The

can you elaborate on what the undefined behavior is? keith's note
doesn't really shed any light. would using sqrtf make it correct?

 

[Keith Thompson]

can you elaborate on what the undefined behavior is? keith's note
doesn't really shed any light. would using sqrtf make it correct?

The note was to clarify what the standard says about undefined
behavior (that it can result in a compilation failure as well as
arbitrary run-time behavior).

Jordan is right; it's the call itself that invokes undefined behavior.
(My statement that the assignment inovkes undefined behavior was less
precise; I was referring to the expression as a whole, which includes
the call, not to the act of assigning the value.)

The call sqrt(a) invokes undefined behavior because there's no visible
prototype for the sqrt() function. In C90, it's implicitly assumed
that the function takes an unknown number and type(s) of arguments and
returns int. Since the actual sqrt() function returns double, you're
lying to the compiler, and it will get its revenge. The most likely
behavior is that the generated code will grab an int value from
somewhere (either from the location that the actual double result is
stored, or from somewhere else, depending on the calling conventions)
and *assume* that it's an int. That's where the undefined behavior
takes place. If that doesn't blow up, the int value is then
implicitly converted to float and assigned to a. (The same thing
would happen if you replaced sqrt() with fsqrt().)

In C99, implicit int has been removed. I *think* this means that the
call is illegal, since the compiler has no way to guess, even
incorrectly, what the actual return type of sqrt() is -- or it might
just be undefined behavior for subtly different reasons. I'm sure
someone can find chapter and verse to determine exactly what the rules
are.

The proper solution, of course, is to add the proper "#include <math.h>"
so there *is* a prototype in scope.

Worrying about just how the program can behave without the prototype
might arguably be a waste of time, but it can be illuminating, or at
least interesting, in tracking down program bugs, in implementing a
compiler, or just in understanding the rules of the language. The
original question was specifically about the nature of undefined
behavior for an admittedly incorrect program.

 

[Grumble]

(Again, we should discuss this in comp.lang.asm.x86)

I don't really discuss workarounds. I just wanted to state that there
are situations that might be a valid reason not to use double.

<quote the Intel manual>
When the x87 FPU is initialized with either an FINIT/FNINIT or
FSAVE/FNSAVE instruction, the x87 FPU control word is set to 0x37F,
which masks all floating-point exceptions, sets rounding to nearest, and
sets the x87 FPU precision to 64 bits.

[...]

The double precision and single precision settings reduce the size of
the significand to 53 bits and 24 bits, respectively. These settings are
provided to support IEEE Standard 754 and to provide compatibility with
the specifications of certain existing programming languages. Using
these settings nullifies the advantages of the double extended-precision
floating-point format's 64-bit significand length. When reduced
precision is specified, the rounding of the significand value clears the
unused bits on the right to zeros.
</quote>

#include <stdio.h>

void set_FPU_control_word(unsigned int mode)
{
__asm__ ("fldcw %0" : /* no output */ : "m" (mode));
}

double d = 1.7;

int main(void)
{
set_FPU_control_word(0x27f);
printf("%6g\n",((double)(10.0)*d));
printf("%6d\n",(int)((double)(10.0)*d));
return 0;
}

On a Pentium MMX, the output is:
17
17

See also:
http://www.network-theory.co.uk/docs/gccintro/gccintro_70.html