locale data should be consistent-endian (big)

[yuripv]

Summary

For sake of completeness, here's how the consistent-endian implementation looks like -- it's significantly less intrusive, and generally looks cleaner.

The only thing to check here is the performance effect, and being in beta stage for 12.0 now, I guess I have the time to do just that. Any hints on testing as I'm not really familiar with performance issues?

[yuripv]

Sean, could you please give this a try on ref12-ppc64?

lib/libc/locale/collate.c

246

This is the only *real* issue in rS308170 -- wchar_t is (unsigned) int, so 4 bytes.

[sbruno]

In D17618#376145, @yuripv wrote:

Sean, could you please give this a try on ref12-ppc64?

You would like me to revert D17603 and apply this singular diff?

[yuripv]

In D17618#376157, @sbruno wrote:

In D17618#376145, @yuripv wrote:

Sean, could you please give this a try on ref12-ppc64?

You would like me to revert D17603 and apply this singular diff?

Please disregard this for now, collation is completely broken with this change and it is the case with rS308170 for mips, it's just not that visible as ctype. I'll check if it's worth fixing at all as the fix seems to be quite involved. Sorry for the noise.

[yuripv]

With this change alone (and that's what it actually looked for mips) collation is broken. The changes *and* the amount of conversion we need to do every time we load the collation tables make this way not worth it IMO.