6 ms·

Undefined behaviour is not as prevalent in real world code as reading articles from HN might make you think.

rwmj 10y ago
This is a very naive statement. Sure there are a handful of good companies that enable every single compiler warning, and fix those warnings, and then run the code through Coverity, and fix all those problems too. Almost no one else does. The amount of terrible C in the real world is enormous.
- kbart 10y ago
  "The amount of terrible C in the real world is enormous." I'm sure you could say that about pretty much any programming language: "The amount of terrible X in the real world is enormous". There are also plenty of clean, nice, safe C code around (and any other language), there's no need to over-generalize ("Almost no one else does").
  - netheril96 10y ago
    > I'm sure you could say that about pretty much any programming language: "The amount of terrible X in the real world is enormous". But the damage is far greater in C. In other languages you won't have arbitrary code execution or privilege escalation just because the programmer is not careful. Nor will there be, in other languages, so many nondeterministic bugs that show up once in a blue moon.
    - falcolas 10y ago
      > In other languages you won't have arbitrary code execution or privilege escalation just because the programmer is not careful. Sure you do. Remember the YAML fiasco with Ruby? How about the thousand-and-one RCE issues with PHP? eval isn't evil for no reason.
    - kbart 10y ago
      "In other languages you won't have arbitrary code execution or privilege escalation just because the programmer is not careful" No, it's possible to make system insecure with pretty much any language if programmer is not careful. SQL injection, cross-site scripting, cross-site request forgery and the list goes on..
  - 0xfeba 10y ago
    Yeah, I do web development. I've worked with javascript, PHP, and, sigh, classic ASP. There's bad code everywhere. Some languages make it a bit easier, but it's really not the languages fault.
  - cwyers 10y ago
    There are very few programming languages where the total lines of code written is larger than the amount of bad C code written.
    - kbart 10y ago
      There are very programming languages where the total lines of code written is even comparable to C, so of course there is more of bad code too.
      - krylon 10y ago
        There are two kinds of languages: Those everyone hates and those nobody uses (according Bjarne Stroustrup, but I tend to agree... ;-) ).
        MaulingMonkey 10y ago
        There's a kernel of truth there, but I find myself regularly using languages which I hate much less. If your best defense of a language is "well, at least people use it", that's a bad sign.
        krylon 10y ago
        I always read Stroustrup's quote as saying, roughly speaking, that if nobody uses a language, nobody will notice its shortcomings, and if lots of people use it, lots of people will notice. In other words, popularity is no excuse for sucking, but if one is not popular, no one will notice how much one sucks.
  - majewsky 10y ago
    https://en.wikipedia.org/wiki/Sturgeon's_law https://en.wikipedia.org/wiki/Sturgeon's_law
- w0utert 10y ago
  >> Sure there are a handful of good companies that enable every single compiler warning. You think so? Every company I've worked for, or that I've known people that worked there, always enabled -Wall for their C and C++ code. Most OSS software compiles with all warnings enabled. I think the issue with undefined behavior in C/C++ is extremely overblown, aside from fun academic examples like 'what does i++++i++ evaluate to' there isn't actually all that much undefined behavior or gotchas in C/C++. I would say there are less, compared to other languages I know.
  - rwmj 10y ago
    Signed overflow problems are everywhere, even in carefully written code. Using 'int' instead of a more specific type is a code smell. Security code which presumes that because you wrote ptr != NULL, that the check is actually carried out. Code that does type punning. Code that doesn't know about aliasing. It goes on and on. You need to know that the problem exists in order to know that you have a problem. There are many C programmers who learned C back in the 1980s who don't even realize these are issues.
    - tarancato 10y ago
      I'd say things have changed quite a bit since format string bugs...
      - MaulingMonkey 10y ago
        Since? I'm still adding the compiler specific annotations to add format string checking to custom variadic logging functions in codebases I inherit, and finding multiple bugs.
  - majewsky 10y ago
    > always enabled -Wall for their C and C++ code Of course you want -Wall -Wextra -Werror -pedantic. ;)
    - mitchty 10y ago
akvadrako 10y ago
I would tend to disagree. For example, casting void * to other pointer types is undefined, but this construct is often used, for example: void func(void *ptr) { uint32_t *ip = ptr; ptr[0] = 123; }
- zosima 10y ago
  This is wrong. Casting to and from void * is defined for all pointer types except function pointers, according to the standard. Otherwise most every assignment after call to malloc would be undefined.
  - akvadrako 10y ago
    Yes, you are right, void * is an exception. However, any other pointer cannot be reliably casted: From C1X, section 6.3.2.3: "A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined." Though that is quite odd, since any pointer can be converted to void* , which only needs alignment to the char type. So converting from x* -> y* is undefined, but x* -> void* -> y* is defined.
    - planteen 10y ago
      That might not necessarily work. If you have something like: >> uint8_t x[100]; >> uint32_t *y = &x[1]; And then dereference y, most RISC architectures will trap on the unaligned access. It doesn't matter if there is an intermediate void pointer or not.
      - akvadrako 10y ago
        I am not trying to say it'll work, I'm trying to show that most non-trivial C programs invoke undefined behaviour, according to the spec. According to my reading an intermediate void pointer allows the pointer casting to stay well defined. However this seems unsafe, even without getting into dereferencing, because implementations are allowed to store omit bits if they assume aligned pointers.
MaulingMonkey 10y ago
You're right - it's far more prevalent, if the bug database for basically every C or C++ codebase I've ever seen is any indication.
- ArkyBeagle 10y ago
  it's a heatmap.
CountSessine 10y ago
There are some very interesting surveys and studies that suggest otherwise. Undefined behaviour due to integer overflow seems to be very common. http://www.cs.utah.edu/~peterlee/papers/tosem15.pdf http://www.cs.utah.edu/~peterlee/papers/tosem15.pdf

