Re: Link-time datatype checking

Ronald Bodkin <rjbodkin@theory.lcs.mit.edu>
Sun, 28 Jun 1992 04:34:15 GMT

          From comp.compilers

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)
| List of all articles for this month |

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
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.