Question regarding gettext behavior on iconv failure

[Eric Blake]

Hello GNU gettext maintainers,

In today's Austin Group meeting, we developed an example of using the
proposed POSIX standardization of gettext() and encountered a situation
where we felt that GNU gettext may have a bug.  For context, the entire
example is at:
https://posix.rhansen.org/p/gettext_split

The example in question set up several .po files and a specific
environment to test various pluralization/transcoding fallbacks, and
concludes with a snippet where a string with an encoding error in
ISO-8859-1 is output in spite of an iconv failure, rather than the
string passed in to ngettext():


    n_recipients = 1;
    // The following outputs "1 Empfänger" encoded in UTF-8:
    printf("%s\n", ngettext("recipient", "recipients", n_recipients));

    bind_textdomain_codeset("mail", "ASCII");

    n_recipients = 1;
    // The following outputs "recipient" with the same encoding as the
"recipient"
    // argument to ngettext (remember, the the system is assumed to not
support
    // conversion from ISO/IEC 8859-1 to ASCII):
    printf("%s\n", ngettext("recipient", "recipients", n_recipients));
    // On GNU gettext, "1 Empfänger" is output in ISO-8859-1 here (i.e.
no conversion is done). I think we already agreed on considering this
behavior a bug,

This raises a few questions: does the GNU gettext team agree that this
can be considered a bug, and if so, will a future gettext release behave
differently?  Or if it is intentional and not a bug, can you provide
justification for the behavior as well as tweaks to the proposed
standard wording for gettext requirements and the worked example?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org