101–110 of 120 posts
Earlier quoted context omitted.
I can't tell if this is satirical, but to be clear, you're proposing to disallow addition?
You could test whether overflow is going to happen first. Or use a math library that explicitly overflows with predictable results.
Earlier quoted context omitted.
You could test whether overflow is going to happen first. Or use a math library that explicitly overflows with predictable results.
I know very few languages that do that. Even Rust doesn't when compiled for release. All for performance reasons.
* It's not UB in Rust, it's guaranteed to be two's compliment overflow.
* It's still a "program error" and debug builds are required to panic.
* Non-debug builds are allowed to either panic or do the overflow, for performance reasons, as you mention. If it was feasible to always panic we'd do that; the current wording allows us to change it to do so in the future if it becomes feasible.
* If you want to do a checked add, you can, it's just not the default.
Earlier quoted context omitted.
They do it, but the performance culture among C devs doesn't appreciate enabling them. https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Object-Size-Che... https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Pointer-Bounds-... I bet not much UNIX software compiled with gcc enables them. Android is probably the only OS that does make use of them. https://android-developers.googleblog.com/2017/04/fortify-in...
The performance culture isn't just C. Far from it. Rust was susceptible to Stack Clash because they ripped out their existing stack probing to gain a few percent increase in performance. The article for this thread literally says, "For many use cases ASan is the better choice because it has much less overhead." IME Valgrind does a _much_ better job of detecting memory issues, partly because ASan only detects issues d…
Citation please?
I thought Rust used guard pages, and that stack probing was something that it was moving towards, not something that was being ripped out.
Earlier quoted context omitted.
The performance culture isn't just C. Far from it. Rust was susceptible to Stack Clash because they ripped out their existing stack probing to gain a few percent increase in performance. The article for this thread literally says, "For many use cases ASan is the better choice because it has much less overhead." IME Valgrind does a _much_ better job of detecting memory issues, partly because ASan only detects issues d…
> Rust was susceptible to Stack Clash because they ripped out their existing stack probing to gain a few percent increase in performance. Citation please? I thought Rust used guard pages, and that stack probing was something that it was moving towards, not something that was being ripped out.
Earlier quoted context omitted.
You could test whether overflow is going to happen first. Or use a math library that explicitly overflows with predictable results.
I know very few languages that do that. Even Rust doesn't when compiled for release. All for performance reasons.
Earlier quoted context omitted.
I think it's the compilers that have perverted the language to such an extent that it's become ridiculously difficult to understand, and so it's the compilers that must change back to being less obtuse and adversarial. The C standard even suggests, when defining undefined behaviour, that one of the possible options is "behaving during translation or program execution in a documented manner characteristic of the envir…
The original mandate of X3J11 was to “codify common existing practice”. The published Rationale goes on to describe a number of relevant criteria, including • Existing code is important, existing implementations are not. • Avoid “quiet changes.” • Trust the programmer. • Keep the language small and simple. • Make it fast, even if it is not guaranteed to be portable. In pre-ANSI C, and C89 C interpreted in line with t…
"12. Trust the programmer, as a goal, is outdated in respect to the security and safety programming communities. While it should not be totally disregarded as a facet of the spirit of C, the C11 version of the C Standard should take into account that programmers need the ability to check their work."
Earlier quoted context omitted.
They do it, but the performance culture among C devs doesn't appreciate enabling them. https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Object-Size-Che... https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Pointer-Bounds-... I bet not much UNIX software compiled with gcc enables them. Android is probably the only OS that does make use of them. https://android-developers.googleblog.com/2017/04/fortify-in...
The performance culture isn't just C. Far from it. Rust was susceptible to Stack Clash because they ripped out their existing stack probing to gain a few percent increase in performance. The article for this thread literally says, "For many use cases ASan is the better choice because it has much less overhead." IME Valgrind does a _much_ better job of detecting memory issues, partly because ASan only detects issues d…
Sure, but it is where it is more visible, specially micro-optimizing code as it is being written, without validating if it really matters to the application's use case with a profiler.
The school of systems programming languages from Algol side, was that correctness was much more relevant than pure performance, Algol dialects for systems programming already had Rust like unsafe blocks in the mid-60's.
In Burroughs B5500 the administrator could enable which applications with unsafe modules were allowed at all to be executed, 10 years before C was invented.
Earlier quoted context omitted.
They CAN accommodate all users, just have compile time options you can enter in your make file/on the command line/etc to say what level of bounds checking/etc you want compiled into your code. Hell that way even within a given project you can choose "this library I'm nervous about so I'll eat the hit on bounds checking".
They do it, but the performance culture among C devs doesn't appreciate enabling them. https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Object-Size-Che... https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Pointer-Bounds-... I bet not much UNIX software compiled with gcc enables them. Android is probably the only OS that does make use of them. https://android-developers.googleblog.com/2017/04/fortify-in...
Earlier quoted context omitted.
They do it, but the performance culture among C devs doesn't appreciate enabling them. https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Object-Size-Che... https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Pointer-Bounds-... I bet not much UNIX software compiled with gcc enables them. Android is probably the only OS that does make use of them. https://android-developers.googleblog.com/2017/04/fortify-in...
That's totally fair. Flip side arguing "we shouldn't do this because people who only care about immediate performance don't want them" feels like it is ignoring some percent of people who may not feel that way, or even the possibility of using it as a way to bring more people to systems level programming but are not up to making the leap Rust currently requires (which will hopefully become less of an issue as they wo…
They implemented a botstraped optimizing compiler for it, making use of an intermediate language with multiple optimization passes.
http://rsim.cs.illinois.edu/arch/qual_papers/compilers/ausla...
It was like having LLVM in the 70's and is only one example of the research on optimizing compilers since FORTRAN was created.