[hp@axis.com: Re: [PATCH v2 11/65] cris: use is_whitespace()]

[Hans-Peter Nilsson]

Sorry: I accidentally left out the mailing list when
replying to Jan regarding the CRIS part, so here it is,
forwarded.  (Actually a re-reply, and I was confused why TAB
could suddenly be introduced in supposedly scrubbed code,
where Jan clarified the context both in the cover letter and
later discussion.)  Note the incompatibility comment though,
that applies both ways: a gcc with #NO_APP and emitting TAB
would require a later assembler, so it's configure.in check
time.

------- Start of forwarded message -------
From: Hans-Peter Nilsson <hp@axis.com>
To: Jan Beulich <jbeulich@suse.com>
In-Reply-To: <9b6e367e-9052-4df7-b428-d2ffeb0a8830@suse.com> (message from Jan
	Beulich on Mon, 27 Jan 2025 17:52:27 +0100)
Subject: Re: [PATCH v2 11/65] cris: use is_whitespace()
Content-Type: text/plain; charset="iso-8859-1"
Date: Mon, 27 Jan 2025 18:18:58 +0100

> Date: Mon, 27 Jan 2025 17:52:27 +0100
> From: Jan Beulich <jbeulich@suse.com>

> On 27.01.2025 17:22, Hans-Peter Nilsson wrote:
> >> Date: Mon, 27 Jan 2025 17:10:32 +0100
> >> From: Jan Beulich <jbeulich@suse.com>
> > 
> >> Wherever blanks are permissible in input, tabs ought to be permissible,
> >> too. This is particularly relevant when -f is passed to gas (alongside
> >> appropriate input). Also switch ISSPACE() uses over.
> > 
> > Hm... This code is supposed to handle formatted input
> > (#NO_APP in effect; format being simplified,
> > "canonicalized") so aren't the TABs supposed to be gone
> > here, whitespaces changed into a single space character?
> 
> With #NO_APP (or the -f command line option) in effect it's quite the
> other way around: TABs would not be replaced.

Sorry, I regularly miss a negation trying to express #NO_APP
effects...  What I mean is that when you reach that code,
you should *not* be making the kind of changes you propose;
that should have been done by the #APP/#NO_APP framework.

> I.e. checking for just
> blanks would make things dependent on the compiler to not emit TABs.
> I don't know about cris, but for most other targets gcc does emit
> tabs.

Correct, because TAB is not a canonical format character for
#NO_APP CRIS assembly code (if for no other reason than
happenstance; has not been accepted).

To wit, with that kind of change, a subtle incompatibility
is introduced, such that suddenly there's a binutils version
that makes a difference, and if a TAB is introduced in code
emitted by gcc, then you'd require a later binutils for that
and no other reason.  So please don't; let that kind of
change happen only for code in #APP mode (whitespace -> one
space).

brgds, H-P
------- End of forwarded message -------