Subject: Handling String for Future O/S

From: Ng Liang Shing <[email-masked]>
Date: Mon, 11 Jul 1994 14:33:46 MYT

Handling String for Future O/S

As future O/S moves towards double-byte string compatibility, new data
structures for handling string has been proposed.  I have seen such proposals
in at least two occasions:  Unicode string handling and NeXT API.

Traditionally, a string is represented in C as a pointer to character i.e.
char *.  The new structure being proposed is to represent string using derived
types.  e.g.  In the new NeXT API, string should use NSString *.  NSString is
derived and defined in the API.  The same idea goes behind Unicode string, the
keyword being a wee bit different.

As the standard has not settle as yet, during the transition, what structure
should we use for handling string?

My answer is to use a unique keyword that is different from char. Any keyword
will do.  We may define our own structure for the moment.  When moving onto a
few platform, replace the keyword with the platform specific one.

e.g.  declare string using type CHString * 'Chinese string'.  In DOS at the
moment, use

typedef struct { char t; /* type:  ASCII, GB or Big5 */
                 char h; /* the High byte */
                 char l; /* the Low byte */ } CHString;

When move to NeXT, use

typedef NSString CHString

The reason for using a unique keyword from char is simple:  because string is
different from char in terms of what it is.  char CAN be used for string or
any other 8-bit value.  String is a special case, so we must distinguish
string from char.

This is true even for single byte string. It is always a good practice to
define a new type to mean a different variable. In this case, simply use

typedef char String

Then declare a String variable using String *.

The CHString above is 3 byte per character, the extra character being used for
type. This can be saved to two bytes if we use some enconding scheme.

ASCII: high byte = 0
GB:    high byte = 1 to 127 (lower ASCII range)
Big5:  high byte = 129 to 255 (upper ASCII range)

However, this is an internal representation. So it should not be confused with
the Extended HZ coding scheme.

GB low byte should use lower ASCII range instead of upper ASCII range.

--
Ng Liang Shing            |   This is an Internet node host inside
Sungai Petani, Malaysia   |   an old 286.  A few years back, this place
[email-masked]          |   was not more than a small town.