From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25348 invoked by alias); 16 Aug 2010 08:37:29 -0000 Received: (qmail 25338 invoked by uid 22791); 16 Aug 2010 08:37:27 -0000 X-SWARE-Spam-Status: No, hits=-0.1 required=5.0 tests=AWL,BAYES_40,MSGID_MULTIPLE_AT,TW_XS X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.158) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 Aug 2010 08:36:53 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o7G8ajw7021202 ; Mon, 16 Aug 2010 10:36:46 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms6.u-strasbg.fr [IPv6:2001:660:2402:d::15]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id o7G8ajpU055914 ; Mon, 16 Aug 2010 10:36:45 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from d620muller (gw-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.4/jtpda-5.5pre1) with ESMTP id o7G8aiiK025762 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Mon, 16 Aug 2010 10:36:44 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: "'Vladimir Prus'" , References: <20100814015352.GA10686@sourceware.org> In-Reply-To: Subject: RE: New ARI warning Sat Aug 14 01:53:52 UTC 2010 Date: Mon, 16 Aug 2010 08:37:00 -0000 Message-ID: <005501cb3d1e$2c349d70$849dd850$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: 2010-08/txt/msg00217.txt.bz2 > From Vladimir Prus > >> gdb/mi/mi-main.c:1512: code: sprintf: Do not use sprintf, instead > use xstrprintf > > gdb/mi/mi-main.c:1512: sprintf (p, ', read_result->data[i]); The real source line is=20 sprint (p, "%02x", read_result->data[i]); > This warning is bogus in this context. How do I silence it? Could you explain further why the message is bogus? I think the message should be enhanced to also propose xsnprintf (char *str, size_t size, const char *format, ...) as a valid substitute for 'sprintf' if the char array is already allocated. Of course this always adds some overhead, but it ensures that no overflow is happening. Is it a C specification, that "%02x" as a format string will never use more than two bytes? If this is the case, we can silence the warning by adding a /* ARI: sprintf */ comment on the same line. otherwise use of 'xsnprintf' seems like an improvement to me. =20 > >> gdb/mi/mi-main.c:1490: gettext: _ markup: All messages should be > marked up with _. > > gdb/mi/mi-main.c:1490: error ("Unable to read memory."); > >> gdb/mi/mi-main.c:1582: gettext: _ markup: All messages should be > marked up with _. > > gdb/mi/mi-main.c:1582: error ("mi_cmd_data_write_memory: Usage: [- > o COLUMN_OFFSET] ADDR FORMAT > > WORD-SIZE VALUE."); 821a825 > >> gdb/mi/mi-main.c:1738: gettext: _ markup: All messages should be > marked up with _. > > gdb/mi/mi-main.c:1738: error ("the specified thread group does not > exist"); >=20 > Of above warnings, only first appears to be added by a recent patch of mi= ne, The script I wrote to try to isolate new warnings is far from perfect and I warned that there could be also false warnings appearing. My knowledge of AWK is still too limited to really write something better, = sorry. > while others were there all the time. That said, have we ever decided if = MI > should try to i18n its error messages? At least some of messages, like > "Unable to read memory" above, can probably be shown to user -- except it= 's > so generic as to be useless. Some messages, clearly, indicate frontend > bugs and showing them to users, or l10n-ing, makes no sense. If it is decided that most mi code should not required i18n,=20 it would be simple to skip those tests for mi subdirectory. We just need to agree on a position concerning this matter. I have no strong feelings in either direction, but it seems quite logical that all messages that are only designated for front-end should rather not be translated, as this would require even more work for the front-ends to recognize them. Pierre Muller as ARI maintainer. =20=20