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

[Jan Beulich]

On 23.09.2025 09:23, Andrew C Aitchison wrote:
> On Tue, 23 Sep 2025, Jan Beulich wrote:
> 
>> On 13.09.2025 17:12, Andrew C Aitchison wrote:
>>> ---
>>>  binutils/nm.c      | 19 +++++++++----------
>>>  binutils/objdump.c | 19 +++++++++----------
>>>  binutils/readelf.c | 19 +++++++++----------
>>>  binutils/strings.c | 23 +++++++++++------------
>>>  4 files changed, 38 insertions(+), 42 deletions(-)
>>
>> Largely okay; a number of cosmetics, though:
> 
> Yes.
> I am used to projects which object to 8 character tab spacing, and 
> prefer to avoid tabs altogether.
> I have not found any description (for human or computer) of the 
> binutils style,

When I search for "GNU coding style", first thing that turns up is
https://www.gnu.org/prep/standards/standards.html. The server looks a
little busy right now, so I couldn't check that's the one, but I'm
pretty sure it is.

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

In the absence of anything written down, taking adjacent code as a
reference is perhaps the best one can do.

>>> --- a/binutils/nm.c
>>> +++ b/binutils/nm.c
>>> @@ -553,22 +553,21 @@ display_utf8 (const unsigned char * in, char * out, unsigned int * consumed)
>>>        switch (nchars)
>>>  	{
>>>  	case 2:
>>> -	  out += sprintf (out, "\\u%02x%02x",
>>> -		  ((in[0] & 0x1c) >> 2),
>>> -		  ((in[0] & 0x03) << 6) | (in[1] & 0x3f));
>>> +	  out += sprintf (out, "\\u%04x",
>>> +		  ((in[0] & 0x1f) << 6) | (in[1] & 0x3f));
>>>  	  break;
>>>
>>>  	case 3:
>>> -	  out += sprintf (out, "\\u%02x%02x",
>>> -		  ((in[0] & 0x0f) << 4) | ((in[1] & 0x3c) >> 2),
>>> -		  ((in[1] & 0x03) << 6) | ((in[2] & 0x3f)));
>>> +	  out += sprintf (out, "\\u%04x",
>>> +		  ((in[0] & 0x0f) << 12) | ((in[1] & 0x3f) << 6) | ((in[2] & 0x3f)) );
>>
>> Here any below, please avoid the extra blank before the final parenthesis.
> 
> This is the second time I have been asked me to change something which 
> I find makes the code more readable - that space makes it easier for me to 
> see whether the parentheses are balanced.
> (The first was that Alan asked that there be no trailing operators
> - I find they make it easier to know how this line connects with the next 
> one.)
> 
> It is all subjective preference, but the project doesn't seem to
> make its preferences clear for me to follow.

No, it's not purely subjective. The style to use is properly described in
(as said, I think) the doc above. Plus again, even if it weren't,
consistency would also be a criteria.

Jan