From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 136453858C83; Sat, 18 Feb 2023 22:43:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 136453858C83 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676760212; bh=bT4ST076up2dXV69PfVATkzqgK/fiKRuuIbsi8dizb0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JX1gxkOpYJJXRsjuVZs+IIatIRhRcbcDcMyUDOOOM0yDruy3KseINWr9lIhE8U5uS 5+X1X1PPBxA+Bg+IOMTza1r2e9Yr983+1mOICvdkelQHQe37Hlwhp8KbLZIs7dwVt9 HkaiZwhC+2uzxu4mWSCX5cnjjv9W3+9k+jn+SwrM= From: "steffen at sdaoden dot eu" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.36 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: steffen at sdaoden dot eu X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29913 --- Comment #3 from Steffen (Daode) Nurpmeso --- 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 seque= nce that is skipped over. ("Normally" the converter "knows" about the characte= r 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=3Dgnutar -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.) --=20 You are receiving this mail because: You are on the CC list for the bug.=