Re: A hole in Ada type safety

[anon@att.net]

AdaMagica: Some times a programmer may need a only a few checks 
suppressed instead of all checks as with the RM Unchecked_Conversion 
function. Then there's the idea of creating your own function just 
like some here will say create your own version of an Integer instead 
of using the one defined in the Standard package. Now, I have one 
simple designed Unchecked_Conversion function that work for any Ada 83 
compiler, and a second version that works for any Ada 95 compiler for 
all types used in that version of the language. Include a 
"unconstrained discriminant limited private" type.

Florian Weimer: My design converts all types and I did not need to use 
aliased or tag type to add the discriminant-dependent feature. Just  
play with it a little and you will see the answer.

Note: One thing. Any and all Unchecked_Conversion function just like 
Machine_Code Insertions adds a safety risk to the party. Plus, the 
conversion functions are easier to hide in a large scale project.

This all started because of an answer that "Robert Duff" gave about about 
AARM-3.7.2(4,4.a), which refers to AI83_00585 and "Erroneous Execution".
In looking at that Ada Issue I see only a compiler design error not an 
"Erroneous Execution" error. The fix is for the compiler to add either 
two or three checks in the elaborate code depending how the compiler 
evaluate the equation, which means no "Erroneous Execution". But in 
15 plus years GNAT has not correct this compiler identifiable error which 
makes me think how many more "Erroneous Execution" has GNAT and other
Ada venders skip fixing making the language less secure.

Also, I knew that Adam and Randy were just talk!!! Makes me think that 
they are waiting for someone to create an example of the "extended return
statement" so, they can learn how to use it. Because in looking at the 
AIs for 95 and 2005 and the ACVC 3.0 there is no example of an "extended 
return statement" for any "unconstrained discriminant limited private" 
except for those that call a function. But that not always possible.

In <87tydfbtp3.fsf@mid.deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes:
>* Robert A. Duff:
>
>> Florian Weimer <fw@deneb.enyo.de> writes:
>>
>>> I don't know if this is a new observation---I couldn't find
>>> documentation for it.
>>
>> It's not new.  It is documented in AARM-3.7.2(4,4.a),
>> which dates back to Ada 83 days.
>
>Ah.  I didn't realize that call to Convert was already erroneous.
>
>It does not seem possible to extend the restrictions on 'Access
>prefixes to to subprogram parameters (due to the way controlled types
>are implemented, for example).
>
>>> Our implementation lacks the full power of Ada.Unchecked_Conversion
>>> because it does not supported limited or unconstrained types. However,
>>> it is sufficient to break type safety.
>>
>> Yes.  Anything that is erroneous necessarily breaks type safety.
>> If you look up "erroneous execution" in the index, you'll find
>> them all.
>
>My concern was that this was not explicitly labeled as erroneous. 8-)
>
>> Your comment, "This note shows that a combination of safe-looking
>> language features can be used to undermine type safety, too."
>> is the key point.  It is indeed unfortunate when "safe-looking"
>> features can be erroneous.
>
>And once there is something like this in the language, it is difficult
>to decide if a new addition (such as aliased parameters) make things
>worse or not.