hamcocar
Joined 1 year ago
Karma
-4
Submissions
5
Member since
Jul 10
Recent submissions
Comment · 1 year ago
Comment · 1 year ago
I am very sorry, but your arguments here are terrible.
Unless casting or type punning through unions are used, the type system should help a lot in terms of avoiding using pointers to types that are not compatible in C. And then special care can be taken in any cases where casts are used. C++ is probably better at avoiding type casts, with all the abstractions it has.
This is different from no aliasing of Rust, where mutable references of even the same type may not alias.
Your own tool, Miri, reports that this fairly simple code snippet is UB, even though it is only the raw pointer that is dereferenced, and "a2" is not even read after assignment.
https://play.rust-lang.org/?version=stable&mode=debug&editio...
And you know better than me that Miri cannot handle everything. And Miri is slow to run, which is normal for that kind of advanced tool, not a demerit against Miri but against the general kind of tool it is.
I am very surprised that you come with arguments this poor.
Comment · 1 year ago
>Yeah, concurrency bugs that only occur in very specific situations are hard to track down with a pure testing tool.
It would have been better to have prevented it in the first place, and it is inconsistent with "fearless concurrency" when the Rust stdlib has UB.
And there are categories of cases that Miri does not handle either, FFI being a clear example as far as I know.
Comment · 1 year ago
I think that way of describing it is really weird.
In C, you do not use any special keywords to opt into or opt out of TBAA, instead it is the rule by default that one must follow. I do not consider that 'opting out'. One can disable that in some compilers by disabling 'strict aliasing', as the Linux kernel does, but that is usually on a whole-program basis and not standard.
In Rust, using raw pointers is using a different mechanism, and mutable references are always 'no aliasing'.
An example of opting in would be C's "restrict" keyword, where one opts into a similar constraint to that of Rust's 'no aliasing' for mutable references.
>use raw pointers (or interior mutable shared references) for all accesses, and you can stop worrying about aliasing altogether.
And dereferencing a raw pointer requires 'unsafe', right? And if one messee the rules up for it, theN UB.
Can you confirm that the interaction between raw pointers and mutable references still requires care? Is this comment accurate?
>It is safe to hold a raw pointer, const T or mut T, at the same time as a mutable reference, &mut T, to the same data. However, it is Undefined Behaviour if you deference that raw pointer while the mutable reference is still live.
Comment · 1 year ago
I am very sorry, but you do not address that TBAA, like C has by default, generally is easier than just no aliasing, like what Rust has for mutable references. This is a major difference. C code can opt into a similar kind of aliasing, namely by using _restrict_, but that is opt-in, while it is always on for Rust.
And there is newer UB as well in Rust stdlib
How is your comment consistent with some C compilers enabling users to disable TBAA/strict aliasing? Like the Linux kernel does. Do those codebases fit "compile to a very surprising series of instructions,"?