From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32373 invoked by alias); 23 Sep 2013 15:47:23 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 32359 invoked by uid 89); 23 Sep 2013 15:47:23 -0000 Received: from asbnvacz-mailrelay01.megapath.net (HELO asbnvacz-mailrelay01.megapath.net) (207.145.128.243) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 23 Sep 2013 15:47:23 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: asbnvacz-mailrelay01.megapath.net Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.49]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 822D91EE4FC5 for ; Mon, 23 Sep 2013 11:47:19 -0400 (EDT) Received: (qmail 1818 invoked from network); 23 Sep 2013 15:47:19 -0000 Received: by simscan 1.4.0 ppid: 15723, pid: 852, t: 0.3531s scanners: clamav: 0.88.2/m:52/d:10739 Received: from unknown (HELO oak.schemamania.org) ([216.254.83.208]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 23 Sep 2013 15:47:18 -0000 Received: from oak.schemamania.org (localhost [IPv6:::1]) by oak.schemamania.org (Postfix) with SMTP id 2033330E0F7F for ; Mon, 23 Sep 2013 11:47:18 -0400 (EDT) Date: Mon, 23 Sep 2013 15:47:00 -0000 From: "James K. Lowden" To: gcc-help@gcc.gnu.org Subject: Re: how to make gcc warn about arithmetic signed overflow Message-Id: <20130923114717.1033f2b8.jklowden@schemamania.org> In-Reply-To: References: <20130921164609.GC3086@a.lan> <20130921174229.GD3086@a.lan> <20130923000355.fa2a964c.jklowden@schemamania.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00158.txt.bz2 On Mon, 23 Sep 2013 08:54:57 +0100 Jonathan Wakely wrote: > > const_cast > > will surely let you change the value of a const object without > > treading into undefined behavior. > > No, it surely won't! > > If an object is defined as const in the first place then it is > undefined behaviour to change it. ... > And the definitive reference, 7.1.6.1 [dcl.type.cv]/4: > "Except that any class member declared mutable (7.1.1) can be > modified, any attempt to modify a const object during its lifetime > (3.8) results in undefined behavior." Oh, gee, someone is wrong on the Internet again. Thanks for the correction. As far as I can make out, the only remaining reliable use of const_cast is to convert a type that was passed as a const reference back to original (non-const) type, if such it was. 7.1.6 is itself mutable, it turns out. My yellowed ARM, copyright 1990, is considerably more relaxed on the question. (And considerably easier to read. I don't know how anyone learns C++ these days, so dense is the technical terminology.) Stroustrup's commentary says, "adding const to a declaration ensures that an object to which the const is applied cannot have its value changed ... unless an explicit type conversion is used.... const does not mean 'store in readonly memory' nor does it mean 'compile time constant'." Regarding errors, it mentions only that a const object might wind up in "readonly" memory, in which case attempts to modify it will result in a runtime error: "The effect of a write operation on any part of [a const] object is either an addressing exception or the same as if the object had been non-const". That is, either it works or you get an exception from the hardware, depending on whether the computer can execute the code. Notably missing from that description is the possibility that the compiler can do anything it wants because the programmer colored outside the lines. The purpose of const was to aid the programmer in preventing accidental changes to a variable. Because compiler writers care more for efficiency than convenience, it's slowly metastasizing into a no man's land between programmer and machine. --jkl