From 7899709255587660758 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,7522e5259f7267d6 X-Google-Attributes: gidf78e5,public From: jpotter@falcon.lhup.edu (John Potter) Subject: Re: x = y = z; Undefined? Date: 2000/01/12 Message-ID: <387bb7c0.39451037@news.csrlink.net>#1/1 X-Deja-AN: 571439909 X-NNTP-Posting-Host: 209.173.93.86 Approved: stephen.clamage@sun.com (comp.std.c++) References: <3876254a.30903561@news.csrlink.net> <3879ca08.3142429@news.csrlink.net> <387b3c32.7816532@news.csrlink.net> <387B6338.FCE9D984@sensor.com> X-UID: 0000000001 X-Status: $$$T X-Trace: newscene.newscene.com 947638212 209.173.93.86 (Tue, 11 Jan 2000 18:50:12 CST) Organization: Newscene Public Access Usenet News Service (http://www.newscene.com/) NNTP-Posting-Date: Tue, 11 Jan 2000 18:50:12 CST Newsgroups: comp.std.c++ Originator: clamage@taumet On 11 Jan 2000 17:34:35 GMT, Ron Natalie wrote: : : : : John Potter wrote: : > : > I disagree. The standard requires that expressions be evaluated as : > written. : : Where does it say that (hint: it doesn't, absent sequence points, the : order of evaluation is UNSPECIFIED). Wrong. The order of evaluation of expressions is defined by the grammar. The order of evaluation of subexpressions and parameters to functions is unspecified. (a + b) * (c + d) Either subexpression may be evaluated first, and even in parallel, but they must both be evaluated prior to the multiply. (i1 = i2) += i3 Either subexpression may be evaluated first, and even in parallel, but they must both be evaluated prior to the add-equal. Storing the result is not part of the evaluation. Results may be retained where ever until a sequence point at which time the values must be stored. This freedom allows the compiler to make optimizations on the assumption that there is no undefined behavior. It does not allow violating the grammar. : Sorry, this is wrong. The order of evaluation is not specified in : C++ absent sequence points. The original poster is correct. Wrong, see above. : Changing il twice between sequence points is wrong. Yes. No arguement. So is the attempted reversal of instructions. : > Any compiler that does anything based upon : > detecting undefined behavior better be issuing a diagnostic. : : No. UNDEFINED BEHAVIOR does not require a diagnostic. There are far : too many things that are undefined behavior that it are impossible to : check for at compile time. By the standard saying it's undefined behavior : it says the compiler doesn't need to consider handling this sort of : error. You completely missed the point. Read again. Any compiler which decides to detect the presence of undefined code BETTER generate a diagnostic about its detection and not generate malicious code intended to do damage. The standard does not require the detection of undefined behavior to allow generation of reasonable optimized code. It does not grant the right to commit crimes against society when it detects undefined behavior. I rejected the reversal of instructions because it could only be done in the presence of undefined code. The optimizer which did that must also be capable of nasal daemons. No interest in fairy tales. Compiler writers are too busy trying to support the standard and provide reasonable optimization to have time for the nonsense suggested. John [ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]