summaryrefslogtreecommitdiffstats
path: root/lib/libc/citrus (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Trivial cleanup: Pass pointers of the correct types to the privateschwarze2016-09-071-9/+7
| | | | | | functions and delete a macro that is used in only one place; no functional change. This completes the audit of the citrus directory (only 3 files left).
* trivial cleanup: delete inline attribute on static function,schwarze2016-09-071-3/+3
| | | | leave that decision to the compiler; no functional change
* trivial cleanup:schwarze2016-09-072-79/+70
| | | | | | | | | | - delete unused headers - add missing function prototype - delete needless casts of return values - KNF: return is not a function - KNF: do not use a pointer as a boolean - consistent wording in comments: s/octets/bytes/ OK gcc: no object change after strip -g
* Delete some abstraction that we don't and won't need.schwarze2016-09-058-289/+41
| | | | | | | | | | | | | | | | Declare functions rather than generating declarations with macros. Just call functions rather than mainting function pointer tables. Purge unused arguments. Simplify mbstate_t casting. Garbage collect one empty and one unused function. As a bonus, make mbsinit(3) work at all, it returned garbage in the past due to a missing cast when passing mbstate_t. Apart from that, no functional change. No libc bump needed; only private functions are removed and change prototype and only private structs change size. OK stsp@ mpi@; deraadt@ likes the general direction.
* delete old lint ARGSUSED commentsguenther2015-11-012-12/+2
|
* Tighten the ranges in wcrtomb(3).bentley2015-10-131-2/+2
| | | | | | | | | | | | By definition, the range of valid Unicode code points is the union of U+0000..U+D7FF and U+E000..U+10FFFF (see Unicode 8.0.0, chapter 3.9). In UTF-16, the encoded values that would represent U+D800..U+DFFF are used for surrogate pairs. UTF-8 has no concept of surrogate pairs; attempting to treat them as regular code points violates the standard and makes no sense besides. ok stsp@
* Make wcrtomb() more readable by weeding out range errors up front,schwarze2015-10-121-14/+11
| | | | | | | doing ASCII handling once rather than twice, and using <= rather than ((&~)==) obfuscation (which already caused a bug in the past). No functional change. Joint work with and OK stsp@ semarie@ bentley@
* Code points U+10000 to U+fffff are valid, too.schwarze2015-10-101-2/+2
| | | | | | Fixing a regression in wcrtomb(3) found with the mandoc testsuite that was caused by the last commit. OK semarie@ bentley@
* correct a range problem in citrus-utf8 version of wcrtomb(3), in order to matchsemarie2015-09-261-2/+2
| | | | | | | | | | RFC 3629 (limiting the range of UTF-8 to 0x10FFFF). it is the counterpart of a previous commit correcting mbrtowc(3). problem spotted by stsp ok bentley@ stsp@
* off-by-one for the previous patch. the limit is inclusive: 0x10ffff is a valid codepoint.semarie2015-09-051-2/+2
| | | | ok stsp@
* check for limiting the range of UTF-8 to 0x10FFFF, as requested by RFC 3629.semarie2015-09-051-1/+8
| | | | ok stsp@
* Use static and __{BEGIN,ENV}_HIDDEN_DECLS to hide a bunch of internalguenther2015-08-274-5/+11
| | | | | | symbols that are not longer exported. (This improves the generated code.) ok deraadt@
* Move to the <limits.h> universe.deraadt2015-01-161-3/+4
| | | | review by millert, binary checking process with doug, concept with guenther
* Noncharacters 0xFFFE and 0xFFFF don't render a UTF-8 string invalidstsp2014-05-031-3/+2
| | | | | | | | | so stop rejecting them in our citrus UTF-8 parser. This is a common misinterpretation of the Unicode standard which resulted in a corrigendum last year: http://www.unicode.org/versions/corrigendum9.html Pointed out by jilles@freebsd (via pfg@freebsd), thanks!
* Fix resetting MB_CUR_MAX when switching locales away from a UTF-8 locale.stsp2013-05-032-4/+5
| | | | | Patch by Vladimir Támara Patiño <vtamara@pasosdeJesus.org> ok mpi millert
* Fix return value of wcrtomb() in single-byte locales if the s argument is NULL.stsp2013-03-071-2/+2
| | | | | wcrtomb() must pretend to store one byte (NUL-terminator) in this case. Patch by Vladimir Tamara Patino. ok guenther
* Remove excessive sys/cdefs.h inclusionderaadt2012-12-053-6/+3
| | | | ok guenther millert kettenis
* Add support for mbsnrtowcs() and wcsnrtombs() to libc.matthew2012-06-063-169/+172
| | | | Bulk build test by naddy.
* Don't use 'n' for the length of multibyte chars, because it is the lengthyasuoka2011-04-211-2/+3
| | | | | | of wide characters. This will fix a problem of uim-fep pre-edit display. OK stsp@
* The UTF-8 decoder should not accept byte sequences which decode to unicodestsp2010-08-051-1/+9
| | | | | | | | | code positions U+D800 to U+DFFF (UTF-16 surrogates), U+FFFE, and U+FFFF. http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8 http://unicode.org/faq/utf_bom.html#utf8-4 ok phessler, millert, miod, deraadt
* When the target pointer 'pwcs' passed to mbsrtowcs() is NULL, mbsrtowcs()stsp2010-08-031-15/+9
| | | | | | | | | | | | | | | | | | | | | is supposed to ignore the 'n' parameter and return the number of wide characters needed to represent the given multi-byte character sequence. However, in the special case where 'pwcs' is NULL and 'n' is zero, our mbsrtowcs() implementation for single-byte locales mistakenly returned zero. Before the UTF-8 locale was added, this bug was invisible to callers of mbstowcs() because mbstowcs() handled this special case itself. But our new mbstowcs() implementation simply forwards to the locale-specific mbsrtowcs() implementation and expects it to do the right thing. The "awesome" window manager's "Run:" command prompt uses mbstowcs() to measure how many (possibly multi-byte) characters a user has typed, and due to this bug would always be tricked into thinking the user had entered zero characters when a single-byte locale was used. Found after prodding by dcoppa. ok deraadt sthen espie
* add missing header needed by strcmp()chl2010-08-012-2/+6
| | | | | | add missing prototype ok stsp@
* Remove stray newline, fix $OpenBSD$; ok deraadtstsp2010-07-292-3/+2
|
* Replace the single-byte placeholders for the multi-byte/wide-characterstsp2010-07-278-6/+765
| | | | | | | | | | | | | | | | | | | | | | | | | | | conversion interfaces of libc (mbrtowc(3) and friends) with new implementations that internally call an API based on NetBSD's citrus. This allows us to support locales with multi-byte character encodings. Provide two implementations of the citrus-based API: one based on the old single-byte placeholders for use with our existing single-byte character locales (C, ISO8859-*, KOI8, CP1251, etc.), and one that provides support for UTF-8 encoded characters (code based on FreeBSD's implementation). Install the en_US.UTF-8 ctype locale support file, and allow the UTF-8 ctype locale to be enabled via setlocale(3) (export LC_CTYPE='en_US.UTF-8'). A lot of programs, especially from ports, will now start using UTF-8 if the UTF-8 locale is enabled. Use at your own risk, and please report any breakage. Note that ncurses-based programs cannot display UTF-8 right now, this is being worked on. To prevent install media growth, add vfprintf(3) and mbrtowc(3) to libstubs. The mbrtowc stub was copied unchanged from its old single-byte placeholder. vfprintf.c doesn't need to be copied, just put in .PATH (hint by fgsch@). Testing by myself, naddy, sthen, nicm, espie, armani, Dmitrij D. Czarkoff. ok matthieu espie millert sthen nicm deraadt
* commit LC_CTYPE files from NetBSD/citrus, not yet linked in.espie2005-08-072-0/+72
okay deraadt@
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.