Groups | Search | Server Info | Login | Register

Groups > comp.os.vms > #378198

Re: Unsafe code blocks

Show all headers | View raw

In article <10flqou$2l1qc$1@dont-email.me>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:
>On 11/19/2025 11:02 AM, Dan Cross wrote:
>> In article <10fig0p$1n41a$2@dont-email.me>,
>> Arne Vajhøj  <arne@vajhoej.dk> wrote:
>>> On 11/15/2025 9:16 PM, Dan Cross wrote:
>>>>> Also note the availability of the 'Valid attribute to make sure that what
>>>>> is in the variable after the unsafe conversion is actually a valid value.
>>>>
>>>> Sum types make this trivial:
>>>>
>>>>       impl SomeType {
>>>>           fn try_from(i: i32) -> Option<Self> {
>>>>               // if valid, return `Some(whatever`),
>>>>               // else return `None`.
>>>>           }
>>>>       }
>>> (assuming Option in Rust is what it is in other languages)
>>>
>>> Option and Ada Valid are somewhat different.
>>>
>>> Option is a way for a function/method to either return
>>> a value or return the fact that there is no value.
>>>
>>> A much better way to do that than traditional
>>> return null or -1 or whatever to indicate there
>>> is no value.
>>>
>>> Ada valid attribute is a runtime check on the result from
>>> an unsafe conversion to see if it meets the constraints
>>> of the data type.
>> 
>> I'm afraid this misses the point.
>> 
>> If a language supports sum types, then general solutions like
>> `Option` or `Result` types can be employed to represent the
>> return type of the conversion operation.  If the conversion is
>> invalid, then one returns `None` (or, perhaps, the `Err` variant
>> of a `Result` if one wants to capture what the actual failure
>> was).  That is, the conversion operation itself subsumes the
>> functionality of the valid attribute, and both the value and
>> whether the conversion was valid are represented in the return
>> type.
>> 
>> Again, taking Rust just as an example, there is a standard way
>> to represent such conversions; the `TryFrom` trait (and it's
>> dual, `TryInto`).  Consider this silly example problem: I have a
>> type representing colors; perhaps the only colors I care about
>> are Red, Green, and Blue. I can label these with integers, say
>> 1, 2 and 3, and I can represent this in Rust using an
>> enumeration.
>> 
>> Now further suppose that I have a file of 8-bit bytes that
>> contain the (raw, integral) representation of these color
>> values; I'd like to convert these into proper objects of the
>> enumeration type, but of course, not all 8-bit byte values
>> represent valid colors, so the proper tool in this case is
>> `TryFrom`.  Note, however, that converting back, from a color to
>> its 8-bit value, is _always_ valid, so I just use `From` in that
>> case (which also, conveniently, gives me `into`).
>
>> #[derive(Clone, Copy, Debug, Eq, PartialEq)]
>> enum Colors {
>>      Red = 1,
>>      Green = 2,
>>      Blue = 3,
>> }
>> 
>> impl TryFrom<u8> for Colors {
>>      type Error = String;
>>      fn try_from(raw: u8) -> Result<Self, Self::Error> {
>>          match raw {
>>              1 => Ok(Self::Red),
>>              2 => Ok(Self::Green),
>>              3 => Ok(Self::Blue),
>>              _ => Err(format!("unsupported value '{raw}'")),
>>          }
>>      }
>> }
>
>> Note the unit tests.  Note also, that, as a result of the way
>> that the conversion is structured, as aided by the return type,
>> the conversion operation itself is safe.
>> 
>> Of course, this example is trivial, but the same principle
>> applies for more comple conversions as well, including unsafe
>> conversions.
>> 
>> Further, by localizing the unsafety inside of the conversion,
>> and using a return type that can represent failure, one can
>> construct a _safe_ interface to do _unsafe_ conversions.
>
>> In contrast, `Valid` is easy to misuse, primarily by not using
>> it at all, in which case you run the risk of raising a runtime
>> exception, or just having an incorrect program.  With either
>> `Option` or `Result`, you are forced to contend with the error
>> case.  The programmer can't forget to check.
>> 
>> Finally, `Valid` is very limited in its applicability: it can
>> only be used with scalar types.  At least in Rust, `Option` and
>> `Result` are generic over essentially arbitrary types.
>> 
>> Put another way, if the language supports something like an
>> `Option` type, then there is no need for a special-case facility
>> like Ada's `Valid` attribute.
>
>All fine.
>
>But you can do the same in Ada.

Indeed, you can, but I never said you couldn't.   My point was
that Ada's `Valid` attribute is overly specific, underpowered,
and ultimately unnecessary in a language that supports proper
sum types over generics.  Ada's `Valid` attribute is neither as
general nor as robust as using an ADT like
Option/Result/Maybe/whatever it's called in any given langauge.

>Both doing similar to above and by using Unchecked_Conversion
>and Valid.
>
> [snip code segment for brevity]
>
>A bit verbose. But if one want short code, then
>Ada is not the right language choice.

Also not as general.  Note that in the Rust example, `Option` is
generic over some type `T`: your example is concrete over the
color enum, and just colocates it with a flag and a convenience
method that returns null if the flag is false (but now all
accesses are via reference).  As a simulacrum, it will serve,
but one could do that in any number of languages; even C with a
couple of accessor functions can do something similar.

But Ada supports generics (recall that Stepanov did the first
implementation of the STL in Ada).  You could use that to build
an actual `Option` type that would closer to the Rust version.
It would probably not be as convenient to use because Ada lacks
Rust-style pattern matching and destructuring, but it would more
or less obviate the need for `Valid`.

>I am printing instead of asserting, because assertions was first
>to Ada 20 years ago and the VMS GNAT I have is over 25 years old.

Fortunately, Generics have been in the language since the 80s.
:-D

	- Dan C.

Back to comp.os.vms | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Unsafe code blocks Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-13 14:04 +0000
  Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-13 15:44 -0500
  Re: Unsafe code blocks Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> - 2025-11-14 12:14 +0100
    Re: Unsafe code blocks John Reagan <johnrreagan@earthlink.net> - 2025-11-14 11:47 -0500
      Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-14 14:02 -0500
        Re: Unsafe code blocks Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> - 2025-11-17 09:25 +0100
          Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-17 14:58 -0500
            Re: Unsafe code blocks Chris Townley <news@cct-net.co.uk> - 2025-11-17 20:11 +0000
              Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-17 15:47 -0500
            Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-18 13:10 +0000
      Re: Unsafe code blocks Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-14 19:32 +0000
    Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-14 13:55 -0500
      Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-14 20:00 -0500
        Re: Unsafe code blocks Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-17 18:56 +0000
          Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-17 14:22 -0500
  Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-16 02:16 +0000
    Re: Unsafe code blocks Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-17 19:22 +0000
      Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-17 14:55 -0500
        Re: Unsafe code blocks Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-17 20:33 +0000
          Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-17 15:55 -0500
      Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-18 12:54 +0000
    Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-18 14:04 -0500
      Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-18 14:07 -0500
        Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-19 16:12 +0000
          Re: Unsafe code blocks Michael S <already5chosen@yahoo.com> - 2025-11-19 19:29 +0200
            Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-19 19:00 +0000
          Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-19 12:41 -0500
            Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-19 18:19 +0000
              Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-19 14:21 -0500
                Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-19 19:49 +0000
      Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-19 16:02 +0000
        Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-19 20:26 -0500
          Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-19 20:31 -0500
          Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-19 21:32 -0500
          Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-20 11:54 +0000
            Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-20 19:18 -0500
              Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-21 03:03 +0000

csiph-web