c++ - Does "Undefined Behavior" really permit *anything* to happen? -


this question has answer here:

edit: question not intended forum discussion (de)merits of undefined behavior, that's sort of became. in case, this thread hypothetical c-compiler no undefined behavior may of additional interest think important topic.

the classic apocryphal example of "undefined behavior" is, of course, "nasal demons" — physical impossibility, regardless of c , c++ standards permit.

because c , c++ communities tend put such emphasis on unpredictability of undefined behavior , idea compiler allowed cause program literally anything when undefined behavior encountered, had assumed standard puts no restrictions whatsoever on behavior of, well, undefined behavior.

but relevant quote in c++ standard seems be:

[c++14: defns.undefined]: [..] permissible undefined behavior ranges ignoring situation unpredictable results, behaving during translation or program execution in documented manner characteristic of environment (with or without issuance of diagnostic message), terminating translation or execution (with issuance of diagnostic message). [..]

this specifies small set of possible options:

  • ignoring situation -- yes, standard goes on have "unpredictable results", that's not same compiler inserting code (which assume prerequisite for, know, nasal demons).
  • behaving in documented manner characteristic of environment -- sounds relatively benign. (i haven't heard of documented cases of nasal demons.)
  • terminating translation or execution -- diagnostic, no less. ub behave nicely.

i assume in cases, compilers choose ignore undefined behavior; example, when reading uninitialized memory, presumably anti-optimization insert code ensure consistent behavior. suppose stranger types of undefined behavior (such "time travel") fall under second category--but requires such behaviors documented , "characteristic of environment" (so guess nasal demons produced infernal computers?).

am misunderstanding definition? these intended mere examples of constitute undefined behavior, rather comprehensive list of options? claim "anything can happen" meant merely unexpected side-effect of ignoring situation?

edit: 2 minor points of clarification:

  • i thought clear original question, , think people was, i'll spell out anyway: realize "nasal demons" tongue-in-cheek.
  • please not write an(other) answer explaining ub allows platform-specific compiler optimizations, unless also explain how allows optimizations implementation-defined behavior wouldn't allow.

yes, permits happen. note giving examples. definition pretty clear:

undefined behavior: behavior international standard imposes no requirements.


Comments

Post a Comment

Popular posts from this blog

android - InAppBilling registering BroadcastReceiver in AndroidManifest -

i'm implementing inapp billing in android app. works well, however, i'm trying decouple broadcast receiver activity manifest. suggestion in android's trivialdrive sample: // important: dynamically register broadcast messages updated purchases. // register receiver here instead of <receiver> in manifest // because call getpurchases() @ startup, therefore can ignore // broadcasts sent while app isn't running. // note: registering listener in activity bad idea, done here // because sample. regardless, receiver must registered after // iabhelper setup, before first call getpurchases(). currently there's class extends broadcastreceiver : public class iabbroadcastreceiver extends broadcastreceiver { /** * intent action receiver should filter for. */ public static final string action = "com.android.vending.billing.purchases_updated"; private final iabbroadcastlistener mlistener; public iabbroadcastreceiver(iabbroadcastlistener listener) { m...
Read more

python Tkinter Capturing keyboard events save as one single string -

is possible store keyboard events 1 string? code below stores 1 char , prints it. card reader or bar code reader, contains collection of character/ string not 1 character @ time. goal save char pressed text variable. from tkinter import * root = tk() def key(event): text= event.char text+= event.char print ("pressed", text) def callback(event): frame.focus_set() print ("clicked at", event.x, event.y) frame = frame(root, width=100, height=100) frame.bind("<key>", key) frame.bind("<button-1>", callback) frame.pack() root.mainloop() currently, creating text variable , everytime key() function gets called, , text stores last character typed. you can define text module level variable , , use module level text inside key function - text = '' def key(event): global text text+= event.char print("pressed", text)
Read more

sql server - Why does Linq-to-SQL add unnecessary COUNT()? -

here tables: create table customer ( cid int primary key, name varchar(32) ) create table ord ( oid int primary key, cid int foreign key references customer, address varchar(20) ) here's linq-to-sql statement: var aaa = c in db.customer select new { c, o = c.ord.tolist() }; and here's inexplicable query generated linq-to-sql: select [t0].[cid] [cid], [t0].[name] [name], [t1].[oid] [oid], [t1].[cid] [cid2], [t1].[address] [address], (select count(*) [dbo].[ord] [t2] [t2].[cid] = [t0].[cid]) [value] [dbo].[customer] [t0] left outer join [dbo].[ord] [t1] on [t1].[cid] = [t0].[cid] order [t0].[cid], [t1].[oid] i want understand how rid of count(*) part. it's entirely uncalled for! linq needs count(*) in order determine number of entries returned o = c.ord.tolist() .
Read more