Re: Link-time datatype checking

Numerous posts recently regarding "Lessons for compiler [warning] writers"
have indicated that for the case of the 'C' [C++] language, the following
approaches and data are relevant to solving datatype mismatches between
routines. Some of the pertinent points are:


a) Use prototypes for all modules.
b) Make compilers smarter to flag conflicts.
c) Have 'lint' catch a bunch of other cases.
d) Integrated environments which uses databases which
      know about the sources can catch a lot of these. But
      only as many as they knows about.
e) User source conflict with existing system library routines.
("This declaration shadows a library function.")


A linker which can catch datatype conflicts would be useful, (like the
RS/6000) but in order to support this kind of feature, the Object File has
to have the capability to carry the information around. The RS/6000
object file format ('xcoff') has a '.typcheck' section to do just this,
but for it to be worthwhile, the compiler has to actually generate
meaninful data for this section. And it certainly ISN'T a feature which
should be mandated, even on systems which have object file support which
the linker COULD flag such conflicts.


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. One quick example that comes to mind is
pass-by-value on SPARC of a floating point number. All pass-by-value
information is done in integer registers:


caller()
{
double callee(float)


return (callee(1.0e0));
}


callee(long_cheater)
long long_cheater;
{
<Code that knows explicitly about floating point
formats and tinkers with bits>
}


Why would anyone do this? Performance. Consider the UNIX trig routines.
The routines sin(), cos(), and exp() are passed floating point values by
value, and their job is to return the result of the operation. Now, on
most modern architectures, the FPU and the Integer Unit operate
independently, so to speed up the trig routines, one COULD utilize both
the integer operations (and twiddle bits) as well as performing floating
point calculations.


So, in summary, Yes, a really smart linker would be useful in catching all
those nasty mis-declared conflicts, but I certainly would want to be able
to disable such a capability because there are times when such mismatches
are intentional. And for production releases of linked executables, I
would most certainly want to strip out such information to decrease the
size of the executable. If the linkage checking information averages 5%
of the size of the object module, that could be a 2.5 Meg win for a 50Meg
executable.


Richard Gorton Alpha Migration Tools - Digital Equipment Corp.
gorton@tallis.enet.dec.com
[One is tempted to make an argument that people who use hacks like this
deserve a few warning messages. -John]
--

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