Bug in most used C++ code on the planet?
Ok so this is guess work but I suggest that almost all C++ code reads
some input and in many cases that input consists of numbers, floating
point numbers. Most computers are IBM PCs running microsoft code.
So I'm suggesting that a bug in the microsoft code that reads
floating point numbers must be amongst the largest bugs in C++ code.
Yet such a bug exists.
Microsoft Visual C++ 6.0 exception on reading 20 character float
An arbitrary limit of 20 characters on floating point numbers read by
microsoft visual
C++ 6.0 has been imposed. This limit, MAXFLTSIZ, has not been
documented. It has been poorly implemented, giving array bound errors
with unpredictable consequences. In one case it caused the executable
to fail (repeatably) on reading 5848000000000.000000
I recommend private routine getdouble() and routines that call it
be re-written not to use a buffer for text read from the input stream.
In file istrgdbl.cpp routine getdouble() the calling routine provides a
buffer of 20 chars, which is used to receive a number as ascii text as
it is read sequentially from the input stream. A check is made that the
number of characters in the number does not exceed 20.
Like a regular C string, the characters in the buffer are terminated by
a null character. NO CHECK IS MADE THAT THERE IS SPACE FOR THE NULL.
If the string reaches 20 characters ios::failbit is set.
Overwriting the byte after the buffer can cause an exception before it
is possible to check istr.rdstate()
The buffer length is set via a fixed and undocumented macro MAXFLTSIZ in
file istrflt.cpp
The bug has been demonstrated on three different PCs.
All my C++ sources complied with debug
I checked visual cpp
Service Pack 5 but could find no mention of istrgdbl.cpp
or istrflt.cpp of this bug or fixes to it.
Why?
Its easy to concentrate upon the array index out of bound part of the
bug. This is easy to see and fix.
But this ignores two problems.
The Wrong Algorithm has been Coded
It is fundamentally wrong to impose a compiler dependent limit on the
length of floating point numbers read from a stream.
It is unnecessary.
The fixed length buffer is not needed to decode the string.
An indefinitely long number can be converted (possibly with
truncation) to a fixed floating point representation in a single pass
through the character sequence.
An Algorithm has been Coded
Many others have already solve the problem of converting a sequence of
ascii characters (- + digits . e) into a floating point number.
Why did microsoft decide to write its own?
(Rather than licensing existing, working, code).
W. B. Langdon
Bug found October 2003