From -5800257759129845305 X-Google-Thread: f78e5,3c316a202087bfac X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.speakeasy.net!news.speakeasy.net.POSTED!not-for-mail NNTP-Posting-Date: Mon, 17 Apr 2006 09:50:02 -0500 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on ak74.algebra.com X-Spam-Level: *** X-Spam-Status: No, score=3.4 required=5.0 tests=HEADER_SPAM,MISSING_HEADERS, TO_CC_NONE autolearn=disabled version=3.1.1 X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Original-To: std-c++@mailman.ucar.edu Delivered-To: std-c++@mailman.ucar.edu Delivered-To: std-c++@ucar.edu From: "ThosRTanner" Newsgroups: comp.std.c++ Subject: Re: Defining undefined, etc., behavior Organization: http://groups.google.com Message-ID: <1145261505.465774.326140@z34g2000cwc.googlegroups.com> References: <123m587c3abqge4@corp.supernews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Complaints-To: groups-abuse@google.com User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: z34g2000cwc.googlegroups.com; posting-host=199.172.169.15; posting-account=WDL57QwAAADh6I7Opo5K2PCbyz8hJhRA X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Approved: Fergus Henderson , moderator of comp.std.c++ X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Date: Mon, 17 Apr 2006 09:44:50 CST Lines: 79 NNTP-Posting-Host: 65.182.171.162 X-Trace: sv3-jXdLyGWgN6z4PG5XPPEW5sSwyMaGUbOr6tkeT9AOR1OZCCLb9EkjdRWfqm4jtgVPkZ0vRnKG98bF96S!8kgTGCOGta47V2N0H58wUuiEZUO0j5M3ZVnteZB9oxnteeLbba3T7YnVCdUiCO1PR6rrD4+oRjr5!ZxDS6BBOpkidM7YnBjZncknpnPX0qiU6LeV9OKux2v0= X-Complaints-To: abuse@speakeasy.net X-DMCA-Complaints-To: abuse@speakeasy.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.std.c++:1569 John Nagle wrote: > Scott Meyers wrote: > > What work has been done on eliminating undefined behavior in C or C++? > > Off the top of my head, some undefined behavior is due to "stupid user > > behavior," e.g., indexing beyond the end of an array, dereferencing a > > null pointer, etc. Other undefined behavior -- or maybe it's > > unspecified or implementation-defined behavior, I can never keep those > > terms straight -- arises from flexibility for implementers, e.g., order > > of evaluating arguments for function calls, order of expression > > evaluation between sequence points, order of initialization of non-local > > statics defined in separate translation units. I'd be interested in any > > work that's been done on identifying these kinds of behavior (beyond > > grepping the standards for "undefined", "unspecified", etc.) and > > suggesting ways to eliminate or avoid them, ideally without any obvious > > runtime cost. (Checking array bounds would fail the "no obvious runtime > > cost" test, while defining function argument evaluation order would > > pass, because, well, because it's not obvious to me that imposing a > > required order would necessarily incur a runtime penalty :-}) > > There really is more than one type of undefined behavior, and > classifying the ones in the C++ specification might be useful. > A few obvious classes: > > -- Violations of the storage model > Examples: > -- Indexing beyond the limits of an array > -- Use of an iterator after an invalidating operation on its collection > > -- Violations of the construction model > Examples: > -- Access to an object before the constructor has completed or after > the destructor has run (includes references to uninitialized variables) > -- Casting into a type for which not all possible values are valid > (pointers, constructed objects) > > -- Violations of the sequencing model > Examples: > -- An expression with calls to two functions with (interfering?) side effects > for which the evaluation rules do not explicitly determine the order > of evaluation > > -- Violations of the concurrency model (insofar as C++ has one) > Examples: > -- Non-volatile data shared between two threads. > > With a taxonomy like this, some issues become clearer. The last three > categories, for example, are potentially detectable at compile time. > The issues for those categories revolve around whether certain > formally undefined behavior should be permitted. > > John Nagle > Animats > I think to that it would be worth adding instances where behaviour isn't undefined but at best unhelpful and arguably completely stupid, such as: Inheriting from a class with a non-virtual destructor - this is well defined, but can break code in a really nasty way. Incorrectly overriding virtual functions (again, the behaviour is well defined, but results in a source of almost endless confusion) throwing an exception that isn't in a clients throw() spec and isn't caught by the client All of these can be detected by the compiler. All of these behaviours are not (to my mind) intuitive. And they all (except the last) take a lot of debugging time to sort out. They do, in my experience, put the novice off the language. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]