4 ms·

Undefined behavior strikes again! It really seems like the C standard maintainers and compiler vendors should just get together and sort that whole mess out. I

Undefined behavior strikes again! It really seems like the C standard maintainers and compiler vendors should just get together and sort that whole mess out. It can give you a few extra percent in some benchmarks, sure, and help C keep its mostly-deserved reputation as the fastest language, but the cost is huge. If these non-type-checked functions are really useful in some very unusual use case, give it a special weird syntax. Don't make it the default and inflict it on everybody whether they want it or not.

JdeBP 9y ago
They did get together to sort the mess out. They did so in the 1980s. Where do you think the idea of "ANSI function prototypes" came from?
- iainmerrick 9y ago
  It's hardly a complete solution, though, since they kept the zero-arg functions around as a special case! ANSI C is the version I first learned. I didn't know that weird exception for zero-args functions still existed, or had forgotten it. I could be wrong, but I bet most C programmers don't know about it.
Garfgon 9y ago
I think it's backward compatibility, not speed. Functions with no arguments lists were supported in C89, so changing it now will break someone's code somewhere. In fact not specifying a parameter list may make your code slower, as (IIRC) default argument promotions are always applied to parameters passed to such a function.
gumby 9y ago
> It really seems like the C standard maintainers and compiler vendors should just get together and sort that whole mess [Undefined behavior] out. Why do you think there is undefined behavior? Because committee members are lazy? Not every machine is a C machine (PDP-11). I used to program machines with bytes that could range from 1-36 bits (these are older than the PDP-7/PDP-11 that C was designed for). A joy to program, but the C model did not apply. You may consider these architectures obsolete, and they are, but many decisions in the design of IP, UDP and TCP (and some higher level protocols) still reflect these machines. Early C standardization efforts bent backwards to support the architectures committee members cared about. Some constraints (undef behavior etc) were removed in later standards (though the C++ committee is more aggressive in this regard than the C committee). And you well could argue that C's tight coupling to the architecture of the PDP-11 and the programming standards of the 70s holds back CPU design. Many of these undefined areas are places where compilers have the opportunity to take advantage of CPU features (e.g. vector hardware). The committee mailing list and other discussions are open -- have a read. And if you feel strongly you can even join the committee.
- iainmerrick 9y ago
  I realize it's there for a reason -- as I understand it, to avoid constraining compilers into generating unnecessarily awkward code for unlikely edge cases. And that fits with one of C's main advantages, being fast and lightweight. But in the last few years I've read many, many articles about problems that crop up when optimizing C compilers do weird things to reasonable-looking code, citing "undefined behavior" as an excuse. I can't say for sure if I've hit issues like that myself, but I've certainly used libraries that have. Maybe the problem lies squarely with the compiler vendors, but the language spec enables them.
  - geezerjay 9y ago
    > do weird things to reasonable-looking code, citing "undefined behavior" as an excuse. If the behaviour is undefined then the code is broken. Programmers need to learn the language instead of putting together hail mary code expecting it to somehow work in spite of the language specifically telling them that they should not expect any defined behavior out of it. People who whine about undefined behavior are like kids who insist in jamming their fingers in a electric socket and whine when they get a shock.
    - iainmerrick 9y ago
      It would be nice for the compiler to be a friend and ally, rather than a mischievous opponent.
- derefr 9y ago
  AFAICT, "undefined behavior" refers to two entirely-separate classes of behavior: 1. cases where the compiler explicitly recognizes a certain permutation of compilation-state as matching some pattern for what the standard calls "undefined behavior"—and then is unconstrained as to what it does in response, but indeed does something in response to detecting that state; 2. cases where the compiler has no compile-time static-analysis approach available for detecting a certain edge-case (e.g. integer overflow), and, further, is inhibited by the standard from generating code to detect that edge-case at runtime either; so the compiler is forced to leave the response to that condition either up to the programmer to explicitly handle, or up to the target architecture to respond to however it likes when it happens. It's clear to me that undefined behavior of the second class is sort of just part of what C "is": a language where the complexity-classes of all the primitives [well, except FP math] are constrained at compile-time, so a line of code that's O(1) on one arch won't get runtime-polyfilled into being O(N) on another in order to "make the arch sane." But my question, then, is this: would it break anything about support for the "not C machine" architectures, if the standard said that everything falling into the first class—explicit undefined behavior—was instead defined behavior, defined as "abort compilation"?

