> One possibility is that above won't work either and
> codeset = nl_langinfo(CODESET);
> isn't working as I expected.
> I may need to add a fallback.
>
After googling a bit around I found that nl_langinfo is not quite as useful
as it could be, since it frequently returns the names of codesets in a non
standardized form, see e.g.
http://www.cl.cam.ac.uk/~mgk25/ucs/norm_charmap.c
http://archives.postgresql.org/pgsql-hackers/2003-05/msg00744.php
Especially in my case (Solaris) it returns "664" instead of "US-ASCII" ,
however the following Tcl_GetEncoding does not know about a codeset "664", so it
returns NULL instead of a valid Tcl_Encoding, which probably finally causes
the segmentation fault.
To fix this problem, you could either convert the result of nl_langinfo to a
canonical name (like described in the links mentioned above), or more simply
recall Tcl_GetEncoding with a known encoding ("iso8859-1" or "us-ascii") if
the first call returns NULL.
In my case, since I know that for my systems "664" is the only encoding that
causes troubles, I just check the return from nl_langinfo:
if (strcmp(codeset,"664") == 0) codeset="US-ASCII";
However, this is of course no portable solution.
Christoph
--
+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server. If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ptk" to majordomo@xxxxxxxxxxxxxxxxxx
|
