Unsafe Zig Is Safer Than Unsafe Rust

Post by MaulingMonkey » Thu, Jan 25, 2018, 3:18 AM UTC

Arnavion wrote: post #59

Animats wrote: post #40

Earlier quoted context omitted.

That's for local variables. Microsoft and Linus Torvalds didn't like it, because it's a way to suddenly cause unexpected stack growth of arbitrary size. That feature was made optional in C++11, and Microsoft never implemented it.

FWIW Microsoft does have SAL annotations to do the same thing. For example fread's prototype is size_t fread( _Out_writes_bytes_(_ElementSize*_Count) void * _DstBuf, _In_ size_t _ElementSize, _In_ size_t _Count, _Inout_ FILE * _File ); https://docs.microsoft.com/en-us/visualstudio/code-quality/a...

    template  int read(int fd, char (&buf)[len]); // array size will be infered
    int read(int fd, char (&buf)[1024]); // array size must be exactly 1024

Post by steveklabnik » Thu, Jan 25, 2018, 3:42 AM UTC

klodolph wrote: post #69

stouset wrote: post #53

Earlier quoted context omitted.

This is pretty much tautological, and nobody's arguing this point. However, you have the benefit of being able to narrow your search scope to the parts of your code marked `unsafe` instead of the entire project. Most things don't need unsafe code. For the things that do, you must yourself uphold the invariant that all requirements of safety are being obeyed when transitioning out of an unsafe block. If you don't do t…

> However, you have the benefit of being able to narrow your search scope to the parts of your code marked `unsafe` instead of the entire project. I may be missing some context, but this is certainly not true in Rust. In order to understand whether an individual piece of code marked `unsafe` is actually correct, you need to examine the context in which it is run and in general you could have to examine a large sectio…

Post by dbaupp » Thu, Jan 25, 2018, 3:46 AM UTC

klodolph wrote: post #65

stouset wrote: post #56

Earlier quoted context omitted.

You have restated your position, but it is still incorrect in the context of this discussion. Even your original statement of "R be[ing] arbitrary Rust code with no 'unsafe' blocks" is problematic: any Rust code is, very unavoidably, built upon a foundation of unsafe code. It has to be , because it's running on an "unsafe" processor. And yet, any safe Rust code in the core library (barring a safeness bug) is obviousl…

> ...is obviously safely composable with any other safe Rust code precisely because it obeys safety guarantees when transitioning from unsafe to safe. And what are those safety guarantees? This is the part where I see a lot of handwaving. > ...either R + X + Y is safe or one of [X, Y] has a safety bug and is inaccurately marking an unsafe interface as safe. Correct, but the problem is that we don't have a way to iden…

Post by voidmain » Thu, Jan 25, 2018, 3:52 AM UTC

deathanatos wrote: post #63

I think the Rust is not how you should write such a code. Why not start with the struct, and cast to a void* or a char* when C code requires it? I.e., the buggy example becomes: #[derive(Copy, Clone, Debug)] #[repr(C)] struct Foo { a: i32, b: i32, } fn main() { let mut array = [Foo { a: 0x01010101i32, b: 0x01010101i32 }; 256]; let foo = &mut array[0]; foo.a += 1; } The unsafe section isn't even required, and the effe…

Post by duneroadrunner » Thu, Jan 25, 2018, 4:01 AM UTC

devit wrote: post #60

stochastic_monk wrote: post #14

Earlier quoted context omitted.

C++ largely suffers from the same problems. Often a C++ programmer can write code which relies on iterators and containers which is quite safe and difficult to mess up, while for a variety of highly-specialized applications, mixtures of packed structs, pointer arithmetic, and arbitary sequences of binary data need to be handled with utmost care. Knowing when to use which set of tools and how to safely glue them toget…

Container and iterator code is not safe at all since there is no bounds checking by default and no protection against iterator invalidation, which can both cause writes to memory outside the intended object and thus a catastrophic outcome. There is no safe subset of C/C++ unless you just don't use pointers or references at all (and refrain from using any library that is not safe which includes large parts of the stan…