Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!ncar!ico!ism780c!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Bug in Microsoft C 5.1
Message-ID: <14563@haddock.ima.isc.com>
Date: 8 Sep 89 22:44:09 GMT
References: <1989Sep7.104322.1210@gdt.bath.ac.uk> <4199@ohstpy.mps.ohio-state.edu>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Distribution: comp.lang.c
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 26

In article <4199@ohstpy.mps.ohio-state.edu> SMITHJ@ohstpy.mps.ohio-state.edu writes:
>I ran this program on a VAX/VMS using the latest version of VAX C and the
>corresct sequence of numbers was printed out so that it does appear as tho'
>you have located a bug in the MSC 5.1 compiler.

I'm sure you already know this, but I'd like to point out that "It works on a
VAX" is not a very good test of code correctness.

>I would also suggest changing the init/while constructs you use to 'for'
>loops.  While these may seem like silly suggestions you would be suprized how
>quickly bugs disappear.

It depends on what the goal is.  I assume that at this point he just wants
someone to confirm that it's a real bug (which seems to be the case) so he can
report it to the vendor.  And even if the goal is to get the original program
working, and if it happens that converting from `while' to `for' makes this
manifestation of the bug disappear, I still wouldn't trust the compiler unless
I knew *why* it makes the symptoms go away -- i.e. what constructs tickle it,
and which ones are believed to be safe.

To the original poster: with the program being this simple and still failing,
if possible you should try single-stepping it with a debugger while examining
the contents of `i' at each step.  Or get the compiler to produce a machine-
language listing, and see if you can spot the improperly generated code.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint