Re: [bug-gnu-libiconv] difference in iconv for EBCDIC SBCS conversion from z/OS OS-provided iconv

[Bruno Haible]

Hi Mike,

> >   - The iconv _library functions_ don't test the environment variable.
> >     It's the iconv _program_ which tests it and passes the information
> >     to the library.
> >...
> Oh. Hm. So that means if a tool uses the iconv() _function_, they will not
> have the ability to use the alternate code point _even if_ they set the
> environment variable?

For the library functions, different designs apply than for a program.

For a program, the user's convenience is important.

For a library, multithread-safety and an object orientated / functional
design are important.

Therefore it's often bad design to have library functions that depend
on the value of an environment variable (or, more generally, on external
state). Simple example: If an application wants to do a conversion with
IBM-1047 in one thread a conversion with the modified IBM-1047 in another
thread. This would be impossible, since there is only one 'environ' object
in the program; it is not per-thread.

I have implemented two ways to get the modified IBM-1047 in the library
functions:
  - By use of iconvctl. See "groff -Tutf8 -mandoc man/iconvctl.3".
  - By passing the encoding name "IBM-1047/ZOS_UNIX" instead of "IBM-1047"
    to iconv_open.
These two should be sufficiently flexible for all kinds of applications.

> That doesn't sound ideal. I would think many of
> the tools we are porting may be binding libiconv rather than calling it.

These tools can implement the behaviour they want, through the two
ways mentioned above. It's not many lines of code.

> It would seem acceptable if "ICONV_EBCDIC_ZOS_UNIX=1 make check" failed
> because the tests expect the default behaviour.

That's not the main point. The main point is a clean library design.

Bruno