Re: C bug of the day

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Hyman Rosen wrote:
> One of the trading systems we use in our company had been
> crashing every night for a week while trying to run a
> certain batch procedure. We finally traced the problem to
> the usual C bugaboo, a buffer overflow.
> 
> In this case, the program was trying to form an SQL command
> for entering a row of data into a database table. Even though
> the program is written in C++, the programmers apparently
> decided that the way to produce the SQL was to format it into
> a fixed-size buffer. Unfortunately, they decided to use '%f'
> to format some floating-point numbers, and more unfortunately,
> a situation arose in our data where a number was on the order
> of 10**141. Boom!

We've encountered a number of C problems here, similar to that.
The only difference is that our source code in question was
primarily in C. But your experience only goes to show as I have
always maintained, that C++ is not safe because of the STL.
There will always be the temptation to go straight to
the old C habits (I know, you can go out of your way to do
bad things in Ada too, but in Ada at least, this is usually
more effort.. not less).

Your problem occurred with a large number. The best one I had
encountered was the reverse. The value was near zero as something
like 1.0E-14. It took me 3 months of hard core debugging to ferrit
this one out, because it was occuring inside of a shared library that
was about 250k SLOC (C code). Because we always found problems
in this legacy code, I never expected to find the problem where it
finally turned up.

The problem ended up in an INFORMIX-7.31 library,
where the float (or was it decimal?) value was being converted
to some other form (I think it was decimal -> string) for
a formatted print with picture info. Chance are that this bug
is still in the current version ;-)

After building many types of electric
fence routines, I eventually proved that the problem was caused
by this INFORMIX conversion routine when the value had a very
negative exponent. It seems that the INFORMIX routine did not
plan its buffer properly in this scenario. Fortunately, for this
application, I was able to just plug in a zero if
the value was sufficiently small. This fixed the memory corruption
problem.

That little buffer overflow problem cost me 3 months of my life,
and was a very expensive mistake for the company to correct.

> We don't have the source code, but they do ship the program as
> relinkable libraries. We found the offending string and patched
> the binary to use %g instead of %f. Sigh.

Creative fix!  8-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]