nazgul@apollo.UUCP (Kee Hinckley) (11/14/83)
***
*
*
I found the following bugs in AZTEC C on the Apple, but at least one of them
is probably generic.
1) printf does not support the "g" option for floating point numbers.
It turns out that the support should be in the "format.c" file, which
is called by printf, scanf, etc.. I checked and found that it was
half implemented, as though someone forgot to finish it. Further
checking showed that the reason they never finished was that the
floating-to-ascii routine (in 6502 assembler) only takes the "f" and
"e" formats. In any case, it is fairly simple to add "g" to "format.c"
so that it will at least *print* the number, even if it isn't optimized.
2) ".0f" prints the decimal point, after the number. Technically I suppose
this isn't a bug, but it is annoying.
3) WARNING! If the floating point number you are trying to print out is
a power of ten less than the precision allows, the float-to-ascii
routine will hang! (If you don't follow that (and I'm not sure I
stated it accurately anyway) take the following examples:
".0f", .01 --> bombs
".1f", .001 --> bombs
".2f", .0001 --> bombs
...)
I couldn't follow the assembler code enough to figure out what was
happening.
If anyone has any fixes to any of the above (other than kludging the "format.c"
functions) I would appreciate them. I've reported the bugs to MANX, but I don't
know when they will come out with a fix. Incidentally, one of my disks ceased
operating suddenly (both copy and master) so I had them send me another. They
had a newer version of VED on it... but it doesn't work on the ][e! For some
reason it takes carriage return as an illegal character! The object code is
also 2 records smaller, for what thats worth. I don't know if the problem was
][e specific or not.
Query: A device driver for the ][e 80-column card? Someone?
-kee
...decvax!wivax!apollo!nazgul