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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,daf1e35a4e978e9d X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-20 10:12:11 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeed.belnet.be!news.belnet.be!ossa.telenet-ops.be!skynet.be!skynet.be!news.csl-gmbh.net!newsfeed01.sul.t-online.de!t-online.de!newspeer1-gui.server.ntli.net!ntli.net!news6-win.server.ntlworld.com.POSTED!not-for-mail From: "chris.danx" Newsgroups: comp.lang.ada References: <0x8Q8.6779$ZP1.1263481@news11-gui.server.ntli.net> <5ee5b646.0206200805.7c4be786@posting.google.com> Subject: Re: have to use unrestricted access but just what about access X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: Date: Thu, 20 Jun 2002 18:11:38 +0100 NNTP-Posting-Host: 80.5.140.234 X-Complaints-To: abuse@ntlworld.com X-Trace: news6-win.server.ntlworld.com 1024593127 80.5.140.234 (Thu, 20 Jun 2002 18:12:07 BST) NNTP-Posting-Date: Thu, 20 Jun 2002 18:12:07 BST Organization: ntl Cablemodem News Service Xref: archiver1.google.com comp.lang.ada:26501 Date: 2002-06-20T18:11:38+01:00 List-Id: "Robert Dewar" wrote in message news:5ee5b646.0206200805.7c4be786@posting.google.com... > The referenced post in this thread is an excellent lesson > in when how to seriously misuse the Unrestricted_Access > attribute. I wasn't comfortable with Unrestriced_Access anyway, so the code was changed it earlier today not to use Unrestricted_Access... type Dot_Window is new Gwindows.Windows.Main.Main_Window_Type with record Drawing_Surface : Gwindows.Drawing_Panels.Drawing_Panel_Access := null; Key_Coordinator : Dot_Key_Coor.Coordinator_Access := null; Watcher : Dot_Key_Watcher.Watcher_Access := null; Builder : Dot_Builder.Builder_Access := null; end record; Everything is dynamically allocated and if at any point an allocation fails, the program is terminated (after tidying up of course)! If you have a suggestion as to how to improve the mechanism by which the two tasks communicate I'd gladly listen. > But even a cursory examination of this code will show > that it is very likely to generate a dangling pointer. The tasks which use the protected object are terminated (and deallocated) before the protected object itself, so there should be no dangling pointer. I always make a point of noting where anything is allocated and under what circumstances they should be deallocated.