4 ms·

Defining undefined behavior doesn't change the language spec, only adds to it. All it's doing is saying that "my compiler uses the freedom to do anything that

Defining undefined behavior doesn't change the language spec, only adds to it. All it's doing is saying that "my compiler uses the freedom to do anything that undefined behavior grants to do something sane". By definition, anything that would be broken by such a change was already undefined behavior.

Retra 12y ago
That's a reasonable way to do things, but only if it is not a misappropriation of resources and effort. If someone is writing C code, it is generally inadvisable to rely on behavior that is implementation specific, even if your implementation does nice things. That would violate portability and readability, both things that are nearly unanimously considered to be ideals of programming practice. So really, the "something sane" that you are talking about should be issuing an error or warning.
- TheLoneWolfling 12y ago
  I don't see the difference between saying "this is valid C99 code" and "this is valid 'paranoid C' code". At least not if your 'paranoid C' compiler is working to a specification.
  - lmm 12y ago
    People would compile "paranoid C" with a normal C compiler (perhaps there is no paranoid C compiler for their platform). If your code is silently broken on some compilers, that's arguably even worse than being silently broken on all compilers. It would be better to a) make a compiler that errors out on any undefined behaviour (so that people would fix it in their code and it would then be fixed everywhere they compile) and/or b) use a new language.
    - TheLoneWolfling 12y ago
      "Paranoid C" would be a new language. It's just far easier to define a new language in terms of an extension to an existing language than making a new one from scratch. No need to throw the baby out with the bathwater. I mean, C++ started as an extension to C in the same way. The reasoning for having it an extension is mainly so that current code can be trivially ported.
      - lmm 12y ago
        If you permit calling C libraries from "paranoid C", that would give a very confusing debugging experience, where the semantics of identical code was different depending on which file that code happened to reside in. If you don't... maybe. But do you realistically think "paranoid C" would ever get its library ecosystem up to a level where it matched e.g. OCaml? Do you think embedded vendors would be more likely to support it (the other big use case for C)? If you're going to be switching libraries anyway, OCaml is a much nicer language to work in.
        TheLoneWolfling 12y ago
        You can say the same about C and C++: [1] (On a side note. I like OCaml, but don't like the syntax. I wish there was a language out there that was basically OCaml with c-like syntax. Or rather, I wish language syntax in general was less coupled with language semantics. It should be possible, and is, to, for example, automatically convert between Pythonic-style indentation and C-style braces and lisp-esque braces. Define the language in terms of an AST and leave the syntax up to the editor.) [1] http://stackoverflow.com/questions/12887700/can-code-that-is-valid-in-both-c-and-c-produce-different-behavior-when-compile http://stackoverflow.com/questions/12887700/can-code-that-is...
- TheLoneWolfling 12y ago
  Also, I'd argue that half the time trying to write things in a portable manner in C is drastically less readable. Look at the madness that ensues when you try to do something as simple as a bitwise rotation, for instance.

Retra 12y ago

That's a reasonable way to do things, but only if it is not a misappropriation of resources and effort. If someone is writing C code, it is generally inadvisable to rely on behavior that is implementation specific, even if your implementation does nice things. That would violate portability and readability, both things that are nearly unanimously considered to be ideals of programming practice. So really, the "something sane" that you are talking about should be issuing an error or warning.

TheLoneWolfling 12y ago
I don't see the difference between saying "this is valid C99 code" and "this is valid 'paranoid C' code". At least not if your 'paranoid C' compiler is working to a specification.
- lmm 12y ago
  People would compile "paranoid C" with a normal C compiler (perhaps there is no paranoid C compiler for their platform). If your code is silently broken on some compilers, that's arguably even worse than being silently broken on all compilers. It would be better to a) make a compiler that errors out on any undefined behaviour (so that people would fix it in their code and it would then be fixed everywhere they compile) and/or b) use a new language.
  - TheLoneWolfling 12y ago
    "Paranoid C" would be a new language. It's just far easier to define a new language in terms of an extension to an existing language than making a new one from scratch. No need to throw the baby out with the bathwater. I mean, C++ started as an extension to C in the same way. The reasoning for having it an extension is mainly so that current code can be trivially ported.
    - lmm 12y ago
      If you permit calling C libraries from "paranoid C", that would give a very confusing debugging experience, where the semantics of identical code was different depending on which file that code happened to reside in. If you don't... maybe. But do you realistically think "paranoid C" would ever get its library ecosystem up to a level where it matched e.g. OCaml? Do you think embedded vendors would be more likely to support it (the other big use case for C)? If you're going to be switching libraries anyway, OCaml is a much nicer language to work in.
      - TheLoneWolfling 12y ago
        You can say the same about C and C++: [1] (On a side note. I like OCaml, but don't like the syntax. I wish there was a language out there that was basically OCaml with c-like syntax. Or rather, I wish language syntax in general was less coupled with language semantics. It should be possible, and is, to, for example, automatically convert between Pythonic-style indentation and C-style braces and lisp-esque braces. Define the language in terms of an AST and leave the syntax up to the editor.) [1] http://stackoverflow.com/questions/12887700/can-code-that-is-valid-in-both-c-and-c-produce-different-behavior-when-compile http://stackoverflow.com/questions/12887700/can-code-that-is...
TheLoneWolfling 12y ago
Also, I'd argue that half the time trying to write things in a portable manner in C is drastically less readable. Look at the madness that ensues when you try to do something as simple as a bitwise rotation, for instance.