Solaris 9 CSI-enabled Libraries

Nearly all functions in libc (/usr/lib/libc.so) are CSI-enabled. However, the following functions in libc are not CSI-enabled because they are EUC-dependent functions:

• csetcol()

• csetlen()

• euccol()

• euclen()

• eucscol()

• getwidth()

• csetno()

• wcsetno()

In the Solaris 9 product, libgen /usr/ccs/lib/libgen.a and libcurses /usr/ccs/lib/libcurses.a are internationalized but not CSI-enabled.

Locale Database

The locale database format and structure is private and subject to change in a future release. Therefore, when developing an internationalized application, do not directly access the locale database. Instead, use the internationalization APIs in libc, described in "Internationalization APIs in libc".

Note - When working with the Solaris 9 environment, use the locale databases that are included with the Solaris 9 product. Do not use locales from previous Solaris versions.

Process Code Format

The process code format, which is also known as wide-character code format in the Solaris 9 product, is private and subject to change in a future release. Therefore, when developing an international application, do not assume the process code format is the same. Instead, use the internationalization APIs in libc described in "Internationalization APIs in libc".

Note - The process code for all Unicode locales is in UTF-32 representation. For more detail on UTF-32, refer to the "Unicode Standard Annex #19: UTF 32" and "Unicode Standard Annex #27: Unicode 3.1" from The Unicode Consortium or http://www.unicode.org/.

Multibyte Support Environment

A multibyte character is a character that cannot be stored in a single byte, such as Chinese, Japanese, or Korean characters. These characters require 2, 3, or 4 bytes of storage. A more precise definition can be found in ISO/IEC 9899:1990 subclause 3.13.

The Amendment 1 to ANSI C, which is also known as ISO/IEC 9899:1990, added new internationalization features, collectively known as the Multibyte Support Environment (MSE). Amendment 1 defines additional internationalization APIs for multibyte codesets with state and also for better wide-character handling support.

The programming model enables these multibyte characters to be read in as logical units and stored internally as wide characters. These wide characters can be processed by the program as logical entities in their own right. Finally, these wide characters can be written out, undergoing appropriate translation, as logical units.

This procedure is analogous to the way single-byte characters are read in, manipulated, and written out again. The MSE enables programs to be written to handle multibyte characters using the same programming model that is used for single-byte characters.

Dynamically Linked Applications

Solaris 9 product users can choose how to link applications with the system libraries, such as libc, by using dynamic linking or static linking. Any application that requires internationalization features in the system libraries must be dynamically linked. If the application has been statically linked, the operation to set the locale to anything other than C and POSIX using the setlocale function will fail. Statically linked applications can be operated only in C and POSIX locales.

By default, the linker program tries to link the application dynamically. If the command line options to the linker and the compiler include -Bstatic or -dn specifications, your application might be statically linked. You can check whether an existing application is dynamically linked using the /usr/bin/ldd command.

For example, if you type:

% /usr/bin/ldd /sbin/sh

the command indicates that the /sbin/sh command is not a dynamically linked program, as shown by the following response:

ldd: /sbin/sh: file is not a dynamic executable or shared object

If you type:

% /usr/bin/ldd /usr/bin/ls

the command displays the following message:

libc.so.1 => 	/usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1

This message indicates that the /usr/bin/ls command has been dynamically linked with two libraries, libc.so.1 and libdl.so.1.

Changed Interfaces

libw and libintl have moved to libc and are no longer in libw and libintl.

The shared objects ensure runtime compatibility for existing applications and, together with the archives, provide compilation environment compatibility for building applications. However, you no longer must build applications against libw or libintl.

For more information on filters, see the Linker and Libraries Guide.

The following list shows the stub entry points in libw.

fgetwc

fgetws

fputwc

fputws

getwc

getwchar

getws

isenglish

isideogram

isnumber

isphonogram

isspecial

iswalnum

iswalpha

iswcntrl

iswctype

iswdigit

iswgraph

iswlower

iswprint

iswpunct

iswspace

iswupper

iswxdigit

putwc

putwchar

putws

strtows

towlower

towupper

ungetwc

watoll

wcscat

wcschr

wcscmp

wcscoll

wcscpy

wcscspn

wcsftime

wcsclen

wscncat

wcsncmp

wcsncpy

wcspbrk

wcsrchr

wcsspn

wcstod

wcstok

wcstol

wcstoul

wcswcs

wcswidth

wcsxfrm

wctype

wcwidth

wscasecmp

wscat

wschr

wscmp

wscol

wscoll

wscpy

wscspn

wsdup

wslen

wsncasecmp

wsncat

wsncmp

wsncpy

wspbrk

wsprintf

wsrchr

wsscanf

wsspn

wstod

wstok

wstol

wstoll

wstostr

wsxfrm