[PATCH 1/1] Correct -Ue output for nm, objdump and readelf, like PR33360 does for strings.

[Alice Carlotti]

On Mon, Sep 08, 2025 at 04:15:06PM +0200, Jan Beulich wrote:
> On 08.09.2025 15:30, Andrew C Aitchison wrote:
> > On Mon, 8 Sep 2025, Jan Beulich wrote:
> > 
> >> On 05.09.2025 20:02, Andrew C Aitchison wrote:
> >>> Signed-off-by: Andrew C Aitchison <github@aitchison.me.uk>
> >>> ---
> >>>  binutils/nm.c      | 4 ++--
> >>>  binutils/objdump.c | 4 ++--
> >>>  binutils/readelf.c | 4 ++--
> >>>  3 files changed, 6 insertions(+), 6 deletions(-)
> >>
> >> Much like the strings change this is okay to put in, while at the same time
> >> I think we want to move to what you described in another reply, uniformly
> >> using \unnnn and \Unnnnnnnn. I'm further wondering whether going just up to
> >> 4 input chars in the functions is actually sufficient. Aiui in all four
> >> instances at least a sanity check is missing, guarding against us treating
> >> a 5- or more char sequence as a 4-char one, breaking the stream of bytes.

UTF-8 was restricted in 2003 to just the range representable by UTF-16, so all
valid UTF-8 encodings need at most four characters.  However, we don't
currently check that the 0x08 bit is unset (as you noticed); I've added this
check as part of my strings.c patch.

> >>
> >> Aiui this wants committing on your behalf?
> > 
> > Yes please, but I note in the other thread
> > https://sourceware.org/pipermail/binutils/2025-September/144078.html
> > that Alice has spotted other problems and is working on a series of patches.

My series of patches has ended up being a partial rewrite of the UTF-8 handling
in strings.c, and I'll probably send it (initially, at least) as a single
patch.  It's approximately +150 -320 lines at the moment (including bug fixes -
there was a lot of duplicated or inefficient code).  I just want to add some
tests before sending that out.


As for the other utilities - there are differences between what strings.c is
doing with UTF-8 (detecting valid strings) vs. what I think the other three
utilities are doing (displaying symbol names or stuff like that, which might
include non-ASCII characters and might not be valid UTF-8).  I haven't worked
out what would be correct behaviour for symbols that aren't valid UTF-8, and I
think at least one of the printing modes is doing validation but ends up just
printing out the symbols unchanged anyway.

So I'll leave the other files alone for now, and therefore this patch certainly
shouldn't wait for mine.  And in any case, fixing output for valid UTF-8 seems
like a good self-contained fix that is best provided separately from a more
substantial rework of the validation logic.

Alice

> 
> Right, I'm aware. As per what Alan said for the strings patch, I think we
> want to take this right away, and then other stuff can go on top. Such
> later changed may then also be easier to review, when all four places are
> sufficiently similar.
> 
> Jan