Talk:Undefined behavior
From Wikipedia, the free encyclopedia
I got rid of the todo-box comment that "UB is not a feature", because clearly it is a feature of many programming languages. (It's not usually a "feature" in the marketingspeak sense, of course.)
I also subst'ed the {{todo}} template, so it would be around to comment on. I don't mind if it's removed. (The anonymous editor makes a good point about the #pragma paragraph, though; it really is out of place.) --Quuxplusone 02:47, 6 December 2006 (UTC)
- Hi :-) I'm not sure whether the term "feature" applies… native speakers are in a much better position to decide, and perhaps someone can come up with a wording which avoids the term altogether. BTW, I don't think subst'ing the template was a good idea. Why did you do that? (You made me suspect that I wasn't logged in when inserting my comments but I was :-) Not sure why you say I'm "anonymous". I didn't put a signature after the comments, if that's what you mean, as I thought it wasn't important). —Gennaro Prota•Talk 12:06, 6 December 2006 (UTC)
Sorry, I saw after commenting that you were logged in; I tend to assume that if a Talk-page comment isn't signed, it's "anonymous". :) I subst'ed the template so that it would be here on the page in case anyone wondered in three months what I was talking about... except that I just noticed(!) that it didn't actually substitute in the text, which is what I was trying to do. So I've reverted my subst'ing.
Regarding "feature": UB is a "feature" of C and C++ in the same way that currying is a "feature" of ML, or funny operators are a "feature" of APL: it's something a C or C++ programmer is going to have to deal with, because it's a feature of the language. If there's a better word, I'd support it; the only other word I can think of right now is "element", and that has even more confusing overloads in a programming context. :) --Quuxplusone 23:37, 6 December 2006 (UTC)
I took out the nasal demons part of the todo-box because it is just "[r]ecognized shorthand on the Usenet group comp.std.c for any unexpected behavior of a C compiler on encountering an undefined construct.", not actual demons coming out of your nose. In other words, unexpected results is a perfectly possible result of undefined behavior. Also, maybe the todo-box should be taken out altogether because the article currently mentions that undefined and implementation-defined behavior are different. — Daniel 00:19, 13 July 2007 (UTC)
- Done. --Quuxplusone 06:59, 13 July 2007 (UTC)

