| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
these were removed from the standard but still offered as an extension
in langinfo.h, so nl_langinfo should support them.
(cherry picked from commit 0206f596d5156af560e8af10e950d3cb2f29b73d)
|
| |
|
|
|
|
|
| |
due to a skipped slot and missing null terminator, the last few
strings were off by one or two slots from their item codes.
(cherry picked from commit a19cd2b64aabee4ae3c80bcf4ba8da26fba560e4)
|
| |
|
|
| |
posix allows zero length destination
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with these changes, the character set implemented as "big5" in musl is
a pure superset of cp950, the canonical "big5", and agrees with the
normative parts of Unicode. this means it has minor differences from
both hkscs and big5-2003:
- the range A2CC-A2CE maps to CJK ideographs rather than numerals,
contrary to changes made in big5-2003.
- C6CD maps to a CJK ideograph rather than its corresponding Kangxi
radical character, contrary to changes made in hkscs.
- F9FE maps to U+2593 rather than U+FFED.
of these differences, none but the last are visually distinct, and the
last is a character used purely for text-based graphics, not to convey
linguistic content.
should there be future demand for strict conformance to big5-2003 or
hkscs mappings, the present charset aliases can be replaced with
distinct variants.
reportedly there are other non-standard big5 extensions in common use
in Taiwan and perhaps elsewhere, which could also be added as layers
on top of the existing big5 support.
there may be additional characters which should be added to the hkscs
table: the whatwg standard for big5 defines what appears to be a
superset of hkscs.
|
| |
|
|
|
|
| |
at this point, it is just the common base charset equivalent to
Windows CP 950, with no further extensions. HKSCS and possibly other
supersets will be added later. other aliases may need to be added too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
like for other character sets, stateful iso-2022 form is not supported
yet but everything else should work. all charset aliases are treated
the same, as Windows codepage 949, because reportedly the EUC-KR
charset name is in widespread (mis?)usage in email and on the web for
data which actually uses the extended characters outside the standard
93x94 grid. this could easily be changed if desired.
the principle of this converter for handling the giant bulk of rare
Hangul syllables outside of the standard KS X 1001 93x94 grid is the
same as the GB18030 converter's treatment of non-explicitly-coded
Unicode codepoints: sequences in the extension range are mapped to an
integer index N, and the converter explicitly computes the Nth Hangul
syllable not explicitly encoded in the character map. empirically,
this requires at most 7 passes over the grid. this approach reduces
the table size required for Korean legacy encodings from roughly 44k
to 17k and should have minimal performance impact on real-world text
conversions since the "slow" characters are rare. where it does have
impact, the cost is merely a large constant time factor.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
LC_GLOBAL_LOCALE refers to the global locale, controlled by setlocale,
not the thread-local locale in effect which these functions should be
using. neither LC_GLOBAL_LOCALE nor 0 has an argument to the *_l
functions has behavior defined by the standard, but 0 is a more
logical choice for requesting the callee to lookup the current locale.
in the future I may move the current locale lookup the the caller (the
non-_l-suffixed wrapper).
at this point, all of the locale logic is dummied out, so no harm was
done, but it should at least avoid misleading usage.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
the latter is both for ABI purposes, and to facilitate eventually
adding LC_TIME support. it's also nice to eliminate an extra source
file.
|
| |
|
|
|
| |
this seems to have been a simple copy-and-paste error from the code
for converting from legacy codepages.
|
| |
|
|
|
|
|
|
| |
to deal with the fact that the public headers may be used with pre-c99
compilers, __restrict is used in place of restrict, and defined
appropriately for any supported compiler. we also avoid the form
[restrict] since older versions of gcc rejected it due to a bug in the
original c99 standard, and instead use the form *restrict.
|
| |
|
|
|
| |
posix has resolved to add this usage; for now, we just avoid writing
anything to the new locale object since it's not used anyway.
|
| |
|
|
|
|
|
|
| |
dynamic-allocation of the structure is not valid; it can crash an
application if malloc fails. since localeconv is not specified to have
failure conditions, the object needs to have static storage duration.
need to review whether all the values are right or not still..
|
| | |
|
| | |
|
| |
|
|
| |
apparently this was never tested before.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
these are mostly untested and adapted directly from corresponding byte
string functions and similar.
|
| |
|
|
|
|
| |
this should be everything except for some functions where the non-_l
version isn't even implemented yet (mainly some non-ISO-C wcs*
functions).
|
| | |
|
| | |
|
| |
|
|
|
| |
also support (and restrict to subsets) older chinese sets, and
explicitly refuse to convert to cjk (since there's no code for it yet)
|
| | |
|
| | |
|
| |
|
|
|
| |
this broke most uses of iconv in real-world programs, especially
glib's iconv wrappers.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
sadly the C language does not specify any such implicit conversion, so
this is not a matter of just fixing warnings (as gcc treats it) but
actual errors. i would like to revisit a number of these changes and
possibly revise the types used to reduce the number of casts required.
|
| | |
|
| |
|
