Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
    ssokolow
    Senior Member

  • ssokolow
    replied
    ...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.

    Leave a comment:

  • ssokolow
    Senior Member

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

    Leave a comment:

  • coder
    Senior Member

  • coder
    replied
    Originally posted by sophisticles View Post
    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!

    Leave a comment:

  • sophisticles
    Senior Member

  • sophisticles
    replied
    Originally posted by ssokolow View Post

    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.

    Leave a comment:

  • sinepgib
    Senior Member

  • sinepgib
    replied
    Originally posted by sophisticles View Post

    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.

    Leave a comment:

  • sophisticles
    Senior Member

  • sophisticles
    replied
    Originally posted by ms178 View Post
    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.

    Leave a comment:

  • sinepgib
    Senior Member

  • sinepgib
    replied
    Originally posted by coder View Post
    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

    Originally posted by coder View Post
    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.

    Leave a comment:

  • FlaSheridn
    Junior Member

  • FlaSheridn
    replied
    Originally posted by ddriver View Post
    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.

    Leave a comment:

  • skeevy420
    Senior Member

  • skeevy420
    replied
    Originally posted by cl333r View Post

    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.

    Leave a comment:

  • ssokolow
    Senior Member

  • ssokolow
    replied
    Originally posted by pal666 View Post
    any language requires global reasoning about correctness. and your quote goes onto listing examples of bad c code.
    Fine. You want me to nitpick? "That requires global reasoning about correctness just to avoid person A introducing a memory bug because they forgot or didn't realize that person B changed some little thing on the other side of the codebase."

    I was trying to preserve C and C++'s dignity, so that's on you.

    Originally posted by pal666 View Post
    i said it before, every rust success story starts with pain caused by sticking to c instead of using c++
    Given that it's you, I know it'd be a waste of my time showing how that statement is false.

    Leave a comment:

Working...
X