Issue UNINITIALIZED-ELEMENTS Writeup

Forum:		Public Review

Issue:        UNINITIALIZED-ELEMENTS

Forum:	      CLEANUP

References:   DEFSTRUCT (p308), MAKE-ARRAY (pp287-288)

	      Moon's public review comment #3 (X3J13/92-3203)

	      Issue BOA-AUX-INITIALIZATION

Category:     CLARIFICATION

Edit history: 24-Jun-91, Version 1 by Hornig

	      12-Aug-91, Version 2 by Pitman (flesh out Problem Description

	        and Examples, light editing of other sections, add endorsement)

	      20-Dec-92, Version 3 by Loosemore (update writeup to reflect

		draft 12.24; proposal is unchanged)

	      08-Jan-93, Version 4 by Loosemore (more comments from Moon)

Status:	      Version 2 failed 4-5-1 at Dec 1991 meeting

              Version 4 passed 9-0-0 at Mar 1993 meeting



Problem Description:


 CLtL says of ARRAY element initial values (p287):


   If the :initial-element option is omitted, the initial 

   values of the array elements are undefined (unless the

   :initial-contents or :displaced-to option is used.)


   [Similar remarks are made for :initial-contents and

    :displaced-to.]


 CLtL says of DEFSTRUCT slot initial values (p308):


   If no default-init is specified, then the initial contents 

   of the slot are undefined and implementation-dependent.


 From this wording, the draft specification (12.24) has chosen to say that

 uninitialized array elements have an "implementation-dependent value", 

 but that "the consequences are undefined" if an attempt is made to read 

 an uninitialized structure slot.  


 Aside from the inconsistency being a source of confusion, the language

 in the array section would seem to prevent implementations from

 diagnosing references to uninitialized array slots in high-safety code,

 something that would be very helpful in debugging.



Proposal UNINITIALIZED-ELEMENTS:CONSEQUENCES-UNDEFINED:


 Specify that the consequences of reading an uninitialized array

 element or structure slot are undefined.


Test Case:


 #1: (LENGTH (LIST (AREF (MAKE-ARRAY 1) 0)))


     returned 1 under CLtL and draft 12.24

     but has undefined consequences under this proposal.

     


 #2: (DEFSTRUCT (KONS (:CONC-NAME "") (:CONSTRUCTOR KONS)) KAR KDR)

     (LENGTH (LIST (KAR (KONS))))


     returned 1 under CLtL 

     but has undefined consequences under draft 12.24 and this proposal.


Rationale:


 This change will permit, but not require, an implementation to detect

 reading of uninitialized values.  Reading an uninitialized value usually

 indicates a programming error.  Implementations which wish to ease

 debugging may detect this error and report it to the user.


 Implementations are already required to detect references to

 uninitialized symbol value and function cells in high safety mode,

 and to uninitialized slots in objects of types STANDARD-OBJECT 

 and CONDITION in all safety modes.


Current Practice:


 Symbolics currently initializes uninitialized array elements to a

 type-dependent value.  Symbolics currently detects references to

 uninitialized structure slots and calls the SLOT-UNBOUND generic

 function.


Cost to Implementors:


 None.


Cost to Users:


 This change might affect user programs which read uninitialized slots

 but then do absolutely nothing with the value (such as those in the

 Examples section).  In pracitce, there probably aren't a lot of

 programs with that property.


Cost of Non-Adoption:


 Users will not be able to detect this important class of programming

 errors reliably.


Benefits:


 High-safety implementations may continue to detect these problems.


Aesthetics:


 Most people think it is unaesthetic to read a value which has not been

 initialized.


 Some people think it is unaesthetic to have the language initialize 

 things to unspecified values.


Editorial impact:


 The sections of text affected by this proposal are already flagged

 in the TeX sources for the draft.


Discussion:


 Hornig, Pitman, Moon, and Loosemore have expressed support for some

 version of this proposal.


 Version 2 of this proposal failed by a narrow margin at the December 

 1991 meeting, but the same issue was raised again by Moon's public review

 comment #3.


 According to Kent Pitman, the current inconsistency arose because some 

 people were concerned that "implementations might have to blow out in

 the printer when someone did (MAKE-ARRAY 4)".  But various people wanted 

 reading uninitialized structure slots to have undefined consequences 

 because "the presence of CLOS and STRUCTURE-CLASS and SLOT-UNBOUND

 implies that it is reasonable for an implementation to call SLOT-UNBOUND

 and for SLOT-UNBOUND to signal an error when such a slot is accessed".


 Moon says:

  I don't see anything in the standard that requires the printer to

  "blow out" when printing an object for which there are applicable

  functions that have undefined consequences.  After all, the printer is

  not (required to be) a portable program and is not required to call

  any particular functions (except for PRINT-OBJECT on instances of

  user-defined classes).