JdeBP 9y ago

They did get together to sort the mess out. They did so in the 1980s. Where do you think the idea of "ANSI function prototypes" came from?

iainmerrick 9y ago
It's hardly a complete solution, though, since they kept the zero-arg functions around as a special case! ANSI C is the version I first learned. I didn't know that weird exception for zero-args functions still existed, or had forgotten it. I could be wrong, but I bet most C programmers don't know about it.

Garfgon 9y ago

I think it's backward compatibility, not speed. Functions with no arguments lists were supported in C89, so changing it now will break someone's code somewhere. In fact not specifying a parameter list may make your code slower, as (IIRC) default argument promotions are always applied to parameters passed to such a function.

gumby 9y ago

> It really seems like the C standard maintainers and compiler vendors should just get together and sort that whole mess [Undefined behavior] out. Why do you think there is undefined behavior? Because committee members are lazy? Not every machine is a C machine (PDP-11). I used to program machines with bytes that could range from 1-36 bits (these are older than the PDP-7/PDP-11 that C was designed for). A joy to program, but the C model did not apply. You may consider these architectures obsolete, and they are, but many decisions in the design of IP, UDP and TCP (and some higher level protocols) still reflect these machines. Early C standardization efforts bent backwards to support the architectures committee members cared about. Some constraints (undef behavior etc) were removed in later standards (though the C++ committee is more aggressive in this regard than the C committee). And you well could argue that C's tight coupling to the architecture of the PDP-11 and the programming standards of the 70s holds back CPU design. Many of these undefined areas are places where compilers have the opportunity to take advantage of CPU features (e.g. vector hardware). The committee mailing list and other discussions are open -- have a read. And if you feel strongly you can even join the committee.

iainmerrick 9y ago
I realize it's there for a reason -- as I understand it, to avoid constraining compilers into generating unnecessarily awkward code for unlikely edge cases. And that fits with one of C's main advantages, being fast and lightweight. But in the last few years I've read many, many articles about problems that crop up when optimizing C compilers do weird things to reasonable-looking code, citing "undefined behavior" as an excuse. I can't say for sure if I've hit issues like that myself, but I've certainly used libraries that have. Maybe the problem lies squarely with the compiler vendors, but the language spec enables them.
- geezerjay 9y ago
  > do weird things to reasonable-looking code, citing "undefined behavior" as an excuse. If the behaviour is undefined then the code is broken. Programmers need to learn the language instead of putting together hail mary code expecting it to somehow work in spite of the language specifically telling them that they should not expect any defined behavior out of it. People who whine about undefined behavior are like kids who insist in jamming their fingers in a electric socket and whine when they get a shock.
  - iainmerrick 9y ago
    It would be nice for the compiler to be a friend and ally, rather than a mischievous opponent.
derefr 9y ago
AFAICT, "undefined behavior" refers to two entirely-separate classes of behavior: 1. cases where the compiler explicitly recognizes a certain permutation of compilation-state as matching some pattern for what the standard calls "undefined behavior"—and then is unconstrained as to what it does in response, but indeed does something in response to detecting that state; 2. cases where the compiler has no compile-time static-analysis approach available for detecting a certain edge-case (e.g. integer overflow), and, further, is inhibited by the standard from generating code to detect that edge-case at runtime either; so the compiler is forced to leave the response to that condition either up to the programmer to explicitly handle, or up to the target architecture to respond to however it likes when it happens. It's clear to me that undefined behavior of the second class is sort of just part of what C "is": a language where the complexity-classes of all the primitives [well, except FP math] are constrained at compile-time, so a line of code that's O(1) on one arch won't get runtime-polyfilled into being O(N) on another in order to "make the arch sane." But my question, then, is this: would it break anything about support for the "not C machine" architectures, if the standard said that everything falling into the first class—explicit undefined behavior—was instead defined behavior, defined as "abort compilation"?