From -1389167438443676107 X-Google-Thread: f78e5,3c316a202087bfac X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news3.google.com!news4.google.com!news.glorb.com!news.alt.net!comp-std-cpp-robomod!not-for-mail From: kuyper@wizard.net Newsgroups: comp.std.c++ Subject: Re: Defining undefined, etc., behavior Date: 15 Apr 2006 01:00:10 GMT Organization: http://groups.google.com Lines: 25 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <1145062028.095134.267190@z34g2000cwc.googlegroups.com> References: <123m587c3abqge4@corp.supernews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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=4.0 required=5.0 tests=HEADER_SPAM,MISSING_HEADERS, NO_REAL_NAME,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 X-Trace: posting.google.com 1145062034 6241 127.0.0.1 (15 Apr 2006 00:47:14 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 15 Apr 2006 00:47:14 +0000 (UTC) User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20060202 Fedora/1.0.7-1.2.fc4 Firefox/1.0.7,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: z34g2000cwc.googlegroups.com; posting-host=66.234.255.45; posting-account=bPBxkgwAAABzUwlEAMy-xGlLqZFJ5Jz_ X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-MIME-Autoconverted: from quoted-printable to 8bit by mulga.cs.mu.OZ.AU id k3F0lRD7027221 X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Xref: g2news1.google.com comp.std.c++:1547 "Tom�s" wrote: > > So at the end of the day, you're either writing portable code, or platform > specific code. For both, avoid undefined behaviour. Not quite. In the context of the C++ standard, "undefined behaviour" means only that the C++ stanadard chooses not to provide any definition for the behavior. That doesn't prevent a particular implementation from providing it's own, unportable definition of the behavior. It's commonplace for extensions to be implemented by defining standard-undefined behavior. For instance, it's commonplace for an implementation to implement an extension by requiring #inclusion of a non-standard header file that defines or declares identifiers whose names are reserved to the implementation, which has undefined behavior according to 17.4.3.1p3. There's nothing wrong with code that's intended to be non-portable relying on a particular implementation's definition of behavior that is otherwise undefined. --- [ 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 ]