From storm@texas.dk Wed Feb 13 12:04:46 1991
Received: from texas.dk by dkuug.dk via EUnet with UUCP (5.64+/8+bit/IDA-1.2.8)
	id AA07308; Wed, 13 Feb 91 12:04:46 +0100
Received: by texas.dk (smail2.5)
	id AA15481; 13 Feb 91 12:04:40 MET (Wed)
To: keld@dkuug.dk
Cc: i18n@dkuug.dk
In-Reply-To: Keld J|rn Simonsen's message of Tue, 12 Feb 91 23:22:39 +0100 <9102122222.AA17488@dkuug.dk>
Subject: Re: (i18n 72) paper presented to WG11
Message-Id: <9102131204.AA15475@texas.dk>
Date: 13 Feb 91 12:04:38 MET (Wed)
From: storm@texas.dk (Kim F. Storm)
X-Charset: ASCII
X-Char-Esc: 29


I agree with Keld that using the names in the charmap is an excellent
way to write portable strings (provided we can agree on the character
names to use in the charmap).

The problem with introducing these general strings is how to merge
them into existing languages and utilities.  Keld uses the example

           "s<o/>ndag"

which would need some currently unspecified functions to interpret
(e.g. for printing or pattern matching).

Let us take this a step further and play with the idea of using the
following syntax in C:

	char *str = "s\<o/>ndag";

There are some possible interpretations here:

	1. The \<o/> character is substituted into the string at
	   compile time.  This would be a trivial addition to the
	   compiler, but it would not ensure portability of the
	   binary, since it would be "linked" with the charmap
	   of the system where the program was compiled.
	   
	2. It can still be compiled in some "tricky" way and resolved
	   at LOAD time.  If COFF format is used, I would guess that
	   a "charmap" section could be used to resolve this.
	   
	3. Compile the \< token into an otherwise unused character
	   code and use that at run-time to trigger "on the fly"
	   substitution in all STANDARD routines operating on strings,
	   e.g. strcpy and printf.

	4. Forget the whole thing, and write a complete new set of
	   functions to operate on "portable strings".
	   
From a "normal" programmer's point of view (don't care how it works,
as long as it works...), I would prefer solution #3.

--
Kim F. Storm, Texas Instruments A/S, Denmark.
Chairman of the Danish POSIX WG (S142 u22 A11)