A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1635 ====================================================================== Reported By: steffen Assigned To: ====================================================================== Project: 1003.1(2016/18)/Issue7+TC2 Issue ID: 1635 Category: Base Definitions and Headers Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: steffen Organization: User Reference: Section: iconv Page Number: 1123 Line Number: 38014 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2023-02-21 00:14 UTC Last Modified: 2023-02-21 18:20 UTC ====================================================================== Summary: iconv: please be more explicit in input-not-convertible case ======================================================================
---------------------------------------------------------------------- (0006164) steffen (reporter) - 2023-02-21 18:20 https://austingroupbugs.net/view.php?id=1635#c6164 ---------------------------------------------------------------------- P.S.: to eloberate some more, any implementation which wants to conform to the upcoming POSIX standard needs to pass the configured state (//IGNORE, //TRANSLIT ..) along its internal code path, so that this addition would be an "easy" one. Adding this very helpful addition to make the behaviour of the most widely used (and standards-incompatible) implementation explicitly addressable allows future programmers to know what they are doing. (By other means than performing compile-time tests and fixate behaviour according to the compile-time-tested environment.) I truly believe in the honourable Bruno Haible's approach, if it is addressable like that. The only other implementation that allows programmers to realize their own output conversion failure stuff is that of AIX (looking at gnulib), because that uses the NUL byte as an implementation-defined conversion, but that, of course, will fail for data which contains embedded NULs (which for one is otherwise graspable by iconv(3), and second will fail for all multi-byte as in 16-bit or 32-bit encodings per se). In general real life situation it very bad, just look at the efforts of character set conversion in the widely used and widely available libarchive. This addition could make things a bit better. Issue History Date Modified Username Field Change ====================================================================== 2023-02-21 00:14 steffen New Issue 2023-02-21 00:14 steffen Name => steffen 2023-02-21 00:14 steffen Section => iconv 2023-02-21 00:14 steffen Page Number => 1123 2023-02-21 00:14 steffen Line Number => 38014 2023-02-21 18:20 steffen Note Added: 0006164 ======================================================================
