pete@octopus.COM (Pete Holzmann) (06/28/91)
We just discovered that Microsoft has silently ANSI-fied "thousands" of
things in their C compiler in moving from version 5.1 to 6.0 (that's a
quote from a MicroSoft support engineer). Almost none of these changes
are documented anywhere.
Now I'm not particularly concerned about many of these changes, since they're
often enhancements, or obvious changes that show up whenever old non-ANSI
code is recompiled.
What concerns us, and should concern anyone else who has a significant pile
of code written in 5.1 C (we happen to have around a half million lines or
so), is that some unknon quantity of these changes can't be caught by the
compiler, nor by lint, and they silently introduce bugs into the code!
An example: the fputs() function in C 5.1 returns zero if successful, and
non-zero if it fails. Under ANSI C (including 6.0), it returns non-negative
(0 or greater) if successful, and negative if it fails. Thus, code that
correctly looks for ( fputs(...) == 0 ) is no longer valid.
Apparently, Microsoft made so many changes of this type that they found it
impossible to keep track of them all!
Since porting our code from C 5.1 to true ANSI C requires that we fix all
bugs of this type, we need to find or create a list of the changes from
C 5.1 to C 6.0 that can or will silently introduce bugs into existing code.
1) Does anybody out there already have such a list?
2) Is anybody out there willing or interested in helping me create such a
list? If enough of us work on it, it shouldn't be too bad...
Thanks!
Pete
--
Peter Holzmann, Octopus Enterprises |(if you're a techie Christian & are
19611 La Mar Ct., Cupertino, CA 95014 |interested in helping w/ the Great
UUCP: {hpda,pyramid}!octopus!pete |Commission, email dsa-contact@octopus)
Voice: 408/996-7746;FAX=408/985-0859kremer@cs.odu.edu (Lloyd Kremer) (06/28/91)
In article <1991Jun28.030934.10935@Octopus.COM> pete@octopus.COM (Pete Holzmann) writes: >We just discovered that Microsoft has silently ANSI-fied "thousands" of >things in their C compiler in moving from version 5.1 to 6.0 I think I found one by accident. Floats no longer automatically promote to doubles on evaluation. Instead the resulting type depends on which type comes first in the SOURCE code! For example: float f; double d; sizeof(f) == 4 sizeof(d) == 8 sizeof(f + d) == 4 sizeof(d + f) == 8 Any other arithmetic operator works the same. This may be an unwanted side effect of their change to let floats be passed to ANSI-defined functions taking a float parameter. However, I noticed that for old-style argument passing floats are still passed on the stack as doubles, if that's any consolation. Lloyd Kremer Hilton Systems, Inc. kremer@cs.odu.edu
steve@taumet.com (Stephen Clamage) (06/29/91)
kremer@cs.odu.edu (Lloyd Kremer) writes: |I think I found one by accident. Floats no longer automatically promote to |doubles on evaluation. Instead the resulting type depends on which type comes |first in the SOURCE code! For example: | float f; | double d; | sizeof(f + d) == 4 If this is true, it is a bug; it is not due to any ANSI rule. The sizeof operator is obliged to return the size of the type of its expression. The type of 'f+d' is 'double', under ANSI C rules, or any other C rules. In K&R C, floats were always promoted to doubles in any expression. In ANSI C the 'always' requirement is removed. There are still rules which require floats to be promoted to doubles. If one operand of a binary operator is a double, the other is promoted to double (unless it is a already a long double). This rule covers the given example. -- Steve Clamage, TauMetric Corp, steve@taumet.com