rwmj 10y ago

This is a very naive statement. Sure there are a handful of good companies that enable every single compiler warning, and fix those warnings, and then run the code through Coverity, and fix all those problems too. Almost no one else does. The amount of terrible C in the real world is enormous.

kbart 10y ago
"The amount of terrible C in the real world is enormous." I'm sure you could say that about pretty much any programming language: "The amount of terrible X in the real world is enormous". There are also plenty of clean, nice, safe C code around (and any other language), there's no need to over-generalize ("Almost no one else does").
- netheril96 10y ago
  > I'm sure you could say that about pretty much any programming language: "The amount of terrible X in the real world is enormous". But the damage is far greater in C. In other languages you won't have arbitrary code execution or privilege escalation just because the programmer is not careful. Nor will there be, in other languages, so many nondeterministic bugs that show up once in a blue moon.
  - falcolas 10y ago
    > In other languages you won't have arbitrary code execution or privilege escalation just because the programmer is not careful. Sure you do. Remember the YAML fiasco with Ruby? How about the thousand-and-one RCE issues with PHP? eval isn't evil for no reason.
  - kbart 10y ago
    "In other languages you won't have arbitrary code execution or privilege escalation just because the programmer is not careful" No, it's possible to make system insecure with pretty much any language if programmer is not careful. SQL injection, cross-site scripting, cross-site request forgery and the list goes on..
- 0xfeba 10y ago
  Yeah, I do web development. I've worked with javascript, PHP, and, sigh, classic ASP. There's bad code everywhere. Some languages make it a bit easier, but it's really not the languages fault.
- cwyers 10y ago
  There are very few programming languages where the total lines of code written is larger than the amount of bad C code written.
  - kbart 10y ago
    There are very programming languages where the total lines of code written is even comparable to C, so of course there is more of bad code too.
    - krylon 10y ago
      There are two kinds of languages: Those everyone hates and those nobody uses (according Bjarne Stroustrup, but I tend to agree... ;-) ).
      - MaulingMonkey 10y ago
        There's a kernel of truth there, but I find myself regularly using languages which I hate much less. If your best defense of a language is "well, at least people use it", that's a bad sign.
        krylon 10y ago
        I always read Stroustrup's quote as saying, roughly speaking, that if nobody uses a language, nobody will notice its shortcomings, and if lots of people use it, lots of people will notice. In other words, popularity is no excuse for sucking, but if one is not popular, no one will notice how much one sucks.
- majewsky 10y ago
  https://en.wikipedia.org/wiki/Sturgeon's_law https://en.wikipedia.org/wiki/Sturgeon's_law
w0utert 10y ago
>> Sure there are a handful of good companies that enable every single compiler warning. You think so? Every company I've worked for, or that I've known people that worked there, always enabled -Wall for their C and C++ code. Most OSS software compiles with all warnings enabled. I think the issue with undefined behavior in C/C++ is extremely overblown, aside from fun academic examples like 'what does i++++i++ evaluate to' there isn't actually all that much undefined behavior or gotchas in C/C++. I would say there are less, compared to other languages I know.
- rwmj 10y ago
  Signed overflow problems are everywhere, even in carefully written code. Using 'int' instead of a more specific type is a code smell. Security code which presumes that because you wrote ptr != NULL, that the check is actually carried out. Code that does type punning. Code that doesn't know about aliasing. It goes on and on. You need to know that the problem exists in order to know that you have a problem. There are many C programmers who learned C back in the 1980s who don't even realize these are issues.
  - tarancato 10y ago
    I'd say things have changed quite a bit since format string bugs...
    - MaulingMonkey 10y ago
      Since? I'm still adding the compiler specific annotations to add format string checking to custom variadic logging functions in codebases I inherit, and finding multiple bugs.
- majewsky 10y ago
  > always enabled -Wall for their C and C++ code Of course you want -Wall -Wextra -Werror -pedantic. ;)
  - mitchty 10y ago

akvadrako 10y ago

I would tend to disagree. For example, casting void * to other pointer types is undefined, but this construct is often used, for example: void func(void *ptr) { uint32_t *ip = ptr; ptr[0] = 123; }

zosima 10y ago
This is wrong. Casting to and from void * is defined for all pointer types except function pointers, according to the standard. Otherwise most every assignment after call to malloc would be undefined.
- akvadrako 10y ago
  Yes, you are right, void * is an exception. However, any other pointer cannot be reliably casted: From C1X, section 6.3.2.3: "A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined." Though that is quite odd, since any pointer can be converted to void* , which only needs alignment to the char type. So converting from x* -> y* is undefined, but x* -> void* -> y* is defined.
  - planteen 10y ago
    That might not necessarily work. If you have something like: >> uint8_t x[100]; >> uint32_t *y = &x[1]; And then dereference y, most RISC architectures will trap on the unaligned access. It doesn't matter if there is an intermediate void pointer or not.
    - akvadrako 10y ago
      I am not trying to say it'll work, I'm trying to show that most non-trivial C programs invoke undefined behaviour, according to the spec. According to my reading an intermediate void pointer allows the pointer casting to stay well defined. However this seems unsafe, even without getting into dereferencing, because implementations are allowed to store omit bits if they assume aligned pointers.

MaulingMonkey 10y ago

You're right - it's far more prevalent, if the bug database for basically every C or C++ codebase I've ever seen is any indication.

ArkyBeagle 10y ago
it's a heatmap.

CountSessine 10y ago

There are some very interesting surveys and studies that suggest otherwise. Undefined behaviour due to integer overflow seems to be very common. http://www.cs.utah.edu/~peterlee/papers/tosem15.pdf http://www.cs.utah.edu/~peterlee/papers/tosem15.pdf