Quoting the bug Description:
In the problem report corresponding to bug 17197 submitted
against the RHEL GLIBC, even though the focus of the customer's
complaint is on GLIBC emitting redundant shift sequences,
the provided test case implies the customer is actually having
a problem interpreting already encoded data (i.e., with iconv()
treating the duplicate/redundant escape sequences as errors).
If iconv() accepted the duplicate sequences the customer wouldn't
be affected.
The solution implemented in response to bug 17197, changing
the converter to avoid emitting the redundant escape sequences,
while a worthwhile improvement, is not sufficient to resolve
the complaint because there may already be IBM930-encoded data
containing redundant shift sequences that need to be converted.
The current fix will not help users avoid the errors when
converting such data.
Looking for guidance, I checked POSIX to see if it provides
support for the current behavior (rejecting redundant escape
sequences) in POSIX. I don't see anything in POSIX to sanction
rejecting such input. Even if POSIX did allow for such behavior,
since other GLIBC converters accept redundant escape sequences,
it seems that the IBM930 converter should accept them as well
for consistency. Doing otherwise makes the iconv interfaces
needlessly error-prone to use.
The attached patch removes the checking for redundant escape
sequences from the converters for the five encoders to allow
them to successfully convert data containing such sequences.
Tested on powerpc64le-redhat-linux-gnu.
Martin