From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28233 invoked by alias); 9 Feb 2012 19:23:33 -0000 Received: (qmail 28221 invoked by uid 22791); 9 Feb 2012 19:23:32 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from elasmtp-mealy.atl.sa.earthlink.net (HELO elasmtp-mealy.atl.sa.earthlink.net) (209.86.89.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 09 Feb 2012 19:23:18 +0000 Received: from [70.170.59.51] (helo=macbook2.local) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RvZaP-0004GK-AS for gdb-patches@sourceware.org; Thu, 09 Feb 2012 14:23:17 -0500 Message-ID: <4F341D1E.3090206@earthlink.net> Date: Thu, 09 Feb 2012 19:23:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [no-commit-intention] Naive unnamed fields for main_type [Re: [patch] Fix gdb-gdb.py for flds_bnds copy-pastes] References: <20120209092727.GA2664@host2.jankratochvil.net> <20120209093119.GA2722@host2.jankratochvil.net> <20120209151621.GB3474@adacore.com> In-Reply-To: <20120209151621.GB3474@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da940d6075384b9c0c8c8bc509d26eaa5b0c3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes 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-02/txt/msg00157.txt.bz2 On 2/9/12 7:16 AM, Joel Brobecker wrote: >> I naively tried first to just use unnamed field which makes everything great: > Hmmm, true! This flds_bnds union has been bugging me (when debugging) > pretty much ever since it was introduced. > > Personally, I don't know what the obstacles are for switching to C99 > (technical, FSF policy?). For this particular issue, I feel that it > would not exist if struct main_type was a C++ class. So that could be > another way out of that annoying union. (thinking aloud) > The expected language dialect can be whatever we decide it to be. There are basically three categories of gotchas: 1) Non-GCC compilers. Although there's not the bootstrapping problem that GCC itself has, we do want people to use GDB even if it might be the only piece of GNU software on their systems. We should at least build with the standard native compiler on our supported systems, but should feel free to use whatever flags. Did any of the proprietary workstation compilers totally miss the C99 boat? 2) Older versions of GCC. For C99 this seems unlikely to be an issue anymore, who has a still-usable GCC that is over 10 years old? 3) Libraries/headers. This is probably the most common way that people get hosed - their GCC is modern, but library and headers are several generations older, and possibly lacking C99-required bits. Stan