6 ms·

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 an

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).

pkhuong 10y ago
http://cacm.acm.org/magazines/2016/3/198849-a-differential-approach-to-undefined-behavior-detection/fulltext 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?
- TickleSteve 10y ago
  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.
  - D-Coder 10y ago
    The Potzrebie car isn't the only car with issues. At least the Potzrebie's doors-falling-off problem is widely known.
    - Gibbon1 10y ago
      If the compiler writers union decides that the spec allows for 'format hard drive off on signed overflow' we can always change the spec to 'don't format hard drive on signed overflow'
      - pcwalton 10y ago
        It's not that simple. The compiler writers have caused security issues before in the Linux kernel. And the compiler writers are right: the undefined behavior that they exploit exists for important performance-related reasons.
        pizlonator 10y ago
        To say they are right is an overstatement, I think. There is insufficient discussion of the empirically measured performance benefits of specific forms of UB. Some kinds of UB could be turned into something stricter, like reading a bad pointer. This either traps or returns some value. It won't format your hard drive unless you install a trap that formats your hard drive, but that's none of the spec's business. Traps can happen due to timers, so if arbitrary traps mean UB then every instruction is UB. Even if the spec punts on defining what a trap is, that's a progression over saying it's UB. Same thing goes for division and modulo. In corner cases, it will either return some value or it will trap. It won't format your hard drive. The most profitable "true" UB is stuff like TBAA, but smart people turn that off. Do you know what the performance benefits are of other kinds of UB? Do you know how many of those perf benefits (like being maybe being able to take some shortcuts in SROA) can't be solved by changing the compiler (i.e. you'll get the same perf, but the compiler follows slightly different rules)? Maybe I'm not so well read, but I hardly ever hear of empirical evidence that proves the need for UB, only demos that show the existence of an optimisation in some compiler that would fail to kick in if the behaviour was defined. Also, if there were perf benefits of the really gnarly kinds of UB, I would probably be happy to absorb the loss in most of the code I write. If I added up all of the time I've wasted fixing signed-unsigned comparison bugs and used that time to make WebKit faster, then I'd probably have made WebKit faster by a larger amount than the speed-up that WebKit gets from whatever corner-case optimisation the compiler can do by playing fast and loose with signed ints. I suspect that UB is the way that it is because of politics - you can't get everyone to agree what will happen, nobody wants to lose some optimisation that they spent time writing, and so we punt on good semantics.
        _0ffh 10y ago
        "...the undefined behavior that they exploit exists for important performance-related reasons..." That's a good point, but arguably incomplete. It was there, to give the compiler writer leeway to implement the semantic in the way which is natural for the platform. It was not intended to play sophistic tricks on the programmer, in order to gain a few per cent of performance in some benchmark.
- jjnoakes 10y ago
  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.
- EpicEng 10y ago
  A warning is not 'definite UB'
pcwalton 10y ago
Undefined behavior in the form of memory safety issues is a problem in day-to-day work.
- TickleSteve 10y ago
  we will have to agree to disagree on that one.
- caf 10y ago
  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.
  - pizlonator 10y ago
    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.
    - MaulingMonkey 10y ago
      There are fewer issues that scare me more than undefined behavior that usually works. "Works" enough for programmers to add it, knowingly or unknowingly, even to defend it as "working in practice"... only to leave a needle in a haystack that they'll never find.
pjmlp 10y ago
> 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.
- pavlov 10y ago
  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.
  - pjmlp 10y ago
    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.
    - anexprogrammer 10y ago

pkhuong 10y ago

http://cacm.acm.org/magazines/2016/3/198849-a-differential-approach-to-undefined-behavior-detection/fulltext 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?

TickleSteve 10y ago
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.
- D-Coder 10y ago
  The Potzrebie car isn't the only car with issues. At least the Potzrebie's doors-falling-off problem is widely known.
  - Gibbon1 10y ago
    If the compiler writers union decides that the spec allows for 'format hard drive off on signed overflow' we can always change the spec to 'don't format hard drive on signed overflow'
    - pcwalton 10y ago
      It's not that simple. The compiler writers have caused security issues before in the Linux kernel. And the compiler writers are right: the undefined behavior that they exploit exists for important performance-related reasons.
      - pizlonator 10y ago
        To say they are right is an overstatement, I think. There is insufficient discussion of the empirically measured performance benefits of specific forms of UB. Some kinds of UB could be turned into something stricter, like reading a bad pointer. This either traps or returns some value. It won't format your hard drive unless you install a trap that formats your hard drive, but that's none of the spec's business. Traps can happen due to timers, so if arbitrary traps mean UB then every instruction is UB. Even if the spec punts on defining what a trap is, that's a progression over saying it's UB. Same thing goes for division and modulo. In corner cases, it will either return some value or it will trap. It won't format your hard drive. The most profitable "true" UB is stuff like TBAA, but smart people turn that off. Do you know what the performance benefits are of other kinds of UB? Do you know how many of those perf benefits (like being maybe being able to take some shortcuts in SROA) can't be solved by changing the compiler (i.e. you'll get the same perf, but the compiler follows slightly different rules)? Maybe I'm not so well read, but I hardly ever hear of empirical evidence that proves the need for UB, only demos that show the existence of an optimisation in some compiler that would fail to kick in if the behaviour was defined. Also, if there were perf benefits of the really gnarly kinds of UB, I would probably be happy to absorb the loss in most of the code I write. If I added up all of the time I've wasted fixing signed-unsigned comparison bugs and used that time to make WebKit faster, then I'd probably have made WebKit faster by a larger amount than the speed-up that WebKit gets from whatever corner-case optimisation the compiler can do by playing fast and loose with signed ints. I suspect that UB is the way that it is because of politics - you can't get everyone to agree what will happen, nobody wants to lose some optimisation that they spent time writing, and so we punt on good semantics.
      - _0ffh 10y ago
        "...the undefined behavior that they exploit exists for important performance-related reasons..." That's a good point, but arguably incomplete. It was there, to give the compiler writer leeway to implement the semantic in the way which is natural for the platform. It was not intended to play sophistic tricks on the programmer, in order to gain a few per cent of performance in some benchmark.
jjnoakes 10y ago
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.
EpicEng 10y ago
A warning is not 'definite UB'

pcwalton 10y ago

Undefined behavior in the form of memory safety issues is a problem in day-to-day work.

TickleSteve 10y ago
we will have to agree to disagree on that one.
caf 10y ago
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.
- pizlonator 10y ago
  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.
  - MaulingMonkey 10y ago
    There are fewer issues that scare me more than undefined behavior that usually works. "Works" enough for programmers to add it, knowingly or unknowingly, even to defend it as "working in practice"... only to leave a needle in a haystack that they'll never find.

pjmlp 10y ago

> 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.

pavlov 10y ago
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.
- pjmlp 10y ago
  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.
  - anexprogrammer 10y ago