From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15052 invoked by alias); 26 Apr 2012 21:52:54 -0000 Received: (qmail 15044 invoked by uid 22791); 26 Apr 2012 21:52:53 -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; Thu, 26 Apr 2012 21:52:36 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SNWc7-0005wm-85 from Maciej_Rozycki@mentor.com ; Thu, 26 Apr 2012 14:52:35 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 14:52:34 -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; Thu, 26 Apr 2012 22:52:32 +0100 Date: Thu, 26 Apr 2012 21:59:00 -0000 From: "Maciej W. Rozycki" To: Jan Kratochvil CC: Subject: Re: [PATCH] microMIPS support In-Reply-To: <20120426192611.GA24056@host2.jankratochvil.net> Message-ID: References: <20120426183713.GA21029@host2.jankratochvil.net> <20120426192611.GA24056@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/msg00968.txt.bz2 On Thu, 26 Apr 2012, Jan Kratochvil wrote: > > > static const char *const mips_compression_strings[] = { > > > > Hmm, no objection to your suggestion per se, but is it allowed by C89? > > It is already used in GDB since: > http://sourceware.org/ml/gdb-patches/2012-01/msg00973.html > [obv] Code cleanup: add_setshow_enum_cmd: Make 1440 bytes of data segment read-only But it's your own change and there wasn't any discussion about it there, so I can't take it as an argument, sorry. > I am not aware of any compatibility issue of it. But are you absolutely sure that it was a supported construct with C89 or are you only assuming having no counter-evidence? Do you have a copy of the standard? Unfortunately I don't or otherwise I would have checked myself and C99 doesn't note it in the list of major changes from the previous version of the standard (but then I wouldn't classify it as a major change). At the time I learnt C (some 18 years ago) that certainly wasn't a construct I had seen in any language reference I had available or was made aware of in any other way and I am fairly sure it's quite a recent addition. I first heard of it in the 2000s only (and then well into). An equivalent construct that I am sure to be portable is: typedef const char *ccharp; const ccharp foo; but I'm not sure that's maintainable -- too obfuscated in my view. AFAIK we still require our code to conform to C89 (fortunately not K&R anymore) or we could use lots of good stuff, starting from the long long type (so much needed for MIPS opcode tables in opcodes/ among others; we had a discussion in the context of MIPS segments not so long ago here as well, ending with a piece of convoluted code to avoid both the long long type and compiler warnings, depending on the configuration chosen), through designated initialisers (suddenly you stop losing track of your NULLs through your 50-member struct), etc. Any comments, anyone? Maciej