public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "steffen at sdaoden dot eu" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug libc/29913] iconv(3) is not POSIX compliant, and does not conform to linux man-pages manual Date: Sat, 18 Feb 2023 22:43:31 +0000 [thread overview] Message-ID: <bug-29913-131-MqN0ebgpAM@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-29913-131@http.sourceware.org/bugzilla/> 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.
next prev parent reply other threads:[~2023-02-18 22:43 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-12-16 23:03 [Bug libc/29913] New: " steffen at sdaoden dot eu 2023-02-18 20:48 ` [Bug libc/29913] " rrt at sc3d dot org 2023-02-18 21:20 ` rrt at sc3d dot org 2023-02-18 22:43 ` steffen at sdaoden dot eu [this message] 2023-02-19 0:40 ` bruno at clisp dot org 2023-02-19 0:51 ` bruno at clisp dot org 2023-02-19 1:58 ` steffen at sdaoden dot eu 2023-02-19 10:06 ` rrt at sc3d dot org 2023-02-19 10:15 ` rrt at sc3d dot org 2023-02-19 10:22 ` rrt at sc3d dot org 2023-02-19 22:57 ` steffen at sdaoden dot eu 2023-02-19 23:02 ` steffen at sdaoden dot eu 2023-02-20 20:09 ` steffen at sdaoden dot eu 2023-02-20 20:54 ` steffen at sdaoden dot eu 2023-02-20 21:52 ` steffen at sdaoden dot eu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-29913-131-MqN0ebgpAM@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).