From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,HEADER_SPAM autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fc772,b30bd69fa8f63cb2 X-Google-Attributes: gidfc772,public X-Google-Thread: 103376,b30bd69fa8f63cb2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-03 14:47:46 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.ems.psu.edu!news.cse.psu.edu!uwm.edu!rpi!not-for-mail From: "Warren W. Gay VE3WWG" Newsgroups: comp.lang.ada,comp.lang.c++.moderated Subject: Re: C bug of the day Date: 3 Jun 2003 17:49:58 -0400 Organization: Bell Sympatico Sender: cppmods@netlab.cs.rpi.edu Message-ID: <3EDCCE72.4020707@cogeco.ca> References: NNTP-Posting-Host: netlab.cs.rpi.edu X-Original-Date: Tue, 03 Jun 2003 12:36:02 -0400 X-Submission-Address: c++-submit@netlab.cs.rpi.edu X-Auth: PGPMoose V1.1 PGP comp.lang.c++.moderated iQBVAwUAPt0X/UHMCo9UcraBAQHHxQH+KxeoBBgzunyRMr6TTinAhL3BFclbU4+H gwiKdOSGPSoz9t1aCkDUj+U4DbOueJMYnL8JnVtaIIc7KnuyDtC9uw== =DSp1 Xref: archiver1.google.com comp.lang.ada:38557 comp.lang.c++.moderated:67650 Date: 2003-06-03T17:49:58-04:00 List-Id: 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! ]