asm!("
mov eax,1 ; system call number (sys_exit)
int 0x80 ; call kernel
")
Obviously both are equally unsafe, also obviously both are extremely rare and not "large parts" of any program whatsoever (unless you're writing your program directly in assembly).
If you mean using the wrapper libraries that typically wrap system calls. Rust removes all sorts of possible fuckups. For instance in C one might write
ssize_t bytes = read(some_file, buf, nbyte);
and if buf is null or a dangling pointer or nbyte is greater than the size of the allocation of buf you get undefined behavior. Or if afterwards you write
printf("%s", buf);
and you forgot that read doesn't necessarily return a null terminated string you get undefined behavior. And so on and so forth.
In rust you would write something like
let mut buf = [0; nbyte];
let bytes = some_file.read(&mut buf)?;
and buf can't possibly be null or dangling and you can't possibly have messed up the length of the array because the abstractions checked that for you.
Afterwards if we were to write
println!("{}", buf);
Well it will fail to compile... because buf isn't a string... and doesn't otherwise implement Display. But if we were to try to match the C code exactly and write one of
the second one would return an error if it wasn't a utf8 string, but neither would ever result in undefined behavior/security vulnerabilities.
(And yes, both of those are probably bugs in most programs, since you probably want to print buf[.. bytes] not buf. But bugs aren't security vulnerabilities. Also in real code I expect you would use read_to_string() if you were going to print it, which eliminates this potential bug too)
If you mean using the wrapper libraries that typically wrap system calls. Rust removes all sorts of possible fuckups. For instance in C one might write
and if buf is null or a dangling pointer or nbyte is greater than the size of the allocation of buf you get undefined behavior. Or if afterwards you write and you forgot that read doesn't necessarily return a null terminated string you get undefined behavior. And so on and so forth.In rust you would write something like
and buf can't possibly be null or dangling and you can't possibly have messed up the length of the array because the abstractions checked that for you.Afterwards if we were to write
Well it will fail to compile... because buf isn't a string... and doesn't otherwise implement Display. But if we were to try to match the C code exactly and write one of the second one would return an error if it wasn't a utf8 string, but neither would ever result in undefined behavior/security vulnerabilities.(And yes, both of those are probably bugs in most programs, since you probably want to print buf[.. bytes] not buf. But bugs aren't security vulnerabilities. Also in real code I expect you would use read_to_string() if you were going to print it, which eliminates this potential bug too)