may_alias (thread separated from another one)

DSP, Plugin and Host development discussion.
RELATED
PRODUCTS

Post

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.

Post

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.
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.

Post

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".
~stratum~

Post

Z1202 wrote: Wed Feb 20, 2019 7:09 am Second, there can be systems where 0 is a perfectly valid memory address. Why can't I program for those systems in C++?
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.

Post

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.
Last edited by Max M. on Wed Feb 20, 2019 4:10 pm, edited 1 time in total.

Post

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~

Post

~deleted~. tired. pointless.

Post

Max M. wrote: Wed Feb 20, 2019 4:34 pm ~deleted~. tired. pointless.
If you have been coding for about 10-20 years it's highly probable that you have experienced as few things that would be quite difficult to explain without getting tired. It's OK and understandable.
~stratum~

Post Reply

Return to “DSP and Plugin Development”