Groups | Search | Server Info | Login | Register

Groups > comp.os.vms > #378179

Re: Unsafe code blocks

From cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups comp.os.vms
Subject Re: Unsafe code blocks
Date 2025-11-18 12:54 +0000
Organization PANIX Public Access Internet and UNIX, NYC
Message-ID <10fhqao$gt4$1@reader2.panix.com> (permalink)
References <10f4oi1$25lkk$2@dont-email.me> <10fbc6h$4hb$1@reader2.panix.com> <10ffsku$1233b$2@dont-email.me>

Show all headers | View raw

In article <10ffsku$1233b$2@dont-email.me>,
Simon Clubley  <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2025-11-15, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <10f4oi1$25lkk$2@dont-email.me>,
>> Simon Clubley  <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>
>>>The unsafe keyword is a hack implemented in languages that have not been
>>>designed correctly.
>>
>> Wait, Simon, tell me how you really feel.
>>
>
>Well, Simon is known to have opinions. :-)

:-D

>>>The Ada approach, of disabling checks on a specific
>>>reference to a variable instead of disabling checks within a whole block
>>>of code, is far superior.
>>
>> It's unclear to me how this is materially different.
>>
>> In Rust, blocks return the value of the last expression they
>> contain, so an `unsafe` block may refer to a single expression.
>> However, I disagree with the above in the sense that the ability
>> to introduce scope when doing something `unsafe` can be
>> incredibly useful.  But what if the expression is really a
>> statement?
>>
>> For example:
>>
>> ```rust
>> 	unsafe {
>> 	    use core::intrinsics::volatile_copy_memory;
>> 	    let src = entry.virt_page_addr() as *const arch::Page;
>> 	    volatile_copy_memory(page, src, 1);
>> 	}
>> ```
>
>And that is exactly the kind of thing I am talking about. :-)
>
>Of those three statements, only the last one appears to be the unsafe one.

This is true, but also the sort of thing where I want to
localize the scope of both the use statement, as well as `src`.

>It is also the kind of thing I was reacting to when I saw Arne's
>example and went YUCK!, YUCK!, YUCK! :-)

Heh.

>> There's no need to leak the existence of `src` or that one is
>> using the volatile memcpy intrinsic here.  I suppose could could
>> also write this as,
>
>If that is important, I would have placed the whole sequence inside a
>local block as you do below.
>
>> ```rust
>> 	{
>> 	    use core::intrinsics::volatile_copy_memory;
>> 	    let src = entry.virt_page_addr() as *const arch::Page;
>> 	    unsafe {
>> 		volatile_copy_memory(page, src, 1);
>> 	    }
>> 	}
>> ```
>
>And this example is much closer to the Ada way. Related statements still
>get checked and only one specific statement, the actual statement that is
>unsafe, has checks disabled.

Let me be clear: _all_ of those expressions get checked.  The
`unsafe` superset just lets you do a few additional things; the
contract is that you, the programmer, have some external domain
knowledge that the compiler cannot derive from the code, and you
are asserting that you have verified that the language's
requirements vis its semantics hold, since the compiler cannot
check that for you.  `unsafe` does not mean you get to violate
the language's rules; it just means that you're taking
responsibility for them when the compiler would ordinarily do
that for you.

>> etc.
>>
>>
>>>For example, this is how you do an unsafe conversion in Ada:
>>>
>>>https://adaic.org/resources/add_content/docs/95style/html/sec_5/5-9-1.html
>>
>> This example seems equivalent to an `unsafe fn` in Rust.  An
>> unsafe conversion of this nature might use `std::mem::transmute`
>> in that world.
>
>The Ada example localises the unsafe bit down to a specific operation
>within a statement, not a full statement, and certainly not a full function.

Ah, I'm being unclear, then.  In Rust, `unsafe fn` means that
the function must be _called_ from an `unsafe` block.  It does
not mean that the statements inside the function are implicitly
wrapped in an `unsafe` block (though in fairness it used to;
this was changed in, I believe, the 2024 edition of the
language).

Anyway, I think it's unfair to say that `unsafe` blocks are a
misfeature, or a sign of poor design.  In expression-oriented
languages, they're sort of size-to-fit.

	- 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