From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16473 invoked by alias); 15 Feb 2015 11:53:15 -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 16461 invoked by uid 89); 15 Feb 2015 11:53:14 -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: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 15 Feb 2015 11:53:13 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 11030A80BDF; Sun, 15 Feb 2015 12:53:11 +0100 (CET) Date: Sun, 15 Feb 2015 11:53:00 -0000 From: Corinna Vinschen To: gdb-patches@sourceware.org Subject: Re: [PATCH] Add support for embedding scripts in .debug_gdb_scripts. Message-ID: <20150215115311.GQ7225@calimero.vinschen.de> Reply-To: gdb-patches@sourceware.org Mail-Followup-To: gdb-patches@sourceware.org References: <83egqu1u69.fsf@gnu.org> <8361c5254p.fsf@gnu.org> <83egqsys6z.fsf@gnu.org> <20150119144921.GC4041@adacore.com> <54DE3CE9.1090802@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="D9sZ58tf58331Q5M" Content-Disposition: inline In-Reply-To: <54DE3CE9.1090802@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00357.txt.bz2 --D9sZ58tf58331Q5M Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1542 On Feb 13 18:05, Pedro Alves wrote: > On 01/20/2015 04:35 PM, Doug Evans wrote: >=20 > > 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. >=20 > I think saying NUL instead of "null" is as archaic as saying CR instead of > "carriage return", LF instead of "line feed", NL instead of "new line", > etc. I mean, maybe archaicness is not really the issue. >=20 > IMO, it's just a matter of whether we think using the character's > control code symbol is OK instead of the full name. I think the > decision should be based on that alone. >=20 > E.g., would we write: >=20 > "If this section exists, its contents is a list of entries separated > by CR NL, specifying scripts to load. The list is terminated with > a NUL character." Sure, except for s/NL/LF/g. What I don't grok here either is the usage of the word "archaic" in terms of a well-known, well-established, documented, and, above all, *standardised*(*) set of abreviations of characters with a certain meaning. NUL is the character with the value \0. Why is that suddenly a problem? Aren't developers the target group of the GDB documentation? Isn't ASCII developer 101? Corinna (*) https://tools.ietf.org/html/rfc20 https://mailarchive.ietf.org/arch/msg/ietf-announce/KIbuNLhChScLC2JBTmF= Ojj8fT78 http://www.rfc-editor.org/std/std-index.txt --=20 Corinna Vinschen Cygwin Maintainer Red Hat --D9sZ58tf58331Q5M Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU4IimAAoJEPU2Bp2uRE+geYkP/3NA1zkxQGs3181RoEDNxCqF N29ErzXQ7bhyK74xf6aRdizzEmUcaJkhRbbzyLx11ynQYHHjLftVXnl7ZGVC7ugu gMqleIX01BAIUmSts/ovdfRHElIDzn+4q7TDWGb14LBurhAEtjhI9cX01gKv0ijO tHJhGV8QB4pKu/Tbf8PO7R+CLK+ChMpyUl88T36fH0guUWM2I4oEDUhyHf53LX81 pjEehjVEUNaq44HfAZMc8ICZms3SY/jCrKziuHHFqxkoEn/DrWQh7t8d7ZCDW7Nw NpTKyy5fgqfZtZ6cOHkE77F485wx2exXKJM+T7C8nmOZcQu3qt32nCUWxAbkQvAV sCz+UE71K7hr2jP4gj2c4b+5hfByFD8uKfPzRpjTDvAN+4JEAibnjp0aG0fbQ1KN nCR4A6lDc+2O7igvWrYLfU4qAC5yKAAwxR9RZF0mkbxmLU++JB742CeTO+gxNAZg xN/eyUjrVcWvtI0OHxXISU4ycXWhYTfQ8GuBQW1NnjiJI99K0n7rBRZRhJp4i6zy LvtqgGt0aJLjc6HWmbLFm6tCNxZWmjQzCP/xc4warSS95fUFH2Y3qYXJgBA35ppo uk5toETlLhftcdONmdux2yM5l+x3FEuNT1PrxRXqe6dFiWB/9zl6j3jRAPvzCaex kMm8I9cHbGBut4f6y4Pg =9nm9 -----END PGP SIGNATURE----- --D9sZ58tf58331Q5M--