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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3254d965945d603a,start X-Google-Attributes: gid103376,public From: geert@fozzie.sun3.iaf.nl (Geert Bosch) Subject: How to prevent 'Unchecked_Access Date: 1996/10/22 Message-ID: <54jarn$1rp@fozzie.sun3.iaf.nl>#1/1 X-Deja-AN: 191441059 organization: La Calandre Infortunee newsgroups: comp.lang.ada Date: 1996-10-22T00:00:00+00:00 List-Id: OK, as long as there is no GC for GNAT I'd like to use the stack whereever I can to prevent errors in memory management. Sadly enough there are many times I need to pass access types to procedures at library level, notably OS and GUI libraries. Although I understand the use of Ada-95 accessibility levels to prevent dangling pointers (dangling access objects???), there are many times Unchecked_Access is necessary to pass parameters to a subprogram that is known not to secretly store it somewhere for later reuse. Isn't there a way to express this safe behavior at the subprogram, so they can be used without using Unchecked_Access. A pragma specifying that an access-type parameter is limited would seem logical. For those who might think that this question falls into the category "how do I turn this screw without using the screwdriver", I'd like to point out that the situation I describe doesn't have to be "Unchecked". Subprograms that take these limited access types as parameters can be checked at compile time so there is nothing Unchecked taking place. Reserving a dangerous feature for places which *are* potentially dangerous is better IMHO that using it all over the place. Of course specifying the pragma for imported C functions is potentially unsafe, but importing C functions was unsafe already. I'm very interested in your opinions on this. -- E-Mail: geert@sun3.iaf.nl