From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22981 invoked by alias); 3 Dec 2010 00:10:28 -0000 Received: (qmail 22965 invoked by uid 22791); 3 Dec 2010 00:10:26 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 03 Dec 2010 00:10:22 +0000 Received: (qmail 15834 invoked from network); 3 Dec 2010 00:10:19 -0000 Received: from unknown (HELO tp.orcam.me.uk) (macro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 Dec 2010 00:10:19 -0000 Date: Fri, 03 Dec 2010 00:10:00 -0000 From: "Maciej W. Rozycki" To: Paul Koning cc: binutils@sourceware.org Subject: Re: [PATCH 08/20] MIPS/GAS: Improve a LUI complaint message In-Reply-To: <9840ECA4-9B53-4A2E-8474-2D676F976610@dell.com> Message-ID: References: <9840ECA4-9B53-4A2E-8474-2D676F976610@dell.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2010-12/txt/msg00141.txt.bz2 On Thu, 2 Dec 2010, Paul Koning wrote: > > @@ -10005,7 +10005,8 @@ mips_ip (char *str, struct mips_cl_insn > > && imm_expr.X_op == O_constant > > && (imm_expr.X_add_number < 0 > > || imm_expr.X_add_number >= 0x10000)) > > - as_bad (_("LUI expression not in range 0..65535")); > > + as_bad (_("LUI expression (%lu) not in 0..65535 range"), > > + (unsigned long) imm_expr.X_add_number); > > s = expr_end; > > continue; > > > I'm not a native speaker of English, but the original word order (...in > range x..y) seems better to me. I have changed the order so that "0..65535" precedes the noun it describes as an adjective (substitute e.g. "(the) correct" for comparison); alternatively "in (the) range of 0..65535" where "0..65535" is used as a noun would seem correct to me as well. Anyway the mention of the problematic value is what matters here and I won't insist on the rest of the change. While at it I'd like to rise my concern about the lack of a way to output numbers of the offsetT or addressT type on hosts where these boil down to the long long type -- I realise in the old days it used to be problematic, but nowadays we have with its PRI* macros, so perhaps we should factor them in one way or another. Otherwise we risk confusing the user here or there when values with some high-order bits get truncated and error messages like this report values that might appear valid once that happened. Maciej