From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id CD3AF3858005 for ; Thu, 4 Nov 2021 19:34:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CD3AF3858005 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-590-SoyLRuuZPuWTg66TCwSL7Q-1; Thu, 04 Nov 2021 15:34:12 -0400 X-MC-Unique: SoyLRuuZPuWTg66TCwSL7Q-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8454D10B3942; Thu, 4 Nov 2021 19:34:11 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.72]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C0EE15F4ED; Thu, 4 Nov 2021 19:34:10 +0000 (UTC) From: Florian Weimer To: =?utf-8?B?0J3QuNC60LjRgtCwINCf0L7Qv9C+0LI=?= Cc: libc-alpha@sourceware.org Subject: Re: [PATCH] gconv: Do not emit spurious NUL character in ISO-2022-JP-3 (bug 28524) References: <87a6ikf0uv.fsf@oldenburg.str.redhat.com> Date: Thu, 04 Nov 2021 20:34:08 +0100 In-Reply-To: (=?utf-8?B?ItCd0LjQutC40YLQsCDQn9C+0L/QvtCyIidz?= message of "Thu, 4 Nov 2021 20:03:21 +0500") Message-ID: <87y26390lr.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2021 19:34:15 -0000 * =D0=9D=D0=B8=D0=BA=D0=B8=D1=82=D0=B0 =D0=9F=D0=BE=D0=BF=D0=BE=D0=B2: > From d8321b3b4399a6e1999bd0ebd1466f6235dc5630 Mon Sep 17 00:00:00 2001 > From: Nikita Popov > Date: Tue, 2 Nov 2021 13:21:42 +0500 > Subject: [PATCH] gconv: Do not emit spurious NUL character in ISO-2022-JP= -3 > (bug 28524) > > Bugfix 27256 has introduced another issue: > In conversion from ISO-2022-JP-3 encoding, it is possible > to force iconv to emit extra NUL character on internal state reset. > To do this, it is sufficient to feed iconv with escape sequence > which switches active character set. > The simplified check 'data->__statep->__count !=3D ASCII_set' > introduced by the aforementioned bugfix picks that case and > behaves as if '\0' character has been queued thus emitting it. > > To eliminate this issue, these steps are taken: > * Restore original condition > '(data->__statep->__count & ~7) !=3D ASCII_set'. > It is necessary since bits 0-2 may contain > number of buffered input characters. > * Check that queued character is not NUL. > Similar step is taken for main conversion loop. > > Bundled test case follows following logic: > * Try to convert ISO-2022-JP-3 escape sequence > switching active character set > * Reset internal state by providing NULL as input buffer > * Ensure that nothing has been converted. > > Signed-off-by: Nikita Popov Thanks, applied. Florian