Agreed - I think any added support for these should first look whether migrating over to musl upstream code to replace an older handwritten one will provide a fix, and if not, it would be preferred to first add the feature to musl and then bring it as an updated musl version to Emscripten.
If not, the best route of action is probably to identify the smallest surface area of api modifications that are needed so that existing musl code that we already build can also recognize the added new locale features. For example, how would sprintf which we implement from upstream musl hook into this? It sounds to me like the browser-specific parts that we port are in the locale info fields, rather than changing existing code algorithms, i.e. that we would not use Intl.DateTimeFormat as a replacement to strftime, but instead figure out how to feed the browser locale info into strftime using the musl machinery. 2014-11-17 19:58 GMT+02:00 Alon Zakai <[email protected]>: > In general adding such support is great. The only issue is if it is in > code we get from upstream musl, in which case we would need to coordinate > with them, we don't want to diverge more than we have to. > > - Alon > > > On Sat, Nov 15, 2014 at 2:06 PM, Nicholas Wilson < > [email protected]> wrote: > >> Hi, >> >> Emscripten currently supports only the C locale (and its "POSIX" alias), >> and doesn't even have "C.UTF-8" (emscripten's "C" locale claims its codeset >> is ASCII, although actually its functions like printf and strftime are >> already completely UTF-8-safe). We ship complete translations for several >> languages in our products, and will soon have to have multi-language >> support in our emscripten product. >> >> Really, it's just the date and time that we need from C, when it comes >> down it. If I submitted support for just this, would that be OK, or would >> you want "complete" support for all the odd number-parsing and monetary >> functions too? >> >> These are the functions that are locale-dependent: >> * atoi/atol/sscanf/printf/strtol and all the other digit-parsing and >> printing functions >> These can be supported using Intl.NumberFormat in browsers to output nice >> Arabic digits; there isn't a handy ECMAScript function for parsing though, >> oddly. Getting the currency symbol for strfmon is also possible using >> NumberFormat. >> * strftime >> This can be implemented using Intl.DateTimeFormat >> * strcoll, isupper, etc (character functions) >> Intl.Collator should be helpful here >> * nl_langinfo >> Some of the things like D_FMT are a right nuisance to scrape from >> Intl.DateTimeFormat but should probably be possible. >> >> I don't know much about C++ locale stuff, never had need for it (I stick >> to the C functions that work, plus bits of ICU to replace broken ISO >> functions). >> >> Maybe struggling to retro-fit the ECMAScript functions into the C ones is >> just too error-prone though? Another alternative I'd be happy to code up >> would be an Emscripten-specific set of date/time functions to go in >> <emscripten.h> that expose the browser's locale functions without munging >> them into a legacy C interface. You already have to call platform-specific >> functions on Mac and Windows already, because the C strftime is buggy and >> incomplete, so having a solid set of emscripten functions might be both >> easier and preferable to trying to make setlocale+strftime work just like >> on Linux. >> >> Any thoughts on these possibilities? >> >> Nick >> >> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
