This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: representing charsets
- From: Andy Koppe <andy dot koppe at gmail dot com>
- To: cygwin-developers at cygwin dot com
- Date: Fri, 2 Apr 2010 20:32:38 +0100
- Subject: Re: representing charsets
- References: <416096c61003300449u737a0c8x3155217e8e16aa1e@mail.gmail.com> <20100330144658.GA18364@calimero.vinschen.de> <w2m416096c61003302253t932c5756u9c96351869052804@mail.gmail.com> <20100331083453.GA22524@calimero.vinschen.de> <l2t416096c61003311414x15f17482zcc760d66bddf39d8@mail.gmail.com> <20100401143001.GA28167@calimero.vinschen.de>
Corinna Vinschen:
>> I'd be tempted to replace the 'char *codeset' fields in the various
>> locale info structs with integer IDs as well, but the entanglement
>> with the _*_locale_buf buffers makes that rather complicated.
>
> If we use the enums as you proposed, and if we also add a table to
> newlib which maps the enums to charset names, then we could do that.
Unfortunately I can't see where to store the enums for the locale
category codesets, since __part_load_locale in newlib and the new
rebase_locale_buf in nlsfuncs.cc assume that the various lc_*_T
structs consist entirely of pointers.
> The next step then would be an offical API to allow the locale(1) tool
> to get the names of all supported codesets, rather than having to have
> a codeset list in the application itself.
Is there a (de facto) standard API for that?
Andy
ps: Could you attach the Cygwin counterpart of your big newlib locale patch?