From JLS@liverpool.ac.uk Wed Aug 5 13:06:25 1992 Received: from vm.uni-c.dk by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA12382; Wed, 5 Aug 92 13:06:25 +0200 Message-Id: <9208051106.AA12382@dkuug.dk> Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R2) with BSMTP id 3273; Wed, 05 Aug 92 13:06:59 DNT Received: from UKACRL.BITNET by vm.uni-c.dk (Mailer R2.07) with BSMTP id 4766; Wed, 05 Aug 92 13:06:58 DNT Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 2633; Wed, 05 Aug 92 12:04:41 BST Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 6604; Wed, 05 Aug 92 12:04:40 BST Via: UK.AC.LIV.IBM; 5 AUG 92 12:04:37 BST Received: from JLS@UK.AC.LIVERPOOL by MAILER(4.4.t); 5 Aug 1992 12:04:04 BST Date: Wed, 05 Aug 92 11:54:21 BST From: Lawrie Schonfelder Subject: Defect Report To: SC22/WG5 members X-Charset: ASCII X-Char-Esc: 29 This is an attempt at a formal defect report to raise the issue of initially undefined pointers. I dont have a form 14 available so cannot structure it in the precise manner of the JTC1 directives but I hope that does not matter too much. As Defect Editor I suppose Andrew Tate is the main target of this mail. ISO/IEC JTC1/SC22/WG5 - Nxxx To:WG5 and the Defect Editor From: Lawrie Schonfelder Pointer Initialisation Defect 5-Aug-92 1 A number of members of WG5 consider that the current standard is defective due to its specification of the initial status of pointers as undefined. We believe that this defect was introduced deliberately but inadvertently in the sence that a significant proportion of both X3J3 and WG5 at the time were not fully aware of the consequeces of this decision. Subsequent analysis and example use of the language demonstrate that this will result in seriously inefficient programs or seriously unsafe programs. For this reason we believe that this defect should be corrected as soon as possible by the appropriate technical corrigendum. 2 The suggested correction to this defect is that pointers should be initially disassociated rather than undefined. In this case a pointer only ever becomes undefined as the result of a program fault and the programmer can rely on pointers in any standard conforming program having a defined status. The edits proposed below are suggested as those necessary to make this correction. 2.1 P48L10 and P51L20 After "defined." add "Prior to being associated with a target by one of these means, a pointer may appear as the argument of the ASSOCIATED function. In which case the result will be the value false." 2.2 P68L19-21 Replace "undefined" by "disassociated" Replace the next sentence by "If the object being allocated is of a derived type containing a pointer component, these pointer components of the target are created in a disassociated state." 2.3 P246L25Replace "undefined" by "disassociated" 2.4 P246L40-P247L1 Delete items (a) and (b) and renumber 2.5 P247L12-13 Replace "but undefined." by "with a target that is definable but currently undefined."