Floating exception bug

[Mike Borza]

In article <1675 at viper.Lynx.MN.Org> dave at viper.Lynx.MN.Org (David Messer) writes:
>In article <171 at nlgvax.UUCP> geertj at nlgvax.UUCP (Geert Jan de Groot) writes:
> >In article <1656 at viper.Lynx.MN.Org> dave at viper (David Messer) writes:
> >
> >Not true! Functions always return values on the stack, even if the value
> >isn't used. Thus, y() returns a double on the floating point stack.
> >But, main() doesn't remove it because of the wrong declaration. 
> >Thus, y() _must_ be declared double.
>
>I've had many people point out to me (in boring detail :-) that the problem
>is an inconsistent declaration.  Of course that is the problem!  What is
>unacceptable to me is that a function in a _library_, whose definition
>I may not of known, caused a problem which only showed up much later
>in the execution of the program.  If I hadn't had the source to the
>function in question, I never would've found it.

That the undeclared library function definition is unacceptable to you
is irrelevent.  The compiler has correctly used what semantic
information it has available to make a decision about how to
handle the return value.  If this semantic information is in error,
the compiler can hardly be blamed for the mistake.
>
>The program in question has compiled and executed correctly for many
>years on a variety of UNIX systems -- it should've compiled and
>executed correctly on Microport.

I have no doubt that the error in question was difficult and tedious
to find, but that changes nothing.  The fact that the computed results
were similar across a variety of machines is not a proof of correctness.
The implementor of the compiler is free to make whatever decisions
s/he likes about the underlying implementation of the language, so long
as the implementation conforms the standard.  The program you describe
apparently made an implicit assumption about the implementation, which
was true enough across a variety of machines, and possibly compilers,
that the error went undetected until now.

I know a researcher who migrated a large-ish program "which had been
working for years" from a CDC mainframe to a VAX VMS environment.
The program crashed unpredictably with segmentation exceptions,
and the researcher was sure the problem was in the hardware or
system software.  One of his assistants spent more than a month to
find that the cause was a scalar which was passed to a subroutine
and picked up as an array.  This bug had gone undetected for years
and survived through a variety of hardware and system software changes.
Should this program have "worked"?  Semantically, there is little
difference between this problem and the one you describe.

Now my real question... what other little goodies are waiting in
store for you the next time you port this monster?  Will it port
painlessly to a vectorizing architecture?  To a parallel one?

>   __                     _ _ _              David Messer - Lynx Data Systems

mike borza  <antel!mike at maccs.uucp or nusip at maccs.uucp>