Sorting out the i18n header mess




While trying to figure out the i18n configuration mess, I've
put together the following which describes the situation on
various systems. If people could check out the information
as it applies to their system and supplement it, if necessary,
I'd appreciate it. Thanks,
                                        Owen

There are three identifiable classes of functions:

  POSIX multibyte string functions:
    mblen, mbstowcs, mbtowc, wcstombs, wctomb, mblen, mbstowcs,
    mbtowc, wcstombs, wctomb

  Wide character classification functions:
    iswalnum(), ...

  Other wide character string manipulations functions:
    putwc, wcscat, wcscpy, ...

Systems I have access to:
------------------------
AIX 4:
  POSIX: <stdlib.h>
  wchar class: <wchar.h> (also in <ctype.h>, if ALL_SOURCE defined)
  other: <wchar.h> (also in <wchar.h>, if ALL_SOURCE defined)
   
  Notes: has <wcstr.h> for backwards compatibility.
         does not have <wctype.h>

glibc 2.0.5c
X/Open Single Unix spec, v2.0
  POSIX: <stdlib.h>
  wchar class: <wctype.h>
  other: <wchar.h>

Other systems
-------------
HP/UX 9.05:
  POSIX: <stdlib.h> (?)
  wchar class: <wchar.h>
  other: <wchar.h> ???
  Notes: <wchar.h> maybe conflicts with <wctype.h>. (???)

Solaris 2.5
  POSIX: <stdlib.h>
  wchar class: <wchar.h>
  other: <wchar.h> ???
  Notes: has a <wctype.h> that conflicts with <wchar.h>. (?)

Solaris 2.6
  POSIX: <stdlib.h>
  wchar class: <wchar.h>
  other: <wchar.h> ???
  Notes: does not have <wctype.h> (?)

IRIX 5.1
  POSIX: <stdlib.h> (?)
  wchar class: does not have (?)
  other: does not have (?)

Linux libc5
  POSIX: <stdlib.h> (?)
  wchar class: does not have (?)
  other: does not have (?)
 
Whatever Tim has:
  Has <wchar.h> and <wctype.h>, which when included together produce
  a warning

Random notes:
-------------

- X11R6 provides the POSIX functions and some of the 
  miscellaneous wide char functions with a lot more working locales than
  most systems. It doesn't provide the char class functions.

- X11R5 doesn't provide anything (?)

- When using the X locale support with -DX_LOCALE, it isn't safe
  to use other wide-char functions from the OS.

- Something funny goes on with Solaris 2.6 - setlocale() doesn't
  seem to work with the C locale!

Requirements:
-------------

- The POSIX functions are hard to do without.

- It is nice to have iswalnum, but lacking that, it is possible to
  a gross hack like:

#define iswalnum(c) ((wchar_t)(c) <= 0xFF && isalnum(c))
 
  This is needed in any case when running with -DX_LOCALE, since
  X doesn't provide iswalnum.

- The miscellaneous wide-char functions aren't needed now, though they
  would be useful if they were available.

Conclusions:
------------

All systems seem to have a mblen, mbcstowcs, etc., that at least
work with the C locale, defined in <stdlib.h>

People using X11R5 will need to use locales supported by their
system.

Solaris 2.5 is a complete pain to support.

Basic strategy:
  If system doesn't support locale, use -DX_LOCALE, and iswalnum hack.
  Otherwise
    If system has <wchar.h> which defines iswalnum (how to determine?)
      just include <wchar.h>
    If system has <wctype.h>, just include <wctype.h>
    Otherwise: 
      use iswalnum hack. 

A simpler strategy (basically Takashi Matsuda's) would be:
  If system doesn't support locale, use -DX_LOCALE, and iswalnum hack.
  Otherwise
    If system has <wctype.h> just include <wctype.h>
    If system has <wchar.h> just include <wchar.h>
    Otherwise,
      Use iswalnum hack.
 
This would, however, use the iswalnum() function from <wctype.h>
for Solaris 2.5 in preference to those from <wchar.h>. Since <wctype.h>
doesn't exist on Solaris 2.6 (?), I'm not sure this is correct.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]