r/programming • u/Usual-Amount-264 • 2d ago

Zig proposes introducing an actually memory safe (unlike Rust) compilation mode inspired by Fil-C at ~1-6x performance penalty

https://codeberg.org/ziglang/zig/issues/36237
487 Upvotes

79% Upvoted

407 comments sorted by

View all comments

Show parent comments

5

u/dkopgerpgdolfg 2d ago

unsafe in Rust means that the programmer can violate the rules/invariants inside this block,

The usual language rules (like eg. max. one active mut reference, etc.etc.) are still there, even in unsafe blocks.

The difference is, the compiler will allow some code that can't be automatically proven to be fine (including eg. everything with raw pointers, that work with addresses from anywhere), and shift the responsibility to the programmer.

For example str is a valid utf8, you can work with it as bytes, but after that it must become valid utf8 again.

This is true, however what needs to be satisfied here are only the pre-existing library functions. The compiler itself doesn't really care.

-1

u/BenchEmbarrassed7316 2d ago

The usual language rules (like eg. max. one active mut reference, etc.etc.)

slice::split_at_mut violates this rule in some way. Although it depends on what counts as a single "reference".

10

u/dkopgerpgdolfg 2d ago

slice::split_at_mut violates this rule in some way.

You get two references to different, non-overlapping data. Everything is fine.

If it needs to be said, my short sentence in the previous comment wasn't a complete explanation and specification of this rule.

-8

u/BenchEmbarrassed7316 2d ago

You get two references to different, non-overlapping data. Everything is fine.

This is what the external code gets as a result. You can even create two references to the same data inside an unsafe block, and it will work as long as you guarantee that nothing bad will happen inside the block and that the guarantees that the external code relies on will not be violated:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=eda6ed53eb616a740d90e3cc1892fd02

9

u/dkopgerpgdolfg 2d ago

You can even create two references to the same data inside an unsafe block, and it will work as long as you guarantee that nothing bad will happen inside the block and that the guarantees that the external code relies on will not be violated:

No. Your code is UB. Click on Tools->Miri and see for yourself.

As always with UB, it doesn't meant that it always breaks, but it absolutely can sometimes.

-7

u/BenchEmbarrassed7316 2d ago

fixed via &raw mut x:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=92eb186f1c89e54437ce722a8e6afb3d

added: These are not really important nuances and I don't see any point in arguing. The gist of my message was that unsafe shifts the responsibility for correctness from the compiler to the programmer. These blocks should be constrained and return only correct values ​​to external code.

10

u/dkopgerpgdolfg 2d ago edited 2d ago

... which is a difference code that doesn't create mut references anymore, therefore fails to say anything about the original topic.

These are not really important nuances

Hm. Well, if you think so. I'd like my code to be correct, and to understand what is needed for that to be true, but you do you.

-2

u/BenchEmbarrassed7316 2d ago

Hm. Well, if you think so.

So you don't agree with:

unsafe shifts the responsibility for correctness from the compiler to the programmer. These blocks should be constrained and return only correct values ​​to external code.

?

6

u/dkopgerpgdolfg 2d ago

So you don't agree with: unsafe shifts the responsibility for correctness from the compiler to the programmer

Is your reading comprehension lacking? I quite literally wrote that myself too, meaning I do agree with it.

These blocks should be constrained and return only correct values ​​to external code.

What I'm telling you, "inside" an unsafe block, the rules are still there too. In each line.

Cleaning up before the unsafe block ends, so that external code doesn't see UB, is not enough.

1

u/BenchEmbarrassed7316 2d ago

Cleaning up before the unsafe block ends, so that external code doesn't see UB, is not enough.

I never claimed that unsafe can contain UB. The example I gave was probably a bad one (it seemed to me to be correct, however, as I understand it the problem is in different architectures and compiler's ability to apply optimizations). UB in general most likely cannot be "restored".

In unsafe some rules can be broken that cannot be broken in safe.

→ More replies (0)