On Thu, Oct 31, 2019 at 04:26:16PM +0700, Doan Tran Cong Danh wrote:
> man 1p printf:
> In addition to the escape sequences shown in the Base Definitions
> volume of POSIX.1‐2008, Chapter 5, File Format Notation ('\\',
> '\a', '\b', '\f', '\n', '\r', '\t', '\v'), "\ddd", where ddd is a
> one, two, or three-digit octal number, shall be written as a byte
> with the numeric value specified by the octal number.
>
> printf '\xfe\xff' in an extension of some libc.
I don't think it's libc here at all, but rather the shell.
And as you note, dash does not handle this:
> With dash:
> $ printf '\xfe\xff' | xxd
> 00000000: 5c78 6665 5c78 6666 \xfe\xff
Which makes me wonder how these tests worked at all for people on say,
Debian systems.
I think the answer is that they don't trigger this prereq:
> write_utf16 () {
> if test_have_prereq NO_UTF16_BOM
> then
> - printf '\xfe\xff'
> + printf '\376\377'
> fi &&
> iconv -f UTF-8 -t UTF-16
> }
which comes from:
test_lazy_prereq NO_UTF16_BOM '
test $(printf abc | iconv -f UTF-8 -t UTF-16 | wc -c) = 6
'
Presumably on your system iconv is using musl's internal iconv, which
behaves differently than the glibc one.
So I think your patch is the right thing to do (hex escapes in shell
printf are definitely not portable), but we might want to note something
like:
This wasn't caught by most people running the tests, even though
common shells like dash don't handle hex escapes, because their
systems don't trigger the NO_UTF16_BOM prereq. But systems with musl
libc do; when combined with dash, the test fails.
-Peff
