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,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c1131ea1fcd630a X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: To Initialise or not Date: 1996/05/02 Message-ID: #1/1 X-Deja-AN: 152625325 references: <318508FE.204B@sanders.lockheed.com> <318792E8.28CC1042@escmail.orl.mmc.com> <3188AF51.1F1A7590@escmail.orl.mmc.com> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-05-02T00:00:00+00:00 List-Id: In article <3188AF51.1F1A7590@escmail.orl.mmc.com>, Theodore E. Dennison wrote: >Well, no. A compiler can't detect a thing at run-time. The compiler is >not even running then. It is happily asleep on the disk, dreaming >compiler dreams. Yeah, yeah, yeah. I meant that the code generated by the compiler can do it. >I do see what you are getting at, but I don't think adding a "dirty >bit" to every varaible is a serious consideration. (At least, the >systems programmer in me HOPES it isn't). As I said, the argument against this is efficiency. And, possibly, that it might make interfacing to other languages or hardware more difficult. (I can imagine ways to implement it invisibly.) You don't have to add an entire bit, in most cases. You need to add an extra value, which will add an extra bit only if the type you're talking about *exactly* uses up all the bit patterns. Initializing all access types to "null" is pretty much the same technique -- except it doesn't detect *reads* of null pointers, but just *dereferences* of null pointers. Does the "systems programmer in you" find this ludicrously expensive? It is, in fact, expensive, in some cases. For example, I recently profiled a program I wrote, and found that it spent most of it's time initializing arrays-of-access to null values! On the other hand, it does detect some bugs. For an integer type that doesn't exactly match the hardware supported bounds (e.g. type T is range 1..1_000_000), there's no need to add an extra bit. I once used a Pascal compiler where type Integer was defined to be -2**31..2**31, and the extra value -2**31-1 was used to detect uninitialized variables. This was quite useful. If my program had been too slow, I might have wanted a way to turn this feature off. But it wasn't. Also, if my program had wanted to interface to the actual hardware notion of a 32-bit integer, I might have wanted a way to turn it off. Run-time detection of uninitialized variables is useful, but has some cost. It seems to me that only the application programmer can reasonably make this trade-off. The cost is different, depending on various properties of the application, and whether the cost is tolerable also depends on the application. (For a packed array of Booleans, adding an extra "uninit" value *doubles* the size of the array!) - Bob