From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24672 invoked by alias); 21 Jan 2015 09:57:45 -0000 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 Received: (qmail 24632 invoked by uid 89); 21 Jan 2015 09:57:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 21 Jan 2015 09:57:42 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 0C10C1164D3; Wed, 21 Jan 2015 04:57:41 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LP0zLup3hQSp; Wed, 21 Jan 2015 04:57:40 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id D17811164C4; Wed, 21 Jan 2015 04:57:40 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 8FA4D48E89; Wed, 21 Jan 2015 10:57:39 +0100 (CET) Date: Wed, 21 Jan 2015 09:57:00 -0000 From: Joel Brobecker To: Doug Evans Cc: Eli Zaretskii , "gdb-patches@sourceware.org" Subject: Re: [PATCH] Add support for embedding scripts in .debug_gdb_scripts. Message-ID: <20150121095739.GB24515@adacore.com> References: <83ppaf3oe6.fsf@gnu.org> <83egqu1u69.fsf@gnu.org> <8361c5254p.fsf@gnu.org> <83egqsys6z.fsf@gnu.org> <20150119144921.GC4041@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-01/txt/msg00568.txt.bz2 > > I just personally think this is too extreme a measure. There are times > > when absolute rules may be useful, but I don't think this is the case > > here. > > Eh? What we have here *is* an absolute rule: > We used to be allowed to use phrases like NUL-terminated > in documentation, now we are not. True, but I just think it's not worth starting to write _rules_ down. If we start writing such rules down, then that means that we must write down all other rules. Which seems OK in principle, but when you get to that level of details, the list can become so long as to be really hard to keep in mind. What I'm getting at is that this is really a detail, and if we want to make a rule of it, I'd create one more general that says "no outdated expression" may be used. > > Eli is our documentation maintainer,so let's continue trusting > > his judgement. This discussion is not about black and white, and > > as such, it's easy to disagree. But I don't think it's important > > enough to spend more time on this. I know it can be fustrating > > to make a change one does not believe in, but after a reasonable > > attempt at discussing it, I'd go with his call. > > I for one would liked to have seen the data to back up > the claim that NUL-terminated is archaic. > It's not that I don't trust someone's judgement, rather it's that that's > the wrong way to impose the change. FWIW, and this is only my personal opinion of course, since you are in fact entitled to getting an explanation: Eli telling me, as our Documentation Maintainer, "it reads better if you use [blah]", is usually enough for me to follow his lead and make the change. I'd have to disagree fairly strongly to argue further. Since (I think) Eli tried to explain, is that the case, here? That you disagree fairly strongly with Eli's assessment? -- Joel