Email List: Xaustin-group-lX
[All Lists]

Re: ACTION 2002-5-05: proposed iconv changes (XCUft ERN 11)

To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
Subject: Re: ACTION 2002-5-05: proposed iconv changes (XCUft ERN 11)
From: Bruno Haible <yyyyyy@xxxxxxx>
Date: Mon, 27 May 2002 16:51:43 +0200 (CEST)
References: <1020527140438.ZM3284@skye.rdg.opengroup.org>
Andrew Josey writes:

> On line 19283 change from:
> 
>  "Omit any invalid characters from the output."
> 
> to
> 
>  "Omit any characters that are invalid in the codeset of the input 
>   file from the output."
> ...

>  Add the following at the end of line 19287:
> 
>  If the iconv utility encounters a character in the fromcode input
>  that is valid, but for which an identical character does not exist in the
>  tocode codeset, the iconv utility shall perform an
>  implementation-defined conversion on this character.

I've filed an Aarkvard against this change. Here is the full text.

=======================================================================

@ page 1 line 183 section XCU/TC1/D1/10 objection {XCU/TC1/D1/10/OBJ}

Problem:

The description of the iconv -c option mentions two kinds of
conversion problems:
  - byte sequences that are not valid members of the fromcode,
  - characters that have no corresponding value in tocode.

It would be inconsistent for the iconv utility if option -c
would cause the program to continue after conversion problems
of the first kind but not after conversion problems of the
second kind, and if no other iconv option would allow to
handle conversion problems of the second kind.

The rationale says "Inconsistency with the iconv() function."
It is true that the iconv() function makes a distinction between
the conversion problems of the first kind (which lead to EILSEQ)
and conversion problems of the second kind (which lead to an
implementation defined conversion). The problem is in the iconv()
function; it is this function's specification which should be
changed.

Also, please note that there is no requirement that the iconv
utility program must be implementable with the standard iconv()
function; it could also use an internal function which, in
addition to iconv(), offers independent control of the handling
of the conversion problems of the first and second kind.


Action:

Do not apply change number XCU/TC1/D1/10.

<Prev in Thread] Current Thread [Next in Thread>