Forum: Public Review
References: DEFSTRUCT (p308), MAKE-ARRAY (pp287-288)
Moon's public review comment #3 (X3J13/92-3203)
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
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
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.
Specify that the consequences of reading an uninitialized array
element or structure slot are undefined.
#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.
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.
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
Cost to Implementors:
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
High-safety implementations may continue to detect these problems.
Most people think it is unaesthetic to read a value which has not been
Some people think it is unaesthetic to have the language initialize
things to unspecified values.
The sections of text affected by this proposal are already flagged
in the TeX sources for the draft.
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
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".
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