I've checked the 2020 September refresh.
On Tue, 17 Nov 2020 09:12:17 -0600, Paul Gilmartin wrote:
>
>Does "conversion errors" mean "invalid octet sequences" in the source
>as well as characters valid in the source CCSID but having no equivalent
>in the target charact set. In the former case, how many 0xff are written?
>
>(is "0xff" possibly a typo for "0x3f"?
>
>Truly, if the target character set is ASCII-like the substitute character
>should be 0x1a; if EBCDIC-like, 0x3f; if DBCS, ???, but not a single octet.
>
Is this affected by the update to SC14-7314-40 (see below), and my
addiitonal comments.
> SC14-7314-40 XL C/C++ Runtime Library Reference
>says:
> iconv() — Code conversion
> If a sequence of input bytes does not form a valid character in the
> specified encoded character set, conversion stops after the previous
> successfully converted character, and iconv() sets errno to EILSEQ.
> ...
> If iconv() encounters a character in the input buffer that is valid, but
> for which a conversion is not defined in the conversion descriptor, cd,
> then iconv() performs a nonidentical conversion on this character.
> The conversion is implementation-defined.
>
Now, with revision bar:
If iconv() encounters a character in the input buffer that is valid, but
for which a conversion is not defined in the conversion descriptor, cd,
| then the substitution character is to be put in the target buffer and the
| conversion is to be continued.
I feel that "substitution character" should be further clarified to
"substitution
character (SUB) of the target character set".
("is to be" isn't colloquial English.)
>I feel like a couple RCFs
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
