From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15351 invoked by alias); 15 Mar 2012 20:06:25 -0000 Received: (qmail 15339 invoked by uid 22791); 15 Mar 2012 20:06:23 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,MISSING_HEADERS,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Mar 2012 20:06:08 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2FK63Rg008153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Mar 2012 16:06:03 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q2FK61NB027978; Thu, 15 Mar 2012 16:06:02 -0400 Message-ID: <4F624BA9.70703@redhat.com> Date: Thu, 15 Mar 2012 20:06:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 CC: Doug Evans , Jan Kratochvil , Eli Zaretskii , gdb-patches@sourceware.org, mark@klomp.org Subject: Re: [RFA take 6] Allow setting breakpoints on inline functions (PR 10738) References: <20120314175451.GA20072@host2.jankratochvil.net> <20120315105117.GA3076@redhat.com> <833999wxkt.fsf@gnu.org> <20120315181002.GA10803@redhat.com> <831uotwx2d.fsf@gnu.org> <4F623553.5050204@redhat.com> <83zkbhvhhz.fsf@gnu.org> <20120315184026.GA28322@host2.jankratochvil.net> <20120315192931.GA11584@redhat.com> <4F624848.4090503@redhat.com> In-Reply-To: <4F624848.4090503@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-03/txt/msg00578.txt.bz2 On 03/15/2012 07:51 PM, Pedro Alves wrote: > Why don't we just go with "deprecated"? We completely skip the > "obsolete" ones, and skip the "deprecated" ones, unless the user > wants them badly. The explanation why they're deprecated belongs > elsewhere - it doesn't have to be part of the option name... > > So picking up one of Gary's previous examples, warnings would > simply be: > > versions < 4: "Skipping obsolete .gdb-index section in %s" > versions 4,5: "Skipping deprecated .gdb_index section in %s, > pass --use-deprecated-index-sections to use them anyway" > More so (cause I know people aren't yet fed up with the bikeshedding :-) ), if in the future we ever we want to be selective on _which_ deprecated versions we want to load, we can extend the option to accept a list of integers, like: --use-deprecated-index-sections=7,8 >From : "In the process of authoring computer software, its standards or documentation, or other technical standards, deprecation is a status applied to features, characteristics, or practices to indicate that they should be avoided, typically because they have been superseded. Although deprecated software features remain in the software, their use may raise warning messages recommending alternative practices, and deprecation may indicate that the feature will be removed in the future. Features are deprecated - rather than immediately removed - in order to provide backward compatibility, and give programmers who have used the feature time to bring their code into compliance with the new standard." Sounds Just Perfect to me. Can this make everyone happy, please? :-) -- Pedro Alves