From -6396156962552671424 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,6d203f57726a4ad8 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-01-12 11:01:07 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: thp@cs.ucr.edu Newsgroups: comp.std.c++ Subject: Re: Intelligent subscript checking Date: Sun, 12 Jan 2003 19:01:04 +0000 (UTC) Organization: University of California, Riverside Lines: 46 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <3E081F9B.3090409@nycap.rr.com> <26fabedc.0301080212.14b8d54e@posting.google.com> <3E1C87E8.70409@animats.com> <3E1DEFAF.4020805@animats.com> <3E20DB45.3090806@animats.com> X-Trace: mail2news.demon.co.uk 1042398064 3612 10.0.0.1 (12 Jan 2003 19:01:04 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sun, 12 Jan 2003 19:01:04 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.05) id 18XnLx-0000w6-00 for mail2news@news.news.demon.net; Sun, 12 Jan 2003 19:01:02 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id GAA22323; Mon, 13 Jan 2003 06:00:46 +1100 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ncar.ucar.edu X-Newsgroups: comp.std.c++ X-NNTP-Posting-Date: Sun, 12 Jan 2003 10:51:42 +0000 (UTC) X-User-Agent: tin/1.5.14-20020926 ("Soil") (UNIX) (Linux/2.4.20-xfs (i686)) X-Spam-Status: No, hits=-5.1 required=5.0 tests=INVALID_MSGID,NOSPAM_INC,NO_REAL_NAME,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT version=2.41 Xref: archiver1.google.com comp.std.c++:17047 John Nagle wrote: + thp@cs.ucr.edu wrote: + + +> There have been threads here and/or in comp.std.c where members of the +> Standards committee(s) seemed to agree and to argue convincingly that, +> as soon as undefined behavior becomes proveably inevitable, the +> behavior becomes undefined. + + + As someone else pointed out, the presence of an + "assert" may make an ill-formed program correct, because + the assert causes the program to terminate in a defined way. + Thus, in a strict, rather legalistic sense, the compiler + can't hoist the assert. Thanks. That point had gone right by me. + Arguably, there needs to be some assert-like built-in used + for checking that the compiler understands to indicate improper + behavior, and can thus can hoist. But there must be agreement + on what it is. Right. Perhaps, the Standard could require that certain instances of undefined behavior be "anticipated" via the throwing of special exceptions that gives the kind and place of that anticipated undefined behavior. Such throws must occur before the invocation of undefined behavior and may occur whenever the anticipated undefined behavior becomes "normally inevitable," i.e., provably would occur if no anticpation throwing intervened. I think/hope that this approach allows the implementation to handle efficiently loops that might violate array bounds and/or dereference a null pointer. Tom Payne --- [ 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.jamesd.demon.co.uk/csc/faq.html ]