svn commit: r265167 - head/lib/libc/locale

[Pedro Giffuni]

Oops.. wrong log!!

Should've been this:
_____________

citrus: pass U+FFFE and U+FFFF normally.

r265095, based on an OpenBSD change was rejecting U+FFFE and U+FFFF
in accordance with outdated documentation. Both values are valid
"non-characters" [1] and must be mapped through UTFs.

Reference:
http://www.unicode.org/faq/private_use.html [1]

Reported by:    jilles
MFC after:    4 days

_____________


I will fix it for the MFC.

Pedro.

On 04/30/14 20:42, Pedro F. Giffuni wrote:
> Author: pfg
> Date: Thu May  1 01:42:48 2014
> New Revision: 265167
> URL: http://svnweb.freebsd.org/changeset/base/265167
>
> Log:
>    citrus: Avoid invalid code points.
>    
>    From the OpenBSD log:
>    The UTF-8 decoder should not accept byte sequences which decode to unicode
>    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
>    
>    Reported by:	Stefan Sperling
>    Obtained from:	OpenBSD
>    MFC after:	5 days
>
> Modified:
>    head/lib/libc/locale/utf8.c
>
> Modified: head/lib/libc/locale/utf8.c
> ==============================================================================
> --- head/lib/libc/locale/utf8.c	Thu May  1 00:31:19 2014	(r265166)
> +++ head/lib/libc/locale/utf8.c	Thu May  1 01:42:48 2014	(r265167)
> @@ -203,8 +203,7 @@ _UTF8_mbrtowc(wchar_t * __restrict pwc,
>   		errno = EILSEQ;
>   		return ((size_t)-1);
>   	}
> -	if ((wch >= 0xd800 && wch <= 0xdfff) ||
> -	    wch == 0xfffe || wch == 0xffff) {
> +	if (wch >= 0xd800 && wch <= 0xdfff) {
>   		/*
>   		 * Malformed input; invalid code points.
>   		 */
>