Path: utzoo!utgpu!watmath!clyde!bellcore!rutgers!cs.utexas.edu!ico!rcd From: rcd@ico.ISC.COM (Dick Dunn) Newsgroups: comp.unix.microport Subject: Re: Floating exception bug Summary: fix it where it's broken Message-ID: <12523@ico.ISC.COM> Date: 7 Dec 88 20:20:33 GMT References: <1656@viper.Lynx.MN.Org> <171@nlgvax.UUCP> <1675@viper.Lynx.MN.Org> Organization: Interactive Systems Corp, Boulder, CO Lines: 55 In article <1675@viper.Lynx.MN.Org>, dave@viper.Lynx.MN.Org (David Messer) writes about a program core-dumping on a Microport system: > > I've had many people point out to me (in boring detail :-) that the problem > is an inconsistent declaration. Of course that is the problem! So fix it! How hard is it to reason through this one? - The program has a bug - The bug causes a core dump - The bug has been found - The fix is trivial Why should there be a fix somewhere other than where the bug is. >...What is > unacceptable to me is that a function in a _library_, whose definition > I may not of known, caused a problem... If that's unacceptable to you, then find another programming language, 'cause that's the way C works. Each compilation unit (source file) has to have all the declarations it takes to make the program consistent. As a result of that, you can't just blindly use functions without knowing their interfaces and either explicitly declaring what you need or getting the declarations from an include file. Of course, it's also hard to figure out how you can use a function without knowing its definition! (How do you use something if you don't know what it does?!) > ...If I hadn't had the source to the > function in question, I never would've found it... I regularly use hundreds of functions for which I don't have source. I get the information about them (including proper declarations) from the documentation. I don't need the source; I treat them as black boxes which perform certain functions. All I need to know is the interface. > The program in question has compiled and executed correctly for many > years on a variety of UNIX systems ... Not so. The program in question, by your own admission, is not a correct C program; therefore it is not possible for it to "compile and execute correctly". It IS possible for it to compile and do what you want it to. I'm sorry if that seems like splitting hairs; it's not. The whole point of having language definitions is so that we know what should work on any correct implementation of the language. The definition is binding both on the language implementor (to make the implementation do what it's defined to do) and on the programmer using the implementation (to use only what's defined, and not anything that happens to seem to work). >...it should've compiled and > executed correctly on Microport. Why? You want them to "fix" their implementation so you can retain your bug, to be painfully rediscovered on another system in the future? -- Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870 ...I'm not cynical - just experienced.