may_alias (thread separated from another one)
- KVRist
- 347 posts since 20 Apr, 2005 from Moscow, Russian Federation
And speaking of Rust: https://doc.rust-lang.org/reference/beh ... fined.html
Does not look much better considering the 30 years (actually 40 counting it's not ready yet) of difference in age.
Does not look much better considering the 30 years (actually 40 counting it's not ready yet) of difference in age.
-
- KVRAF
- 1606 posts since 12 Apr, 2002
At the first sight also doesn't look good, but actually difficult to judge without really knowing the language, as there might be clear ways to express the things differently.Max M. wrote: ↑Wed Feb 20, 2019 9:41 am And speaking of Rust: https://doc.rust-lang.org/reference/beh ... fined.html
Does not look much better considering the 30 years (actually 40 counting it's not ready yet) of difference in age.
-
- KVRAF
- Topic Starter
- 2256 posts since 29 May, 2012
It actually looks better because these undefined behaviors are about unsafe blocks, not about everything written in Rust.
There is no argument against the idea that a language designed today has a chance of being better than a 30 years old one. The problem is modifying C++ slowly, breaking a few old rules here and there, and hope that the end result someday might look like the way everybody would wish it to be, like saying "we are going to annoy everybody at each new version of the C++ standard, but the end will some day justify the means".
There is no argument against the idea that a language designed today has a chance of being better than a 30 years old one. The problem is modifying C++ slowly, breaking a few old rules here and there, and hope that the end result someday might look like the way everybody would wish it to be, like saying "we are going to annoy everybody at each new version of the C++ standard, but the end will some day justify the means".
~stratum~
- KVRAF
- 7867 posts since 12 Feb, 2006 from Helsinki, Finland
I don't think the standards mandate a particular value for the null pointer, I don't think they even mandate that a pointer stores a memory address. Rather they just mandate that you can assign the integer value zero to a pointer to make it a null pointer, which is some distinct value. That's about as far as you can get without invoking UB.
- KVRist
- 347 posts since 20 Apr, 2005 from Moscow, Russian Federation
stratum
these undefined behaviors are about unsafe blocks, not about everything written in Rust.
Except that typecasting like `int64* <-> double*` is exactly the mentioned `unsafe` code: https://doc.rust-lang.org/std/mem/fn.transmute.html
Thus (as far as I understand it) all these UBs will happily apply to our 2^x implementation it all began with.
these undefined behaviors are about unsafe blocks, not about everything written in Rust.
Except that typecasting like `int64* <-> double*` is exactly the mentioned `unsafe` code: https://doc.rust-lang.org/std/mem/fn.transmute.html
Thus (as far as I understand it) all these UBs will happily apply to our 2^x implementation it all began with.
Last edited by Max M. on Wed Feb 20, 2019 4:10 pm, edited 1 time in total.
-
- KVRAF
- Topic Starter
- 2256 posts since 29 May, 2012
I have never run into serious bugs because of such things. Memory access safety (type and bounds checking, etc) is an exaggerated problem. The worst "unsafe" thing one can have is a bad multithreaded design. It takes time to learn how to do it right. Weird optimizer behaviors aren't things that I like trying to figure out either. It's nice that the Rust team tried to address the multithreading issue, but I doubt it's entirely successful.
~stratum~
- KVRist
- 347 posts since 20 Apr, 2005 from Moscow, Russian Federation
~deleted~. tired. pointless.
-
- KVRAF
- Topic Starter
- 2256 posts since 29 May, 2012