manning@mmm.UUCP (Arthur T. Manning) (01/30/89)
/*
I received this explation from David West of Microware (515-224-1929):
"The problem demonstrated by the program above is a known bug in the
Microware C library and will be corrected in the next release (version
3.1). [It may be possible to patch the bug depending on C compiler and
operating system versions.]"
*/
#include <stdio.h>
main()
{
double x = 123.45;
double *double_ptr = &x;
short *short_ptr = (short *)&x;
printf("double is %5.2f\n",x);
*short_ptr = 0x6666; /* this must make x an illegally formatted double? */
printf("double is now -->"); fflush(stdout);
/* this program appears to crash at this point */
printf("%5.2f\n",x);
printf("\nprogram complete!\n\n");
}
--
Arthur T. Manning Phone: 612-733-4401
3M Center 518-1 FAX: 612-736-3122
St. Paul MN 55144-1000 U.S.A. Email: manning@mmm.uucpconsult@osiris.UUCP (Unix Consultation Mailbox ) (02/01/89)
In article <1225@mmm.UUCP> manning@mmm.UUCP (Arthur T. Manning) writes
about a "bug" in the Microware C library code for printf. I have a
couple of comments.
First, why is this "bug" a problem? Is the bit pattern created by
poking 0x6666 into the middle of (double) 123.45 a legitimate double?
I doubt it; if it were, I think this problem would have been fixed
long ago. I've never dealt with Microware, but they seem to be more
considerate of their customers than any software company I've ever
known. (For one thing, they are willing to ascribe intelligence to
their customers - most companies just plain can't do this so it must
say something for the quality of Microware's clientele. :-)
Do you really need to be able to poke random bit patterns into doubles?
If so, I'd hate to ever have to support your software.
If it isn't just for fun, are you really worried about it? Common
sense would say that doing something unsupported results in
indeterminate behavior. I'd say that printf (or _doprnt or whatever)
bombing when told to interpret garbage correctly is acceptable behavior.
(You can't tell me that it's not doing what it should if you can't tell
me what "should" is.)
I guess my conclusion is "so what"? It's either a really serious bug
that should have been fixed years ago or a meaningless, trivial side-
effect of misuse of the C language.
In any case, even though I'm dubious that this problem is a genuine
one, I *am* curious about why a fault occurs. I'd try to figure it out
myself but don't know what endiosity a 68k uses and don't have my Sun
anymore to try it and see. (Btw, it works just fine on a Pyramid 9820,
though the results are meaningless...)
philjejones@mcrware.UUCP (James Jones) (02/02/89)
In article <2820@osiris.UUCP> consult@osiris.UUCP (Unix Consultation Mailbox (Phil)) writes: >...why is this "bug" a problem? Is the bit pattern created by >poking 0x6666 into the middle of (double) 123.45 a legitimate double? Yes, it is; Mr. Manning really did find a bug. The value resulting from the poke is somewhere around 1.6e180. While one can suspect that there are better formats to use to print numbers of that magnitude than %f, it should neverthelesss be possible to do so, and as Manning quotes Dave West as saying, it will be possible to do so in the future. James Jones
manning@mmm.UUCP (Arthur T. Manning) (02/03/89)
Yes, Phil, the printf bug was found while tracking another bug and it was far from being fun. A short * got lost inside a double, and it took a while to find it with the printf bug causing the program to crash. I called it a bug after cc and gcc both compiled and ran ok on a Sun 3 with bsd3.5. -- Arthur T. Manning Phone: 612-733-4401 3M Center 518-1 FAX: 612-736-3122 St. Paul MN 55144-1000 U.S.A. Email: manning@mmm.uucp