From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27033 invoked by alias); 22 Apr 2003 03:27:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 27007 invoked from network); 22 Apr 2003 03:27:28 -0000 Received: from unknown (HELO franka.aracnet.com) (216.99.193.44) by sources.redhat.com with SMTP; 22 Apr 2003 03:27:28 -0000 Received: from BitWagon.com (216-99-213-225.dsl.aracnet.com [216.99.213.225]) (authenticated bits=0) by franka.aracnet.com (8.12.8/8.12.5) with ESMTP id h3M3Qm8a020556 for ; Mon, 21 Apr 2003 20:26:48 -0700 Message-ID: <3EA4B654.9030800@BitWagon.com> Date: Tue, 22 Apr 2003 06:52:00 -0000 From: John Reiser Organization: - User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Re: Const warning? (was: Re: [Patch] More redundant...) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg01040.txt.bz2 <> > > I thinking about a warning for variables which the compiler can see > > are not modified. Something like: > > > > Warning: Variable x should be const. This is easy for scalars (parameters or locals), but hard for array and struct/union types. This is too bad, because such a message probably would prevent several bugs per programmer per year. Extensive use of 'const' is very beneficial for maintenance and documentation. It's amazing how helpful it is to see lots of 'const': if it compiles, then the compiler has told you that the value does not vary in time, so you don't have to check. A couple years ago I got fairly far along on this, starting with gcc-2.96. The message I chose was "warning: const omitted". There was a bit available in the type word (the next-to-last unused bit), and I used that. Then you just look at all places that the compiler would complain about using as an lvalue something that is declared const, and mark the type as non-const instead. Increment/decrement required some fiddling, as did taking the address of an object. At the end of each scope, then walk the declarations and complain for those objects that are not marked as non-const, and also not marked as const. This worked quite well for a while [the number of warnings is large], but then I discovered the fundamental problem with the type system in 2.96. The existing type system in 2.96 has the property that, after declaration is finished, then the type word itself is a constant, and can be freely copied (passed as a parameter, etc.), indirected (have '*' applied to it), and selected (have '.member' applied to it). But for non-const marking in one pass, all the non-zero non-const bits must be forwarded to the "master" copy for the expression [object], and doing so is difficult. So I gave up. Side note: The prefered syntax ought to be "char const *foo;" instead of "const char *foo;". Why? Because then there is a simple rule for where 'const' may appear in a declaration: immediately to the left of every identifier, and immediately to the left of every '*'. So the "maximal const" form in this case is "char const *const foo;". -- John Reiser, jreiser@BitWagon.com