From -6619094590909956354 X-Google-Thread: f78e5,3c316a202087bfac X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news3.google.com!news2.volia.net!newsfeed01.sul.t-online.de!t-online.de!newsfeed.vmunix.org!peer-uk.news.demon.net!kibo.news.demon.net!mutlu.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: NULL@NULL.NULL ("Tom�s") Newsgroups: comp.std.c++ Subject: Re: Defining undefined, etc., behavior Date: Fri, 14 Apr 2006 15:52:01 GMT Organization: Eircom.Net http://www.eircom.net Lines: 147 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <123m587c3abqge4@corp.supernews.com> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Transfer-Encoding: quoted-printable X-Trace: news.demon.co.uk 1145029928 29108 158.152.254.254 (14 Apr 2006 15:52:08 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Fri, 14 Apr 2006 15:52:08 +0000 (UTC) X-Original-To: std-c++@mailman.ucar.edu X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: Xnews/4.06.22 X-MIME-Autoconverted: from 8bit to quoted-printable by mulga.cs.mu.OZ.AU id k3EFq4D7006885 X-Amavis-Alert: BAD HEADER Non-encoded 8-bit data (char E1 hex) in message header 'From': From: "Tom\341s" \n X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Path: comp-std-cpp-robomod!not-for-mail X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id k3EFq1nh006850; Sat, 15 Apr 2006 01:52:01 +1000 (EST) X-NNTP-Posting-Date: Fri, 14 Apr 2006 16:07:01 BST X-Delivered-To: std-c++@ucar.edu X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:1533 Scott Meyers posted: > What work has been done on eliminating undefined behavior in C or C++?=20 > 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. I agree. Stuff like the following is just "stupid": int *p; *p =3D 5; //Undefined Behaviour > 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=20 > non-local statics defined in separate translation units. You're either writing: a) Portable 100% Standard-compliant Code b) Platform-specific code / Implementation-specific code If you're writing portable code, then the solution is simple: Don't allow= =20 situations that could, depending on the implementation, result in Undefin= ed=20 Behaviour. Here's an example: char p =3D 120; char +=3D 100; //Could cause Undefined Behaviour This has no place in portable code. On the other hand, if you're programming for a platform where you know th= at=20 "char" is unsigned, then you are free to do the above. > 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. Basically you just have to know the C++ language; you've to know things=20 like: a) It's undefined behaviour for a signed integral type to overflow. b) It's undefined behaviour to check an intrinsic variable's value if it = was=20 never initialised. > (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 > :-})=20 We already have the C++ programming language. Unless we change it with=20 future Standards, we can simply work around any problems. Instead of=20 writing: j =3D f() + g(); Simply write: j =3D f(); j +=3D g(); =20 > My motivation for the question is that it's my understanding that=20 > safety-critical applications typically identify language subsets to > reduce risk, and they then typically impose usage rules on the features > remaining in the subsets to further reduce risk. One form of risk is > unpredictable program behavior, and such behavior can arise from the > use of language constructs with=20 > undefined/unspecified/implementation-defined behavior, so I'm wondering > what work has been done on identifying such constructs and dealing with > them. None that I'm aware of -- because none is needed. Here's an example of ho= w I=20 write portable code: I invariably use Windows XP, so all my programs are Win32. On Win32, the=20 built-in types are as follows: char =3D 8 bits short =3D 16 bits int =3D 32 bits long =3D 32 bits On my platform, I can safely store a 32-bit number in an "int". If I'm=20 writing portable code however, I won't. Why? Because the Standard says an= =20 "int" can be 16-Bit. Thankfully, it also says that a "long" must be at le= ast=20 32-Bit, so I use a "long" when I need to store a 32-Bit number. Also, there may be some systems where, if you don't initialise a local=20 variable, that it's value is 0, as follows: void Func() { int k; k +=3D 56; //k's value is now 56 on some platforms } However, the Standard doesn't guarantee this, so I don't do it in portabl= e=20 code (I wouldn't do it in platform-specific code either -- I'd opt to=20 explicitly set it to zero). So at the end of the day, you're either writing portable code, or platfor= m=20 specific code. For both, avoid undefined behaviour. For the former, avoid= =20 implementation specific behaviour which may result in undefined behaviour= =20 depending on flexibility given to the plaform/implementation. -Tom=E1s --- [ 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 ]