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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-22 10:47:46 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!east1.newsfeed.sprint-canada.net!news.storm.ca!nnrp1.tor.metronet.ca!not-for-mail Message-ID: <3B83F042.4CFB073D@home.com> From: "Warren W. Gay VE3WWG" X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Subject: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) References: <3B6555ED.9B0B0420@sneakemail.com> <87n15lxzzv.fsf@deneb.enyo.de> <3B672322.B5EA1B66@home.com> <4a885870.0108112341.7ce02ac0@posting.google.com> <3B834E5D.B0D26AB1@adaworks.com> <9lvsic$bet9s$1@ID-9852.news.dfncis.de> <9m0193$grs$1@bird.wu-wien.ac.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 22 Aug 2001 17:47:46 GMT NNTP-Posting-Host: 198.96.47.195 NNTP-Posting-Date: Wed, 22 Aug 2001 11:47:46 MDT Organization: MetroNet Communications Group Inc. Xref: archiver1.google.com comp.lang.ada:12264 comp.lang.c:76180 comp.lang.c++:84886 Date: 2001-08-22T17:47:46+00:00 List-Id: Markus Mottl wrote: > In comp.lang.functional Joachim Durchholz wrote: > > Could you share a reference to a report? > > Here is a somewhat longer treatment of the case: > > http://www.jerrypournelle.com/reports/jerryp/Yorktown.html > > In short: a divide-by-zero in a database caused a Windows NT server to > crash, paralyzing the whole computer network on the cruiser Yorktown > for more than two hours. IMHO, it seems to me that advantages of having compiler generated bounds checking and overflow checking code are too often dismissed by the C/C++ camp. Just the other day, I came across a subtle C problem, that was discovered when I ported the algorthm to Ada95. I checked the most recent version of SoX source, and the problem _still_ exists there, apparently still undiscovered. Ada on the other hand, detected the problem very early in the porting development. The following C snippet converts linear 16-bit signed sound samples to A-law compressed samples. The abbreviated code looks like this: #define ACLIP 31744 ... unsigned char st_linear_to_Alaw( sample ) short sample; { static const unsigned char exp_lut[128] = { ...snip... }; int sign, exponent, mantissa; unsigned char Alawbyte; /* Get the sample into sign-magnitude. */ sign = ((~sample) >> 8) & 0x80; /* set aside the sign */ if ( sign == 0 ) sample = -sample; /* get magnitude */ if ( sample > ACLIP ) sample = ACLIP; /* clip the magnitude */ ... The logic is a bit twisted here because of the way the sign bit is tested, but you should be able to see the problem with a bit of effort. The error occurs on the following line : if ( sign == 0 ) sample = -sample; /* get magnitude */ Did anybody spot the problem? I'm sure some did, since I drew attentiont to it. While the logic is reversed in "(sign == 0)", the problem is this: The statement sample = -sample is executed when the linear sample is negative, and _then_ the sample is clipped based on its _positive_ magnitude, in the next statement. But what happens when the sample is -32768 ? Testing this on Red Hat 7, under Linux and HPUX, the result of the test shows that sample = -sample when sample = -32768 is -32768 ! With this as the result, the next statement fails to carry out the clipping code: sample = ACLIP; The end result? A botched encoded sample. Something that you probably would not hear with your ear. In practice this only happens when your samples are maxing out on the 16-bit range, which for recordings will likely result in a lot of clipped (noisy) samples anyway. So you might say, "so what?" Two things: 1) The result is incorrect (that should be enough) 2) This is still a problem for good 16-bit samples that are perhaps "processed" to use the maximum dynamic range (they may have been 32-bit samples before processed into 16-bit samples). Ada picked this problem up right away, albeit at runtime. When I saw the constraint error there, I immediately realized that I had overlooked this special case. This long time problem was obviously never detected by the C developers, and may now eventually get fixed as a result of this posting ;-) I wonder how many other sound projects derived from this same code, and possess the same bug? Windows CoolEdit? Anyway, while sound samples don't paralyze ships, I felt that this is another example of how subtle errors like this can go undetected in C/C++ code. Ada on the other hand was quick to point out this flaw. Kudos to GNAT. ;-) -- Warren W. Gay VE3WWG http://members.home.net/ve3wwg