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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,a88e582de42cdc9b X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!b29g2000hsa.googlegroups.com!not-for-mail From: billjones6789@yahoo.com Newsgroups: comp.lang.ada Subject: Re: Bug in Ada (SuSe 10.2) ? Date: Sat, 23 Feb 2008 02:16:14 -0800 (PST) Organization: http://groups.google.com Message-ID: <630afe6a-8bcb-460a-96c1-089eb0b331f8@b29g2000hsa.googlegroups.com> References: <0_mdna0iHpIsCifaRVnzvQA@telenor.com> <47ba9867$0$21892$4f793bc4@news.tdc.fi> <3a281192-2744-4110-9fc1-90c155c9436b@d4g2000prg.googlegroups.com> <48277611-402f-4622-be05-6edddf6dd56a@o10g2000hsf.googlegroups.com> <624tcvF21i3nvU1@mid.individual.net> <2630d99b-1578-4d79-ac9c-64c00c203b77@e60g2000hsh.googlegroups.com> <69019a65-736e-48ee-bd9f-4c29cd7fc88f@72g2000hsu.googlegroups.com> <1203708110.6651.7.camel@K72> NNTP-Posting-Host: 75.51.80.135 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1203761774 21625 127.0.0.1 (23 Feb 2008 10:16:14 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 23 Feb 2008 10:16:14 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: b29g2000hsa.googlegroups.com; posting-host=75.51.80.135; posting-account=EwprVAoAAADupkeB7R-LUjsi4Ab2CUvf User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0),gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:20016 Date: 2008-02-23T02:16:14-08:00 List-Id: On Feb 22, 11:21=A0am, Georg Bauhaus wrote: > On Fri, 2008-02-22 at 08:10 -0800, billjones6...@yahoo.com wrote: > > Of course, the danger is only eliminated when this language-defined > > check is fully implemented in standard mode. > > Here is another dangling pointer. The program is > giving me results varying with compiler/OS. I didn't see > how accessiblity checks could help in this case, but > then maybe this is a different issue? > > with Ada.Unchecked_Deallocation; > with Ada.Text_IO; > > procedure News3 is > =A0 =A0use Ada; > > =A0 =A0type Int_Ptr is access Integer; > =A0 =A0Pointer: Int_Ptr; > =A0 =A0Dangling_Pointer: Int_Ptr; > > =A0 =A0procedure Copy(Source: in out Int_Ptr; Target: out Int_Ptr) is > =A0 =A0 =A0 procedure Oops is new Unchecked_Deallocation > =A0 =A0 =A0 =A0 (Integer, Int_Ptr); > =A0 =A0begin > =A0 =A0 =A0 Target :=3D Source; > =A0 =A0 =A0 Oops(Source); > =A0 =A0end Copy; > > begin > =A0 =A0Pointer :=3D new Integer'(42); > =A0 =A0Copy(Pointer, Dangling_Pointer); > > =A0 =A0Text_IO.Put_Line(Integer'image(Dangling_Pointer.all)); > end News3; Yes, this is a different issue, and accessibility checks unfortunately don't help in this case. The checks work for pointers into the stack (objects declared inside subprograms where 'access is used), not objects allocated on the heap (where allocators (new) are used). There are various methods available to detect such errors, such as using the valgrind tool or special debug storage pools.