From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23818 invoked by alias); 27 Apr 2012 14:49:18 -0000 Received: (qmail 23748 invoked by uid 22791); 27 Apr 2012 14:49:16 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 27 Apr 2012 14:49:00 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1SNmTi-0003zi-Rb from Maciej_Rozycki@mentor.com ; Fri, 27 Apr 2012 07:48:58 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 07:48:56 -0700 Received: from [172.30.0.84] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Fri, 27 Apr 2012 15:48:57 +0100 Date: Fri, 27 Apr 2012 15:14:00 -0000 From: "Maciej W. Rozycki" To: Jan Kratochvil CC: Subject: Re: [PATCH] microMIPS support In-Reply-To: <20120427020603.GA24531@host2.jankratochvil.net> Message-ID: References: <20120426183713.GA21029@host2.jankratochvil.net> <20120426192611.GA24056@host2.jankratochvil.net> <20120427020603.GA24531@host2.jankratochvil.net> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00991.txt.bz2 On Fri, 27 Apr 2012, Jan Kratochvil wrote: > > But are you absolutely sure that it was a supported construct with C89 or > > are you only assuming having no counter-evidence? > > (a) C89 == C90: http://en.wikipedia.org/wiki/C89_%28C_version%29#C89 > (b) The suggested 'const' construct is compliant with 'gcc -std=c89 -pedantic'. > This does not prove it is really C89 compliant but: In the absence of an actual copy of the standard itself checking with a third-party known-C89/C90-only compiler would be better. > (c) GDB codebase is already not C90 compliant, at least not > with 'gcc -std=c89 -pedantic', as discussed in the thread > Re: [no-commit-intention] Naive unnamed fields for main_type > http://sourceware.org/ml/gdb-patches/2012-02/msg00146.html These are merely bugs IMO, that should simply be fixed instead (and some are outside GDB, readline for one is not a part of GDB, just bundled for convenience, and optional, though I'd agree that using GDB's CLI without readline is a bit painful). We shouldn't deliberately create new bugs on the basis we already have some. ;) As I say I'd be first happy to hear we can finally switch to C99. > I checked according to C90 const array means const elements of the array. > And 'const type *var;' does not make 'var' const - my conclusion is qualifier > 'const' is therefore independent for 'var' and the target type. "const type *var" is a pointer to a variable of "const type" type. "type *const var" is a const pointer to a variable of "type" type. > > At the time I learnt C (some 18 years ago) that certainly wasn't a > > construct I had seen in any language reference > > I do not see any problem using const for an array, what specifically do you > see wrong here? Not a const array, but a const pointer. > > AFAIK we still require our code to conform to C89 (fortunately not K&R > > anymore) or we could use lots of good stuff, > > I agree. I find const arrays compliant with C89. But this is about an array of const pointers, I wouldn't see any problem with an array of const arithmetic-type elements. So far it's your word against mine, I'd like to hear from someone else too. I'll accept whatever their decision will be. Maciej