-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Darren New wrote: > Christopher Smith wrote: >> Trust me. I'm a Smalltalk developer. I grok the Zen, and C++ doesn't >> prevent recovery any more Java. > > Cool. So, like, how does C++ recover from a random pointer being invoked > as an object with a message call, after you've already freed that > memory? Assuming it doesn't dump core, that is?
a) by allowing you to avoid using random pointers b) by allowing you to override new and delete operators to ensure you don't do a double free c) by allowing you to install your own heap d) by allowing you to use a platform or compiler that traps when this happens, say by installing a signal handler for SEGV. >> Here's the thing: you invariably are using some code that wasn't >> necessarily written in a "safe" way. Whether you are using a language >> that is "safe" or C++, it is possible to work at a level of >> abstraction such that your application code isn't doing "unsafe" >> operations. Whether you have to cross some language boundary or not to >> do "unsafe" work is kind of irrelevant. > > Well, obviously, the degree of "safe" depends on the definition of what > you're looking at, and from what side. Many machine languages are > "safe". Hmm.. maybe you mean something different by "machine languages" than I do, but if a machine accepts any arbitrary sequences of bits, there really isn't any safety coming from it. >>> If the programming error of "whoops, forgot to limit the input to the >>> size of my buffer" would checkpoint and dump core, we wouldn't have >>> zillions of viri floating around out there. >> Yes, this is kind of exactly my point. > Uh huh. And I guess you're missing mine. I believe your point is that if everyone would just always do bounds checks and core dump when they exceeded their buffer sizes, we wouldn't have viruses floating around out there. That sounds like an excellent point about why dumping core is a good thing. ;-) >> So, you produce less information about your state, > > Yes. It only shows me what I need to know to debug it. No, it shows a small subset of what you need to know to debug it. As you said yourself, sometimes you need to get more. Sometimes you need even more than a core file, but given that the OS will do it for you, it makes little sense to do less and lose that potentially vital context. >> and you require that your unexpected error hasn't also screwed up your >> database and/or mail access, right? > > Nope. But if it hasn't (and it almost never does), then I get better > information. So, what happens when the database and/or mail don't work? Do you recover and go about your business or do you dump core? >>> Usually I don't have to restart the process, but if I can tell what >>> the error was, I may or may not need to. Chances are that a "socket >>> already in use" error isn't going to get cleared up by me restarting >>> the server. >> Hey, that sounds like an expected error again! ;-) > > Now you're cooking with gas. Safe languages are those that turn > unexpected errors into expected errors. See above null pointer comment. Safe languages *don't* change unexpected errors in to expected errors. As you said yourself, they just remove the possibility of undefined code. Whether an error was expected or not is largely a function of a programmer's noggin. - --Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGbeQ9OagjPOywMBARAumlAKC3JfGaoJaZM+zXDQ6jwlivNIvb0wCgy5AS Ah2l9lAXzipoASu9jj5o5lU= =l0wI -----END PGP SIGNATURE----- -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
