[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2022-06-21 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 Alan Modra changed: What|Removed |Added Version|2.35.2 |2.35 -- You are receiving this mail bec

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-16 Thread vincent-srcware at vinc17 dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 --- Comment #17 from Vincent Lefèvre --- (In reply to Nick Clifton from comment #16) > OK, do you have a patch to propose which fixes this problem ? I think that this could require a lot of changes, because according to the "-e encoding" desc

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-15 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 --- Comment #16 from Nick Clifton --- (In reply to Vincent Lefèvre from comment #15) OK, do you have a patch to propose which fixes this problem ? -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-14 Thread vincent-srcware at vinc17 dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 --- Comment #15 from Vincent Lefèvre --- (In reply to Nick Clifton from comment #14) > But that is the point. The encoding of characters in the file being scanned > is not known. Using LC_CTYPE is incorrect, because that specifies how to > d

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-14 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 --- Comment #14 from Nick Clifton --- (In reply to Vincent Lefèvre from comment #13) >> No - this is the correct behaviour. The 's' encoding says that the >> characters in the file being examined are 7-bits long, not 8-bits. > Then the 's

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-09 Thread vincent-srcware at vinc17 dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 --- Comment #13 from Vincent Lefèvre --- (In reply to Nick Clifton from comment #12) > (In reply to Vincent Lefèvre from comment #10) > Hi Vincent, > > > The bug is that: > > > > if (encoding == 's') > > buf[0] = c & 0x7f; > > > > So

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-09 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 --- Comment #12 from Nick Clifton --- (In reply to Vincent Lefèvre from comment #10) Hi Vincent, > The bug is that: > > if (encoding == 's') > buf[0] = c & 0x7f; > > So the byte 0xc0 gets changed to 0x40, which is printable. No - thi

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-08 Thread vincent-srcware at vinc17 dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 --- Comment #11 from Vincent Lefèvre --- But even when removing this test, keeping the "else", c is always 1-byte long, so that non-ASCII characters are always regarded as non-printable. -- You are receiving this mail because: You are on the

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-08 Thread vincent-srcware at vinc17 dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 --- Comment #10 from Vincent Lefèvre --- The bug is that: if (encoding == 's') buf[0] = c & 0x7f; So the byte 0xc0 gets changed to 0x40, which is printable. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-08 Thread vincent-srcware at vinc17 dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 --- Comment #9 from Vincent Lefèvre --- (In reply to Nick Clifton from comment #8) > Found the cause of the testsuite failure, so here is a revised (version 3) > patch. Like with "-e S", I get binary data: zira% echo $LC_CTYPE C.UTF-8 zira%

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-08 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 --- Comment #8 from Nick Clifton --- Created attachment 13358 --> https://sourceware.org/bugzilla/attachment.cgi?id=13358&action=edit Proposed patch Found the cause of the testsuite failure, so here is a revised (version 3) patch. -- You

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-08 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 Nick Clifton changed: What|Removed |Added Attachment #13356|0 |1 is obsolete|

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-08 Thread sch...@linux-m68k.org
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 --- Comment #6 from Andreas Schwab --- The isw* functions work on wide characters, not multi-byte characters. You first have to convert the string of multi-byte characters to wide characters. -- You are receiving this mail because: You are

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-08 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 --- Comment #5 from Nick Clifton --- (In reply to Vincent Lefèvre from comment #2) > "-e S" does not work with UTF-8, where I get a lot of binary data. Strange - it worked for me. > I think that the correct solution is to use isprint(), whi

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-07 Thread vincent-srcware at vinc17 dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 --- Comment #4 from Vincent Lefèvre --- BTW, "-e S" is also buggy for ISO-8859-1 (and others) too since it outputs the control characters from 0x80 to 0x9f. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-07 Thread vincent-srcware at vinc17 dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 --- Comment #3 from Vincent Lefèvre --- Sorry, to support multibyte characters, you need iswprint(). -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-07 Thread vincent-srcware at vinc17 dot net
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 --- Comment #2 from Vincent Lefèvre --- Hi Nick, (In reply to Nick Clifton from comment #1) > You can achieve the desired decoding by setting the character width > on the command line, like this: > > % echo abcdéfghi | ./binutils/str

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-07 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nickc at redhat dot com Last

[Bug binutils/27551] The default encoding of the strings utility does not conform to POSIX: should honor the current locale.

2021-04-07 Thread nickc at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27551 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1