Hi,
Sachin T wrote:
> Yes, you’re right — locale_t is not yet part of the official z/OS runtime
> API. However, we do have a library called
> zoslib<https://github.com/ibmruntimes/zoslib> which provides implementations
> for many POSIX APIs not natively available on z/OS. The locale_t type and
> related functions, including getlocalename_l, are implemented as part of this
> library.
OK, this at least partially resolves the questions.
My question was:
> Is the 'locale_t' type and its
> associated functions now usable in z/OS or not?
In light of what you said, this probably boils down to:
* Is the zoslib library easy to install for users?
In light of <https://github.com/ibmruntimes/zoslib/issues/67>,
the answer appears to be "no".
* Are the newlocale, duplocale, freelocale functions from zoslib
working as specified in POSIX?
Given that there is no unit test for newlocale in
<https://github.com/ibmruntimes/zoslib/tree/main/test>,
the answer appears to be "no" as well.
(From 30 years of experience, I can say: It is safe to assume
that a piece of code does not work if it has not been tested.)
So, in the current state of affairs it is best to assume that zoslib
does not exist, and then - like in 2019 - you should ensure that
Gnulib defines its own 'locale_t' type. This will make the compilation
error in coreutils go away.
Bruno
