Re: [bug-gettext] make check with gettext-0.19.6 and 0.19.5 fails more than compared to 0.19.4

[Michael Felt]

Well, several months down the road, and sadly, rather than failing to pass some tests (that could have just been noted as iconv() translation is not always bidirectional on AIX, now it is required as an extra component.

As long as GNU iconv() never develops a dependency on gettext we will be okay.

I have learned, as I resolve this in may packages that never used to had a dependency on GNU iconv - not get it for free.

I do not understand the need from gettext to translate "bi-directional". The standard accepts " " as a valid translation of a legal character. (i.e., "euro" to space is legal) - however, the iconv() transform 'back' will never be the same/identical (as "space" does not magically become "euro") - but is this a feature of gettext? I thought gettext is a message presentation system, not a multiple transform "whatever" and back to the original input.

afaik the AIX NLS (national language support) only has the function of presenting messages in different languages - not of reversed translations, better conversions back to the original.

Anyway, I get a lot of "sighs" from "users" who would rather keep dependencies to a minimum. Your wisdom is why this is a new requirement will help me answer their questions! :)

On Fri, Oct 23, 2015 at 11:51 PM, aixtools <address@hidden> wrote:

On 2015-10-23 20:28, aixtools wrote:

On 2015-10-23 20:09, aixtools wrote:

FAIL: msgcat-2
==============

msgcat: Cannot convert from "ISO-8859-1" to "UTF-8". msgcat relies on iconv(). This version was built without iconv().
FAIL msgcat-2 (exit status: 1)

The AIX libiconv.a is considered "unsuitable" because it returns a one-byte string (" ") for the Unicode conversion of the Euro-Symbol.
While this may be your choice - calling it a "bug" is not accurate - as the official (looking) standard documentation (see http://pubs.opengroup.org/onlinepubs/009695399/functions/iconv.html)

states:

If iconv() encounters a character in the input buffer that is valid, but for which an identical character does not exist in the target codeset, iconv() shall perform an implementation-defined conversion on this character.

RETURN VALUE

The iconv() function shall update the variables pointed to by the arguments to reflect the extent of the conversion and return the number of non-identical conversions performed. If the entire string in the input buffer is converted, the value pointed to by inbytesleft shall be 0. If the input conversion is stopped due to any conditions mentioned above, the value pointed to by inbytesleft shall be non-zero and errno shall be set to indicate the condition. If an error occurs, iconv() shall return (size_t)-1 and set errno to indicate the error.

ERRORS

The iconv() function shall fail if:

[EILSEQ]

Input conversion stopped due to an input byte that does not belong to the input codeset.

[E2BIG]

Input conversion stopped due to lack of space in the output buffer.

[EINVAL]

Input conversion stopped due to an incomplete character or shift sequence at the end of the input buffer.

The iconv() function may fail if:

[EBADF]

The cd argument is not a valid open conversion descriptor.

What I specifically see as an official reason for returning an error - that is required! is when there is an error in the INPUT string. And specifically, when it does not exist in the output, aka target codeset - it is implementation defined - and AIX (read the IBM architect way back when) implemented as a blank space.

This is, it seems, not what GNU, or GETTEXT wants to see, but it is not a bug - just different. Documenting that way will save people like myself mucho troubles - AND - to be generous to AIX, Solaris, and HP-UX who all seem to have something to fall over in that text - a switch to permit "the consequences" would be generous.

The standards people had their reasons to let it be implementation defined - just do not ask me what they were.

Sincerely,
Michael