Unsafe Zig Is Safer Than Unsafe Rust

Post by stochastic_monk » Thu, Jan 25, 2018, 4:15 AM UTC

mdip wrote: post #64

devit wrote: post #60

Earlier quoted context omitted.

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…

To be fair, I believe you and the individual you are replying to are treating the word 'safe' differently. Correct; C++ doesn't have a built-in concept of "safe" that is compiler guaranteed and anything written in that, if it isn't written defensively at literally every line of code , falls on the library consumer to handle that. Rust, CLR/JVM/interpreted languages are 'safe' because the compiler will flat out refuse…

Post by didibus » Thu, Jan 25, 2018, 5:12 AM UTC

Post by deathanatos » Thu, Jan 25, 2018, 6:08 AM UTC

dbaupp wrote: post #76

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…

While the approach you suggest usually works well, it doesn't in this case: FILE_NAME_INFO[1] uses a "flexible array member"[2] (although not the C99 version of it), of requiring a dynamically sized character array in the struct's allocation, and writing directly to the memory after a struct instance. The 'WCHAR FileName[1];' field at the end of the struct is just a placeholder to allow easy access to that character…

Post by Animats » Thu, Jan 25, 2018, 7:54 AM UTC

dbaupp wrote: post #33

Animats wrote: post #20

Earlier quoted context omitted.

Rust's approach to "unsafe" is to let the programmer do whatever they want. Having to use this for UNIX-type API calls is kind of lame. I once proposed extending C to allow talking about array sizes.[1] You'd define "read" as int read(int fd, char &buf[len], size_t len); The compiler now knows that "buf" is an array with length "len", and can check calls for "buf" being the right size. The generated code for the call…

> Rust's system for external C calls should be more like that and less about casts to raw pointers. It seems a rosy-eyed view to think that this would helping safety significantly, and would require a lot of effort: it's likely to be much lower pay-off than other things, like investing in, say, sanitizers or even just doing the work of writing safe wrappers for popular C libs, removing C FFI concerns from most people…

Post by imtringued » Thu, Jan 25, 2018, 10:07 AM UTC

jfo wrote: post #32

lossolo wrote: post #26

Zig looks very interesting. There is only TODO in memory section in documentation. From what I understand there is only manual memory management? I've seen there is a mention about custom allocators, any details? Any RAII like concept? or full manual memory management?

"Zig does not support RAII or operator overloading because both make it very difficult to tell where function calls happen just by looking at a function body." more in the 0.1.1 release notes! http://ziglang.org/download/0.1.1/release-notes.html "Zig's standard library is still very young, but the goal is for every feature that uses an allocator to accept an allocator at runtime, or possibly at either compile time or…