[PATCH 1/3] Make UTF-8 output simpler and easier to read.

[Andrew C Aitchison]

On Tue, 23 Sep 2025, Michael Matz wrote:

> Hello,
>
> On Tue, 23 Sep 2025, Andrew C Aitchison wrote:
>
>> I have not found any description (for human or computer) of the binutils
>> style, and I see no response from binutils to the suggestion
>> from gdb to having an optional clang-format config:
>>   https://sourceware.org/pipermail/binutils/2025-September/143986.html
>> In the absence of a house style I don't know what to change my editor
>> to do and seem to have failed to stop it from upsetting your preferences.
>
> binutils follow (like most C-based GNU projects) the GNU Coding Standards
> https://www.gnu.org/prep/standards/standards.html (or, in case you have
> autoconf installed on some linux distros, also `info standards`), amended
> by some local rules that aren't spelled out there (like the unexpanded
> tabs).  It's basically emacs' 'gnu' builtin cc-mode style.

Hmm. Given that binutils is not gcc and is on sourceware,
it was not obvious to me that it was a GNU project.
I *have* now found where it says to use the gnu style.

>> It is all subjective preference, but the project doesn't seem to
>> make its preferences clear for me to follow.
>
> It has such style (and it's more than a preference), but it's indeed true
> that they are meanwhile only learnable (if that's a word) by submitting
> patches and becoming corrected, or using emacs gnu default or indent :)

Hmm. I don't see .indent.pro anywhere.
# for i in nm.c readelf.c strings.c objdump.c ; do echo -n "$i " ;
      indent -gnu $i -o $i.gnu ; diff -w $i $i.gnu | wc -l ; done
nm.c 220
readelf.c 6084
strings.c 78
objdump.c 573

That is, ignoring whitespace but including line-breaks, hundreds
or thousands of differences between what indent thinks is gnu style
and what we currently have in each file (these are the files I'm
currently trying to patch).

I am reluctant to learn a house style (even if commonly used throughout 
the industry) if it is so comprehensively honoured in the breach.

> I guess a clang-format setting file (or something new-fangled like
> editorconfig) that helps would be somewhat appreciated.  But last time I
> checked myself they all had minor issues with corner cases (vis GCC source
> base in that case) in that some rules couldn't be expressed fully.

If the corner cases are that important I would think it worth the effort
to get them fixed in one of these tools so that the style can be auto-applied
in the submission/check-in process.

>  FWIW, my vim config contains
>  set shiftwidth=4
>  set tabstop=8
>  set autoindent
>  set cinoptions={.5s,g0,p5,t0,(0,^-0.5s,n-0.5s
> just in case you're using that :)

I'm using emacs, but thanks. Some of those numbers will be helpful.

> (But of course, things like linebreak before operator, or space after
> comma, but not before closing parens, or two spaces after
> end-of-sentence-dot, and suchlike have to be taken care of manually.
> Muscle memory eventually sets in :) )

Only if all the projects you work on have the same policies.

-- 
Andrew C. Aitchison                      Kendal, UK
                    andrew@aitchison.me.uk