This is good, unless someone has objections I'll commit this. However, we also need the ability to do unicode in the assembler (I'll do this later today if no one beats me to it), and we need some way to communicate the encoding number between the C and the Perl code.
I guess the question with native strings is will it always be ASCII or will it be Shift-JIS etc...? And the follow up to that is can, for the short term, we assume it will be ASCII and then improve our native string transcoding over time? Tanton -----Original Message----- From: Tom Hughes To: [EMAIL PROTECTED] Sent: 10/7/2001 10:23 AM Subject: Transcoding patch The attached patch is a first stab at implementing string transcoding and the unicode string types. The transcoder will currently only map one UTF type to another - there is no attempt to implement mapping to or from native strings as I wasn't sure what the plan was for that. Presumably we will have to determine what the native character set is at configure time and then generate some code to map between that and unicode somehow? There are currently no proper tests because there is no way to generate anything other than a native string using the current assembler. There is a small C test harness (trans-test.c) which I have used to validate the transcoder to a certain extent. This patch also fixes a bug in the existing native strings where string_native_compute_strlen was returning the number of bytes that had been allocated rather than the number that were in use. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ <<transcode.patch>>
