From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8031 invoked by alias); 20 Jan 2015 16:35:12 -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 8019 invoked by uid 89); 20 Jan 2015 16:35:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-we0-f182.google.com Received: from mail-we0-f182.google.com (HELO mail-we0-f182.google.com) (74.125.82.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 20 Jan 2015 16:35:09 +0000 Received: by mail-we0-f182.google.com with SMTP id l61so13525765wev.13 for ; Tue, 20 Jan 2015 08:35:06 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.228.72 with SMTP id sg8mr48575023wic.48.1421771706504; Tue, 20 Jan 2015 08:35:06 -0800 (PST) Received: by 10.27.39.198 with HTTP; Tue, 20 Jan 2015 08:35:06 -0800 (PST) In-Reply-To: <20150119144921.GC4041@adacore.com> References: <83ppaf3oe6.fsf@gnu.org> <83egqu1u69.fsf@gnu.org> <8361c5254p.fsf@gnu.org> <83egqsys6z.fsf@gnu.org> <20150119144921.GC4041@adacore.com> Date: Tue, 20 Jan 2015 16:35:00 -0000 Message-ID: Subject: Re: [PATCH] Add support for embedding scripts in .debug_gdb_scripts. From: Doug Evans To: Joel Brobecker Cc: Eli Zaretskii , "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00541.txt.bz2 On Mon, Jan 19, 2015 at 6:49 AM, Joel Brobecker wrote: >> >> All NEWS entries for new features shall specify the platform(s) on which >> >> the feature is available, if it is not a generally available feature. >> >> [or words to that effect] >> >> And let's enforce all these rules the way we do >> >> coding conventions (which I don't have a problem with). >> >> >> >> Ok? >> > >> > I'm fine with that, if no one objects. But you cannot possibly codify >> > all such minor issues, they are too many. And it isn't needed, from >> > my POV. >> >> If it serves to put in writing absolute rules that someone is likely >> to get tripped up by or not understand then it will have served its >> purpose. > > 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. > 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.