Talk:Undefined behavior

message: 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  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)
replies: text: Done. --Quuxplusone 06:59, 13 July 2007 (UTC)
thread_title: Untitled

message: *http://blog.djmnet.org/2008/08/05/a-pragmatic-decision/ quotes Unix Review from March 1988, which claims that GCC 1.17 tried to execl emacs, then hack, then rogue. This is the wrong order, at least if we assume that the order didn't change between 1.17 and 1.21.
*http://www.oldlinux.org/Linux.old/gnu/gcc-1/gcc-1.21.tar.bz2 shows that the actual order in GCC 1.21 was hack, rogue, emacs.
*http://www.oldlinux.org/Linux.old/gnu/gcc-1/gcc-1.40.tar.bz2 shows that by GCC 1.40 the code had been #ifdef'ed out, but the order remained hack, rogue, emacs.
*http://everything2.com/e2node/%2523pragma gets the order right: nethack, rogue, emacs. (Note that e2 writes "nethack" instead of "hack"; "hack" is the executable GCC actually tried to execute, but by 1988 "NetHack" was the name of the game.)
So, the only "verifiable" paper source we have — Unix Review — gives the wrong information! --Quuxplusone (talk) 21:47, 2 November 2008 (UTC)
thread_title:  Emacs first, or NetHack first? 

message: It be great if this article explained the differences of undefined behavior with unspecified behavior. --Abdull (talk) 09:05, 4 December 2009 (UTC)
thread_title:  Unspecified behavior 

message: Should any examples be given for compilers exploiting undefined behavior for optimization purposes? For example GCC optimizes away a lot of comparisons involving signed integers by ignoring the possibility of overflow. Hiiiiiiiiiiiiiiiiiiiii (talk) 20:18, 18 May 2011 (UTC)
replies: text: Done -- Martinkunev (talk) 14:26, 25 January 2016 (UTC)
thread_title:  Optimizations 

message: I think the #pragma joke section does not belong here. #pragma is not undefined, it is implementation-defined behavior. And even though we do not have the specific article, I believe unspecified behavior is a much better match. --Mormegil (talk) 21:23, 21 October 2012 (UTC)
replies: text: I agree, and thus removed the section. Sebastian (talk) 14:43, 24 April 2014 (UTC)
thread_title:  #pragma joke 

message: To User:Namezero111111 and other editors who are changing the example which uses pointer arithmetic (via array subscripting) to produce undefined behaviour, please refer to ISO/IEC 9899:1999 §6.5.6 ¶8: "When an expression that has integer type is added or subtracted from a pointer, the result has the type of the pointer operand… If both the pointer and result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined." As you can see, the mere evaluation of such an expression results in undefined behaviour; no dereferencing or assignment need have occurred. —Psychonaut (talk) 09:59, 9 September 2013 (UTC)
thread_title:  Undefined behaviour resulting from pointer arithmetic 

message: There's an entire function in C that has undefined behaviour: gets. Nothing guarantees that the string from stdin fits into the buffer passed to the function. --88.113.189.17 (talk) 15:47, 1 November 2013 (UTC)
replies: text: Just because a function can be used to invoke undefined behaviour doesn't mean that the "entire function… has undefined behaviour".  gets() is pretty useless (not to mention a horrible security risk) in the general case, but its behaviour is perfectly well-defined when the size of the input is known to be less than or equal to the size of the buffer. —Psychonaut (talk) 15:56, 1 November 2013 (UTC)
replies: text: When is the size of the user input known? You can't trust the user to always input the correct amount of data. If the user happens to write a correctly sized string, the function will behave as expected, but the concept of undefined behaviour doesn't exclude expected behaviour. A program which writes to freed memory can work as expected too, with luck. --88.113.189.17 (talk) 22:37, 2 November 2013 (UTC)
replies: text: Again, you are confusing actual and potential invocation of undefined behaviour.  Integer division by zero is also undefined behaviour, but that doesn't mean that the "entire division operator in C has undefined behaviour".  —Psychonaut (talk) 16:14, 4 November 2013 (UTC)
thread_title:  gets 

