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,4c459ff0adb576bc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-02-22 06:38:05 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!newsfeed.cwix.com!newscon02.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr30.news.prodigy.com.POSTED!not-for-mail From: "Pat Rogers" Newsgroups: comp.lang.ada References: <3C5AB0B7.9D75D49A@grammatech.com> <3c639940@pull.gecm.com> <4519e058.0202080714.1bf916bb@posting.google.com> <3C65BFF4.F15A07D0@earthlink.net> <3C7324BF.996E182B@adaworks.com> Subject: Re: Refactoring and Ada X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: NNTP-Posting-Host: 208.191.180.40 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr30.news.prodigy.com 1014388648 ST000 208.191.180.40 (Fri, 22 Feb 2002 09:37:28 EST) NNTP-Posting-Date: Fri, 22 Feb 2002 09:37:28 EST Organization: Prodigy Internet http://www.prodigy.com X-UserInfo1: OP]QRACE[BWMQ_H]]ZN@_TDAYZOZ@GXOXZ\@LWQHBATBTSUBYFWEAE[YJLYPIWKHTFCMZKVMB^[Z^DOBRVVMOSPFHNSYXVDIE@X\BUC@GTSX@DL^GKFFHQCCE\G[JJBMYDYIJCZM@AY]GNGPJD]YNNW\GSX^GSCKHA[]@CCB\[@LATPD\L@J\\PF]VR[QPJN Date: Fri, 22 Feb 2002 14:37:28 GMT Xref: archiver1.google.com comp.lang.ada:20251 Date: 2002-02-22T14:37:28+00:00 List-Id: "Randy Brukardt" wrote in message news:u78hac6o7iku15@corp.supernews.com... > >No, I was asking for the exegesis in terms of the RM for Richard's much > more sweeping "comdemnation" of the attribute. ("Condemnation" is too > strong here, but you get the idea.) > > Reading AI-167 might help some > (http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00167.TXT?rev=1.5). > But this AI is still under construction (it is not, and never has been, > approved, contrary to the statement of someone else here), and > undoubtably will change. > The problem rule is 13.9.1(12), which makes the CALL to > Unchecked_Conversion erroneous if the result is invalid. And this rule > is intended (I forget why, Bob?). Thanks (again) for the pointer to the AI in progress. Clearly there is a problem for unchecked conversion in this case. However, unchecked conversion isn't the only way to get the value to which 'Valid is applied. For example, via RM 13.9.2(11): P : aliased Positive; K : Integer; for K'Address use P'Address; begin K := 0; if P'Valid then ... or, for that matter, via System.Address_To_Access_Conversions (for Integer in this example). The OP's saying that 'Valid is useless isn't justified by the problem with unchecked conversion, IMHO. What am I missing? Pat