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

[Michael Matz]

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.

> 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 :)

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.  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 :)

(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 :) )

> Editor. Or me failing to undo the damage of my editor. As I tried to say 
> in my other reply, what is the point of git-format-patch if I have to 
> hand-edit the patches.

If git-format-patch destroys coding style then it indeed does more harm 
than good.


Ciao,
Michael.