From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11452 invoked by alias); 30 Oct 2013 20:24:52 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 11442 invoked by uid 89); 30 Oct 2013 20:24:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: qmta14.emeryville.ca.mail.comcast.net Received: from qmta14.emeryville.ca.mail.comcast.net (HELO qmta14.emeryville.ca.mail.comcast.net) (76.96.27.212) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Oct 2013 20:24:51 +0000 Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta14.emeryville.ca.mail.comcast.net with comcast id jXTR1m00316AWCUAEYQqWP; Wed, 30 Oct 2013 20:24:50 +0000 Received: from up.mrs.kithrup.com ([24.4.193.8]) by omta06.emeryville.ca.mail.comcast.net with comcast id jYQo1m00M0BKwT48SYQp6m; Wed, 30 Oct 2013 20:24:49 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [PATCH][ubsan] Add VLA bound instrumentation From: Mike Stump In-Reply-To: <20131030161504.GC31396@redhat.com> Date: Wed, 30 Oct 2013 20:55:00 -0000 Cc: Jason Merrill , GCC Patches , Jakub Jelinek , "Joseph S. Myers" Content-Transfer-Encoding: quoted-printable Message-Id: <8CFC1A6E-0922-4F40-A9D4-14C2E9F8E848@comcast.net> References: <20130912122655.GN23899@redhat.com> <20130925124132.GJ12296@redhat.com> <52697B9D.9000502@redhat.com> <20131025165803.GF27400@redhat.com> <526AB5CC.60408@redhat.com> <20131025190356.GG27400@redhat.com> <526AC0C9.1050003@redhat.com> <20131030145253.GB31396@redhat.com> <52712C29.3010206@redhat.com> <20131030161504.GC31396@redhat.com> To: Marek Polacek X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg02606.txt.bz2 On Oct 30, 2013, at 9:15 AM, Marek Polacek wrote: > I admit I don't understand the cleanup_points very much and I don't > know exactly where they are coming from So, here is the mental model=85 and how it is related to the standard. C+= + mandates that destructors for objects and temporary objects run no sooner= than a certain place, and no later than another place. In the implementat= ion, we choose a single point to run them, and use a cleanup point as the e= mbodiment of when destructors run. For example: cleanup (a + cleanup (b - c)) means generate this: a b c - dtors for things related to b-c + dtors for things related to a+ (b-c) that's it. Pretty simple. Now, cute little details, once you get past the= simplicity, would be things like, if you run the cleanups for b-c, at the = first dtor line above, do you also run those same things at the lower point= ? That answer is no, they only run once. If one takes an exception out of= that region, does the cleanup action run? That answer is yes. Lots of ot= her possible questions like this, all with fairly simple, easy to understan= d answers. Just ask. Now, some advanced topics=85 So, one thing you discover, if you _add_ a cl= eanup point into an expression, it will run those actions sooner that they = would have run, if you had not. One cannot meet the requirements of the la= nguage standard and just arbitrarily add cleanup points. However, construc= ts beyond the language standard, say ({ s1; s2; s3; }) + b;, one discovers = that the implementation is free to decide if there is a cleanup point for (= { }) or not. The language standard places no requirements on such code, an= d this is why we can decide. decl cleanups are strongly related to these sorts of cleanups, but lie just= outside (enclosing). I'll note their existence for completeness. See CLE= ANUP_STMT for these.