Related articles |
---|
Re: Link-time datatype checking gorton@blorf.ltn.dec.com (1992-06-19) |
Re: Link-time datatype checking rjbodkin@theory.lcs.mit.edu (Ronald Bodkin) (1992-06-28) |
Newsgroups: | comp.compilers |
From: | Ronald Bodkin <rjbodkin@theory.lcs.mit.edu> |
Organization: | MIT Lab for Computer Science |
Date: | Sun, 28 Jun 1992 04:34:15 GMT |
Keywords: | linker, performance |
References: | <19920609091040SEB1525@MVS.draper.com 92-06-095 |
gorton@blorf.ltn.dec.com (Richard Gorton) writes:
> Consider the case when you, the C [C++] developer, with malice and
> aforethought, did write code which RELIES upon datatype mismatches for
> some reason or another.
Why not use unions for this situation? Certainly it would
work in C++; in C it might require a few macros if the C compiler
won't inline (static) functions.
In your example:
caller()
{
double callee(double val);
return callee(1.0e0);
}
union cheat {
double d;
long l;
};
inline static double inner_callee(union cheat cheater)
{
<Code that knows explicitly about floating point
formats and tinkers with bits>
}
double callee(double val)
{
union cheater c;
c.d=val;
return inner_callee(c);
}
Any optimizer worth its salt will be able to generate the same
code by use of this method, and even though its ugly it is clearer and
more explicit than the method of just lying to the compiler. Indeed, even
without inlining a compiler that does TRO should make callee and
inner_callee aliases.
Ron
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.