Comment by TickleSteve
10 years ago
I've been using C for over 20 years and I'm sure I would be caught out by these...
...but...
The fact these curiosities are not an issue in day-to-day work and C is (one of) the most popular languages around today mean that they aren't too serious.
When you have a knowledge of the hardware and are working at that level day-in day-out then issues like this really don't bother you that much.
(I do realise that this is a slightly contrarian view these days, but there is an awful lot of unjustified C-bashing around currently).
http://cacm.acm.org/magazines/2016/3/198849-a-differential-a...
8575 C or C++ packages in Wheezy. This tool found definite UB bugs in 40% of them.
How would you know that your code is sometimes misbehaving because of UB?
The linked paper claims their tool issued as least one warning on 40% of the C or C++ packages, not that they were all valid warnings indicating undefined behavior.
A warning is not 'definite UB'
not denying there are issues... just saying that C isn't the only widespread language with issues. at least C's problems are widely known.
The Potzrebie car isn't the only car with issues. At least the Potzrebie's doors-falling-off problem is widely known.
4 replies →
> The fact these curiosities are not an issue in day-to-day work and C is (one of) the most popular languages around today mean that they aren't too serious.
C became one of the most used languages, not necessary popular, thanks to the adoption of UNIX and the rise of FOSS/C culture (UNIX based) in the late 90's.
Back then it was just yet another systems programming language.
I only started to care about it when I moved from MS-DOS into Windows / UNIX, and even by then I was into C++ after a short (1 year) encounter with C.
As for not being an issue, the CVE list shows daily the cost of any programming language that "enjoys" copy-paste compatibility with C semantics.
Or the business opportunity for those that sell tools that help both developers (static analyzers) and users (anti-virus/firewalls) to overcome those shortcomings.
Late '90s is about a decade off, IMO. C was very much the only systems language by then.
I think the last time a popular OS was built on something else than C was the original Mac OS, which had a Pascal API and used Pascal calling conventions.
On the desktop, C was chosen as the API language for Windows and OS/2 around 1986. That meant both Microsoft and IBM agreed that PC software is going to be in written in C.
On MS-DOS, Acorn, Amiga and Atari it was just yet another one.
On Mac OS (after the C transition), Windows and OS/2, they might had C as main implementation, but most of us that couldn't carry on using Turbo/Quick/HiSoft Pascal, Modula-2 or Basic compilers, moved to C++ instead.
We could still make us of improved safety and stronger type checking features, while being compatible with the C toolchains.
EDIT: Also IBM and Microsoft eventually had very good C++ support in the form of SOM, COM, C Set++ and MFC, with Borland providing the very good OWL and VCL.
Also any Windows 3.x old timer remembers the message and event handling macros alongside #define STRICT, that Microsoft used to bring some sanity to Windows programming with straight C.
6 replies →
> Microsoft and IBM agreed
My understanding of the narrative surrounding this is that Microsoft started working for IBM on OS/2 before switching to Windows, which - struggling here - was intended to have a certain amount of binary compatibility (?). Basically IBM decided, Microsoft went along with them, and the rest was history. Would be interesting to understand who made the decision to use C and why ... was OS/2 intended to be "unix-like"?
Undefined behavior in the form of memory safety issues is a problem in day-to-day work.
UB and memory safety are a big issue exactly because they are not a problem in day to day work.
I literally can't remember the last time I had spent any significant time investigating one of these issues. In my experience when that a crash happen (usually in a unit test or the first time you start the app) because of these issues, the backtrace points you to the exact problem.
The pain start when the program and tests work correctly for all reasonable inputs and the underlying issue never manifests in during normal execution and can be potentially exploited by a malicious attacker with a carefully crafted input.
What I'm trying to say is that I don't want memory safety because it would improve my daily programming experience (in fact possibly the reverse would be true), but I want it because I want security.
> What I'm trying to say is that I don't want memory safety because it would improve my daily programming experience (in fact possibly the reverse would be true)
I think you underestimate how much time is saved by not having to deal with these issues. Programming in C or C++ is frequently an exercise in writing the code, seeing a crash due to a memory safety problem, debugging it, and then repeating until you see anything resembling a working program. Writing in a memory-safe language lets you skip all that startup friction and go straight to "something resembling a working program".
1 reply →
But that's not what this study is about: everyone agrees that stomping wildly off the end of an array in C is not going to end well.
This is about far more subtle issues than that - issues where there is some disagreement about whether it's OK to do or not. And the GP is right - these are often not such a problem in practice, if only because these are the kinds of issues where experienced C programmers know that they're sailing close to the wind, and there's almost always an alternative construct that's on more solid ground.
Signed versus unsigned comparison, signed wrap-around, undefined division behaviour, undefined behaviour of some casts, and strict aliasing optimisations have all caused hard bugs that I've had to spend a lot of time fixing.
I had to deal with some of these before I was a compiler writer, and I would end up just kind of kicking my code repeatedly until stuff worked again.
Now that I'm a compiler writer, I know how to recognize what is happening, but I'm still not smart enough to avoid the bugs in general and I still spend time fixing bugs that result from these issues.
So, I'm with pcwalton: it is a problem. Maybe I don't see it every day, but I see it probably at least once a month.
1 reply →
we will have to agree to disagree on that one.