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: 152644605 distribution: usafa references: <318508FE.204B@sanders.lockheed.com> <3188AF51.1F1A7590@escmail.orl.mmc.com> <4matk0$4k@usafa2.usafa.af.mil> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-05-02T00:00:00+00:00 List-Id: In article <4matk0$4k@usafa2.usafa.af.mil>, Chris Warack wrote: >Unfortunately, that's about the only option possible. However, it's not >as gloomy as it might seem. First, a clarification -- need a dirty bit >for each "object" not each variable (i.e., it has to handle "heap" data >as well as "stack" data). Well, that's not really a "clarification". Heap data is variables, too. In Ada, "object" means "variable or constant". It has nothing to do with whether the thing is stack-allocated or heap-allocated. (Sorry for being pedantic, after ranting about "Ada" vs. "ADA" pedants. ;-) ) Presumably, any rule that prevents reads of uninitialized variables would prevent uninitialized constants from existing at all (so no checks would be required on reading a constant), because all constants are initialized with some expression, and if *that* expression is a read of an uninit var, it would raise an exception. But a method that works for declared variables ought to work for heap variables, too. It seems silly to have a run-time method that works only for stack variables, since that's the case that can *often* be detected at compile time. >... Second, the bit doesn't have to be part of the >object (although adding such a flag as part of an ADT or class definition >is a simple way for the user to gain this feature). As I said elsewhere, you don't usually need an entire extra bit for this. "type T is range 1..1_000_000;" fits in 32 bits. If you add an extra value for this sort of checking, it *still* fits in 32 bits. Not making it part of the object is possible, but complicated, and probably less efficient. >... You could think of >this check as something like the elaboration check. I.e., grossly inefficient and disgusting? ;-) >The advantage of having this in the language is that the compiler may be >able to optimise these checks away whereas if the user codes them, this >becomes difficult. The reason is that the compiler could do the checks >as part of "calling" an operation and therefore determine from the calling >context whether the object was initialized or not. The user code would >be in the implementation of the operation and could not benefit from the >calling context. I'm not sure what you're saying here. Note that Ada defines a read of an uninit *scalar* variable to be wrong, but not a read of an uninit composite. And that's good. Consider a record containing an array of integers, plus the index of the last-used element. It is (and should be) perfectly OK to pass that thing as a parameter, or assign "X:=Y", even though the integers past the last-used one are uninitialized. >The extra time these checks would add is probably not worth it in many (most) >arenas. But, if they existed, a pragma Supress(Initializion_Checks) could >turn them off. I suppose that having them off by default may be best and >a pragma Initialization_Checks would turn them on. Of course, this second >approach could be implementated right now as vendor-dependent pragma... The first could, too. A vendor is allowed to define implementation-defined check names that can be used in pragma Suppress. So, a vendor could check (scalar) variables for uninitialized access, and raise an exception in that case, and allow pragma Suppress to turn it off. (However, a vendor has to support packing -- e.g. a packed array of Boolean has to take 1 bit per component.) - Bob