Intel Makes ControlFlag Open-Source For Helping To Detect Bugs In Code

[skeevy420]

I used to hear that about iron and copper.

Vines and sticks, my dude. Sumbitch round the way wants to discuss something called a "stone". I'm not so sure about that.

[FlaSheridn]

If you make such trivial errors that can be caught by a static analyzer, you clearly don't "already know math", and you are not using the "calculator" as a time saver, but as a mitigation of the absence of skill.

Bugs found by a good static analyzer are not necessarily trivial. One I found with Coverity in a very senior developer’s code took me an afternoon to figure out: an off-by-one overrun that would happen when an inner loop variable was exactly 365, and the outer loop satisfied conditions I never did figure out. This was in a widely-used component which everyone in the company agreed was flakey, but no-one could quite diagnose.

Flash’s First Law of Static Analysis is Developers who fix their static analysis bugs voluntarily are the ones who need it the least. The converse is that developers who believe that they are immune, badly need to use it. See my Dr Dobb’s cover story for further references, especially by Dawson Engler.

[sinepgib]

Wouldn't you want easier & more powerful tools for them (and even possibly yourself) to check their stuff for bugs, or to help locate defects when an anomalous behavior is observed?

No, because good programmers write flawless code 100% of the time, no need /s

So, you have an implicit interest in the quality of that code. Better static analysis tools are one means to that end.

In their fantasy world it's the opposite.

[sophisticles]

Intel, please use this tool on your own icx/icpx compiler (and while at it, at clang/clang++, too). Thanks to a serious compiler bug I bricked my Arch install today.

In all fairness, Arch is easy to brick, especially if using the AUR repositories. Arch may be the most delicate OS i have ever seen, more so than Win Me and that's saying something.

[sinepgib]

In all fairness, Arch is easy to brick, especially if using the AUR repositories. Arch may be the most delicate OS i have ever seen, more so than Win Me and that's saying something.

I never had any problems until I tried to combine login decryption of an fscrypt home with fprintd, I ended up just disabling fingerprint login.
From what I've read systemd-homed seems to simplify that use case, but it seems much more involved to setup for an existing home than from scratch and I'm procrastinating that.
I stick to very simple setups tho, I'm too lazy to learn the proper use of the more complex one so using them becomes paying a lot for things I don't use, and those tend to be less brittle. Fewer moving parts and all that.
Same reason I don't use an IDE, if you learn the tricks it's a massive productivity boost, or so I heard, but I don't and if you use them as if they were just a simple editor everything else just becomes bloat. Like, don't buy a power tool if you'll end up just hammering nails with it.

[sophisticles]

Honestly, after more than 25 years of C (and C++), I’ve become very frustrated with the average C code I seen in the wild. OpenSSL is fairly typical, in a lot of ways. So much C code has buffer overflows, numeric overflows, memory leaks, double frees, undefined behavior, and an an endless number of bugs. There are exceptions—djb’s code is quite good, dovecot seems reasonable, OpenBSD audits aggressively—but when I dive into most C code, I expect problems… I’m tired. I don’t want to rely on programmers practicing constant, flawless vigilance.
-- emk @ https://www.reddit.com/r/rust/commen...not_a/ds0u68p/

The reason for this is that C/C++ promotes and forgives sloppy programming.

About 20 years ago there was this pic that circulated around the net, can't find it now, that showed why Pascal was better than C, outlining some of the coding conventions that C/C++ allowed programmers to do that Pascal, and Fortan, do not.

I think if people had stuck with Pascal and Fortran we would have a lot less bugs.

[coder]

About 20 years ago there was this pic that circulated around the net, can't find it now, that showed why Pascal was better than C, outlining some of the coding conventions that C/C++ allowed programmers to do that Pascal, and Fortan, do not.

I think if people had stuck with Pascal and Fortran we would have a lot less bugs.

MS Quick Basic and Turbo Pascal were my first two programming languages. TBH, I never got as deep with pascal as I've gone with C/C++, so it wouldn't be fair for me to compare them.

I do think that if you look only at the safety aspect, you're missing a least half of the picture. You're looking mostly at what one loses with C, not what's gained. C was developed as a portable alternative to assembly language. It's very low-level, for that reason. There's an undeniable speed advantage it has over most programming languages, as a result. Restricted pointers closed the last big gap between C and Fortran, performance-wise, yet C remains far more flexible.

As for C++, I think it has plenty of safety features, but they're mostly at the library-level and it's therefore incumbent on the programmer to employ them. C++ is extremely rewarding, but the learning curve is basically as high as you want to go.

Anyway, this whole topic reminds me of how "everything should be rewritten in ADA", BITD. Kinda boring to have, in the abstract. If you want to bring it up-to-date, you should at least mention Rust. That would get folks hopping!

[ssokolow]

I'm reminded of Pascal Versus C: A Subjective Comparison by Prabhaker Mateti from 1979.

[ssokolow]

...well, that and Chapter 4: Myths Uncovered from The Pascal Programming Language by Bill Catambay, which is what comes to mind when people pull up things like Why Pascal is Not My Favorite Programming Language
by Brian W. Kernighan.