From JLS@liverpool.ac.uk Tue Aug 18 14:55:33 1992 Received: from vm.uni-c.dk by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA27349; Tue, 18 Aug 92 14:26:11 +0200 Message-Id: <9208181226.AA27349@dkuug.dk> Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R2) with BSMTP id 9311; Tue, 18 Aug 92 14:24:50 DNT Received: from UKACRL.BITNET by vm.uni-c.dk (Mailer R2.07) with BSMTP id 9604; Tue, 18 Aug 92 14:24:48 DNT Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 4641; Tue, 18 Aug 92 13:23:53 BST Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 9739; Tue, 18 Aug 92 13:23:52 BST Via: UK.AC.LIV.IBM; 18 AUG 92 13:23:48 BST Received: from UK.AC.LIVERPOOL by MAILER(4.4.t); 18 Aug 1992 13:21:08 BST Date: Tue, 18 Aug 92 12:55:37 BST From: Lawrie Schonfelder Subject: Re: (SC22WG5.156) Defect Report To: bill@amber.ssd.csd.harris.com Cc: SC22/WG5 members In-Reply-To: Your message of Mon, 10 Aug 92 13:50:51 -0400 X-Charset: ASCII X-Char-Esc: 29 On Mon, 10 Aug 92 13:50:51 -0400 bill@com.harris.csd.ssd.amber said: >> Date: Wed, 05 Aug 92 11:54:21 BST >> From: Lawrie Schonfelder >> X-Sequence: SC22WG5@dkuug.dk 156 >> X-Charset: ASCII >> X-Char-Esc: 29 > >> 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. > >I think this is a terrible idea. In most uses of pointers, the first thing >one does with the pointer is point it at something, or explicitly >initialize it to NULL. If the compiler also generates code to initialize >the pointer, then the operation is done twice. This could be extremely >crippling in an application that allocates an array of 10,000 pointers! How many of these are there going to be? > >If you want the pointer initialized, then do it yourself. Everyone >shouldn't have to pay a performance penalty because other programmers can't >be bothered to write correct programs. > >Bill Leonard >Harris Computer Systems Division >2101 W. Cypress Creek Road >Fort Lauderdale, FL 33309 >bill@ssd.csd.harris.com >--------------------------------------------------------------------------- > Q: How many lawyer jokes are there? > A: Only three. The rest are true stories. >--------------------------------------------------------------------------- If I know the pointer is there I can but If I dont because it is a component of a type whose structure is PRIVATE I dont. As a result to write correct/safe code I have to write very inefficient code that leaks memory all over the place. If pointers are initially disassociated I do not have to create them and then immediately NULLIFY them as now. This leads to some very clumsy code, particularly when list processing when a disassociated pointer is the normal end of list indicator. The inefficiency of having to set disassociated each pointer as it is created is spurious. In any system that does full garbage collection, which any high quality implementation must do. It must distinguish between not yet associated and genuinely dangling or it would be impossible to produce safe garbage collection. The cost of setting any not-yet-associated flag will be pretty much the same as setting disassociated. If you dont like initially disassociated I would settle for an additional status of not-yet-associated and some way of detecting this fact in the Fortran program. I agree with you if people are too lazy to write correct programs then they get what they deserve, but at present I cant write correct programs that are also efficient and not at all in the presence of garbage collection. Lawrie