Some libraries are affected by the introduction of wide characters.
When using library(jasper)
SICStus Prolog properly receives
non-ASCII strings from Java, and similarly, non-ASCII strings can be
correctly passed to Java. This is in contrast with versions of SICStus
Prolog earlier then 3.8 (i.e. without the WCX extensions), where, for
example, strings containing non-ASCII characters passed from Java to
Prolog resulted in an UTF-8 encoded atom or code-list on the
Prolog side.
Several predicates in libraries sockets
, system
and
tcltk
create streams. These now use the
SP_make_stream_context()
function, with SP_WCX_FLAG
as the
option and the relevant SP_STREAMHOOK_LIB
constant as the context
argument. For example, if the WCX mode is set using environment
variables (see WCX Environment Variables), then this implies that
the selected encoding will be used for streams created in the
libraries. E.g. if the SP_CTYPE
environment variable is set to
utf8
, then the output of non-ASCII characters to a socket
stream will be done using UTF-8 encoding. If a
wcx_open
hook is supplied, then the user is free to select
a different encoding for the libraries, as he is informed about the
stream being opened by a library through the context
argument of the wcx_open
function.
Some of the arguments of library predicates contain
atoms that are file names, environment variable names, commands,
etc. If these contain non-ASCII characters, then they will be passed to
the appropriate operating system function following a conversion to the
system encoding in force (wcx_to_os
hook), and
similarly such atoms coming from the OS functions undergo a
conversion from system encoding (wcx_from_os
). Note
however that host names (e.g. in system:host_name(S)
) are
assumed to be consisting of ASCII characters only.