From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 4D49B385843F for ; Mon, 27 Jan 2025 17:05:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4D49B385843F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4D49B385843F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737997529; cv=none; b=NWkHuVNfftEbnpPkcpVAteKIKXBfkTrgWktc/G3b5v2FWXuDrgTzbt+lsQkm1HaVpA6gdCBPNO1eaNmFDftLq9iL/POkWGhEYDSLm7HnCi0i41qTUVPTMducziuZShw+Qcqt8oc1ImcjxU5D09BTJ/b8eIJ18rYosr+l9VDDK70= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1737997529; c=relaxed/simple; bh=l8q8/wStDGNJKBvWdp41kyKgWbP0to/hXbE8xQT0Dlc=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=WeGBwMbXPzkoA0HBW9c9VUUdbvquRMYNEut8RP/levUWCtdR07DkVDfKSD7q7a3o012oIk8R2qBTLBR9F4aBf+nowKTtYzG/Aj+hedKptZp+ZLO5bmtxMy303k0tlGQ1EnYlFumt2SaZ5kxYXx0I8VmFxLMCr1bRKhS3VLjqL5s= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DE76C497; Mon, 27 Jan 2025 09:05:55 -0800 (PST) Received: from [10.2.78.71] (e120077-lin.cambridge.arm.com [10.2.78.71]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0967E3F528; Mon, 27 Jan 2025 09:05:27 -0800 (PST) Message-ID: <5eb0abfa-9b54-4dba-bc5d-22c4ac1a9593@arm.com> Date: Mon, 27 Jan 2025 17:05:26 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 05/65] Arm: use is_whitespace() To: Jan Beulich Cc: Nick Clifton , "ramana.radhakrishnan@arm.com" , Richard Earnshaw , Binutils References: <2316ac5c-7870-4b46-9c80-eaecaef93a31@suse.com> <83414a2b-bfad-4381-8903-152ec0552e88@suse.com> <21fadba4-7b81-4d82-a42e-d9ce1b02437f@arm.com> <13b69da6-e2e2-46cd-8601-1dc0d28d94c3@suse.com> From: "Richard Earnshaw (lists)" Content-Language: en-GB In-Reply-To: <13b69da6-e2e2-46cd-8601-1dc0d28d94c3@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3489.7 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 27/01/2025 16:55, Jan Beulich wrote: > On 27.01.2025 17:31, Richard Earnshaw (lists) wrote: >> On 27/01/2025 15:50, Jan Beulich wrote: >>> --- a/gas/config/tc-arm.c >>> +++ b/gas/config/tc-arm.c >>> @@ -1081,7 +1081,7 @@ const char FLT_CHARS[] = "rRsSfFdDxXeEpP >>> >>> /* Separator character handling. */ >>> >>> -#define skip_whitespace(str) do { if (*(str) == ' ') ++(str); } while (0) >>> +#define skip_whitespace(str) do { if (is_whitespace (*(str))) ++(str); } while (0) >>> >>> enum fp_16bit_format >>> { >>> @@ -1510,13 +1510,9 @@ parse_neon_type (struct neon_type *type, >>> return FAIL; >>> } >>> goto done; >>> - case '0': case '1': case '2': case '3': case '4': >>> - case '5': case '6': case '7': case '8': case '9': >>> - case ' ': case '.': >>> + default: >>> as_bad (_("unexpected type character `b' -- did you mean `bf'?")); >>> return FAIL; >>> - default: >>> - break; >>> } >> >> This entire switch statement has now degenerated into 'f' or error. So I think it would be better to just replace it with an if-else. > > I can do that, but in other projects I'm active we'd deliberately ask > that switch() be used simply in the expectation that if any further > character would want checking for, code churn would then be lower. If > you're fine with the extra churn, I can of course adjust here. > > Jan Never say never, but I can't see other characters being needed here. I'll take that hit if it's needed at some point in the future. Note, we already don't handle this when parsing the numbers after an 'f', so we're not consistent anyway. I don't particularly like the error recovery here anyway, but that's another story. Printing "unexpected type character `b' -- did you mean `bf'?" is not exactly informative when there's so little context shown: it's not even as though 'bf' is the complete answer, the type is 'bf16'; but to do this even close to properly we'd need to tokenize the input and print the entire substring up to the next token separator. R.