[Bug libc/29913] iconv(3) is not POSIX compliant, and does not conform to linux man-pages manual

["steffen at sdaoden dot eu" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29913

--- Comment #3 from Steffen (Daode) Nurpmeso <steffen at sdaoden dot eu> ---
It shall simply put a ? (musl uses *), or maybe a configurable character.
Some libraries then put a ? for each byte, other one for the complete sequence
that is skipped over.  ("Normally" the converter "knows" about the character so
much that the latter strives me a good thing.  Like //TRANSLIT does.)

Yes.  I guess the problem is that in "real life" the problem likely does not
occur in that form.
Or the people work around it somehow.
For example, in "my" Linux distribution, they changed their pkg like

-               bsdtar -c $COMPRESSION -f $TARGET *  &&  bsdtar -t -v -f
$TARGET
+               bsdtar --format=gnutar -c $COMPRESSION -f $TARGET *  &&  bsdtar
-t -v -f $TARGET

because some release balls seem to contain falsely encoded paths.
(So that the -- correct! and _very_ complicated!! -- libarchive character
conversion correctly bails.  But the above is easier to handle than doing
upstream reports, and gives immediate success.  (The bogus path on the disc ..
i do not know.  I did not use those packages once the problem was
circumvented.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.