Re: [PATCH v2 00/65] gas: whitespace handling

[Hans-Peter Nilsson <hp@axis.com>]

Sorry for being a downer, but:

> Date: Mon, 27 Jan 2025 16:23:42 +0100
> From: Jan Beulich <jbeulich@suse.com>

> As per observations in target specific code there appears to be disagreement
> across the assembler whether to check for specific characters (blank and tab
> normally) or whether to use ISSPACE().
> 
> As agreed upon during the Cauldron in Prague, switch to a single base
> construct for all code to use: is_whitespace().

Such decisions should be made online, with the whole
community, not with the people attending a specific session
at a specific event.  (While I had the chance, I had no idea
executive decisions were about to take place.)

> It clearly is an alternative option to have is_whitespace() expand to
> ISSPACE() or ISBLANK() (ISSPACE() also yields "true" for characters we don't
> really consider whitespace), then (obviously) leaving out the last patch. See
> also the CR_EOL uses in read.c and app.c. I think it is advisable though that
> is_whitespace() and is_end_of_{line,stmt}() be non-overlapping; question then
> is what (further) characters to tag as LEX_WHITE (see remarks in patch 01).
> 
> Along with recently (as of the v1 submission) committed work for x86 this
> appears to be sufficient to actually use -f (or #NO_APP at start of file)
> for gcc-generated code.

Does that work also clean up gcc-generated code, like
dropping space after comma or multiple spaces or whatever is
judged the #NO_APP behavior of "x86 assembly"?  I don't see
such patches but maybe they're not posted yet.  It doesn't
just happen to be specified as what gcc generates on the
master branch of today?

> I didn't properly check other architectures yet, but
> I seem to recall that at least Arm32 and PPC would apparently require
> compiler side adjustments, too.

I can't help but thinking this is going ever so slightly in
the wrong direction with regards to #NO_APP: this change-set
is making that mode more lenient towards formatting;
allowing more types of space characters.  With the few
targets that have #NO_APP active in gcc-generated code, you
have the chance of making that mode more strict.

brgds, H-P