121–130 of 144 posts
Earlier quoted context omitted.
Any dynamic memory allocation lacks determinism, which is why in high integrity systems it often forbidden to dynamically allocate memory. As for Rust can be faster than C, well, people said the same about Ada but it rarely is the case so I wouldn't hold my breath for Rust either. After all, those languages use the same backends - GCC in the case of C & Ada, LLVM in the case of C & Rust. But it's enough to as fast as…
> After all, those languages use the same backends - GCC in the case of C & Ada, LLVM in the case of C & Rust. The killer flaw of C for performance is the pointer aliasing problem. C only has the very coarse-grained tools of strict aliasing (often disabled in large applications because it breaks code!) and restrict (which relies heavily on manual programmer annotation) to control these aliasing issues. Since Rust has…
Earlier quoted context omitted.
Because it is a big difference to have 100% of the code unsafe or just a set of visible code regions marked as such.
Hyperbole, or do really believe every line of C is unsafe, in the literal sense, by default? Pray tell me what is the difference between // safe, tested, C ... // potentially dangerous C deemed thus for whatever arbitrary reason And // "safe" Rust ... // "unsafe" Rust
So yes I do belive, given the quality of the code bases I have seen in production.
And as discussed at Linux Kernel Security Summit 2018, which videos are freely available for you to watch as well, even with the rigorous process to accept patchs into the kernel, CVEs keep increasing.
68% of them were caused by memory corruption, something mostly unique to C and languages that are copy-paste compatible with it.
Then another good chunk was related to UB, something that even Linus already ranted a few times.
So yeah, Safe C is an oxymoron, unless we are talking about a new variant with safety turned on by default, where warnings are dealt as errors and everyone uses static analysers that break their CI builds on error.
Earlier quoted context omitted.
Until Blackberry bought it, it was open source. There were free downloads. Now it's proprietary. But there's a lot of info out there from the open source era. The manuals are available. Here's the original QNX paper.[1] [1] https://cseweb.ucsd.edu/~voelker/cse221/papers/qnx-paper92.p...
I am amazed that I cannot find a copy of the source code from the time it was freely available now.
On April 9, 2010, the day the acquisition closed, Research and Motion took the source code offline, with no notice. All user open source projects on QNX were abandoned shortly thereafter.[2]
Earlier quoted context omitted.
> After all, those languages use the same backends - GCC in the case of C & Ada, LLVM in the case of C & Rust. The killer flaw of C for performance is the pointer aliasing problem. C only has the very coarse-grained tools of strict aliasing (often disabled in large applications because it breaks code!) and restrict (which relies heavily on manual programmer annotation) to control these aliasing issues. Since Rust has…
I think it's fair to say that "average" Rust code will be faster than "average" C code due to lack of pointer aliasing issues as the average developer doesn't care about/understand this enough to make the annotations in any codebase I've worked in. Can you make both equally fast? I don't see why not, they're both LLVM.
Earlier quoted context omitted.
No, that's an example of someone not knowing the language very well. You should have written something like, "which is the company that...". I can't think offhand of any language that's really better here in a sense of being more efficient, except probably Classical Latin which is horribly complicated and of course a dead language.
Czech allows you to specify that with a change of one letter depending on who you mean (the CTO - který, the company - která) - this depends on different genders of the two words, but is commonly used.
Earlier quoted context omitted.
Why should the GC not be able to inform the programmer/language designer when memory is discarded? This is a non-issue. Besides, a kernel has to deal with plenty of forms of nondeterminism anyway.
How would the GC in this case inform you when an object is deallocated? The whole point is scope can be extended arbitrarily by anything and that finalization may happen, or it may not, at some point in the future.
Do you maybe have hard real-time systems in mind when you say "deterministic"? I agree that a GC would be a bad idea for those, but these require validation of the hardware in combination with the software anyway.
Earlier quoted context omitted.
Any dynamic memory allocation lacks determinism, which is why in high integrity systems it often forbidden to dynamically allocate memory. As for Rust can be faster than C, well, people said the same about Ada but it rarely is the case so I wouldn't hold my breath for Rust either. After all, those languages use the same backends - GCC in the case of C & Ada, LLVM in the case of C & Rust. But it's enough to as fast as…
Rust doesn't require a heap, you can use it fully statically and still get the deterministic destructors when your stack object is destroyed.