message: There is no advantage at all to this example. All it means is that the "naïve" method of detecting overflow cannot work due to being UB, therefore developers have to bend over backwards to somehow detect the overflow before it happens. It's easy to understand why it's UB when one remembers the C standard does not in any way guarantee that a platform uses Two's complement and assuming it does is bad, but I don't see why one would spin that as a good thing. Medinoc (talk) 14:06, 2 September 2017 (UTC)
replies: text: I agree it's a confused passage. the positive point that the person who wrote that is making is that the optimizer can optimize away code saving space and time. The problem is, he chose a sample of code that might be considered to be "here's how you can use C's efficiency (it doesn't try to detect overflow) and undefined behavior on a known local architecture (therefore defined behavior) to detect overflow if you insert the code appropriate for your semantics" which is illustrating the positive side of C's "close to the metal" nature, and illustrating the pitfalls of undefined behavior and how certain optimizations can screw up that mode. It would be a perfectly good example if it was all explained like that. Also as a small quibble, two's complement arithmetic which you mention is identical to unsigned binary arithmetic which means it doesn't actually require processor support, except for the overflow and sign status flags; otoh other representations for numbers and negative numbers (BCD, sign bit, or ones complement) require their own specialized status flags 66.65.118.87 (talk) 14:24, 2 February 2020 (UTC)
thread_title:  Why is the integer overflow thing listed as a benefit? 

message: The article states that 
The following example will however cause undefined behavior in both C++ and C. 
i = i++ + 1; // undefined behavior
This is not true in C++17, because = has been added as a sequence point, forcing the right side to evaluate before the left. See https://stackoverflow.com/q/47702220 for details and sources.
A better example might be i++ + i++.  — Preceding unsigned comment added by 2003:D8:DBC9:8700:9D1E:F4B2:5AC6:B463 (talk) 06:57, 9 April 2019 (UTC)
replies: text: in . Thanks for pointing this out. Please consider being bolder next time. You could have fixed this 2 years ago. BernardoSulzbach (talk) 18:36, 9 July 2021 (UTC)
thread_title:  Outdated example: i = i++ + 1 is no longer undefined behavior in C++17. 

message: The below example is included in the text but if this is C code, this is incorrect as the NULL pointer is implementation defined. This means that it is not necessarily zero.
 int arr[4] = {0, 1, 2, 3};
 int *p = arr + 5;  // undefined behavior for indexing out of bounds
 p = 0;
 int a = *p;        // undefined behavior for dereferencing a null pointer
I believe this is, however, valid C++ code.
In order to make clear the distinction I would recommend replacing:
p = 0;
with
p = NULL;
for C or:
p = nullptr;
for C++.  — Preceding unsigned comment added by MaxCampman (talk • contribs) 19:17, 10 April 2019 (UTC)
replies: text: "as the NULL pointer is implementation defined" This is a popular misconception: Yes, the integer value of a null pointer is implementation defined (i.e. what you get if you cast it to int, but the C standard says that void* p = 0; creates a null pointer (and that the macro NULL is just the integer 0). See C99 standard, section 6.3.2.3: "An  integer  constant  expression  with  the  value  0,  or  such  an  expression  cast  to  type void* ,is called a null pointer constant. If a null pointer constant is converted to a pointer type, the resulting pointer,called a null pointer,is guaranteed to compare unequal to a pointer to any object or function.". Confusing maybe, but it's the standard :-). Sebastian (talk) 07:30, 11 April 2019 (UTC)
thread_title:  Undefined behaviour caused by dereferencing a null pointer 

message: The article asserts that "In C the use of any automatic variable before it has been initialized yields undefined behavior".
However, this does not seem to be the case. See thishttps://stackoverflow.com/questions/11962457/why-is-using-an-uninitialized-variable-undefined-behavior/11965368#11965368 post by Jens Gustedt, for example, as well as varioushttps://lists.cam.ac.uk/pipermail/cl-c-memory-object-model/2019-October/msg00006.html WG14 discussions. Worse yet, this appears to be rather underspecifiedhttp://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm, and different to how it is treated by C++https://eel.is/c++draft/basic.indet#2https://lists.isocpp.org/liaison/2021/02/0346.php.
I'm struggling to think of the best way to update the article to reflect this information, without unnecessarily confusing people.
Deltax64 (talk) 06:14, 11 March 2021 (UTC)
thread_title:  Using uninitialized objects of automatic storage duration