site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Feb 25, 2005, at 3:57 PM, Monroe Williams wrote: ------------------------------------------------------------------------ Monroe Williams monroe@criticalpath.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... I was having some trouble using setlocale() in a reasonably complex, cross-platform application which links with the Carbon framework, among other things. I've constructed a trivially simple test program that calls setlocale(LC_ALL, "en-US"), and then calls localeconv() and prints out the relevant parts of the resulting structure. Gah, proofreading. The program does correctly use "en_US", not "en-US" as I typed here. If I build the test program with 'gcc localetest.c -o localetest' everything works as expected. If I build the test program with 'gcc -framework Carbon localetest.c -o localetest' (with NO other changes), the setlocale() call seems to have no effect. This means that several of the fields I'm interested in (negative_sign, mon_thousands_sep, and mon_grouping, to be specific) end up as empty strings. It seems nonsensical that linking with the Carbon framework would change the behavior of posix API's like this, but I just saw it happen. I realize that there are alternate internationalization API's available in Carbon, but for my purposes, posix locale support should be more than sufficient, and there's no reason it shouldn't work. Any Apple folks care to comment? If there's a simple workaround (that doesn't involve not linking with Carbon), I'd love to hear it. This email sent to site_archiver@lists.apple.com