Date: Mon, 29 Sep 2008 16:20:03 GMT From: Garrett Wollman <wollman@csail.mit.edu> To: freebsd-standards@FreeBSD.org Subject: Re: kern/114578: [libc] wide character printing using swprintf(dst, n, "%ls", txt) fails depending on LC_CTYPE Message-ID: <200809291620.m8TGK3Xk071022@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/114578; it has been noted by GNATS. From: Garrett Wollman <wollman@csail.mit.edu> To: Christoph Mallon <christoph.mallon@gmx.de> Cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/114578: [libc] wide character printing using swprintf(dst, n, "%ls", txt) fails depending on LC_CTYPE Date: Mon, 29 Sep 2008 11:44:27 -0400 <<On Mon, 29 Sep 2008 08:10:03 GMT, Christoph Mallon <christoph.mallon@gmx.de> said: >> fputwc(3) has similar language about copying the character to the >> output stream, but POSIX still says it can fail with EILSEQ if the >> wide character doesn't exist in the current locale. > fputwc() is entierly different from swprintf(): fputwc() writes to a > stream, swprintf() writes to an array of wchar_t. >> This isn't my area of expertise, but the present behavior seems >> correct. > No, it isn't. The Standard is clear: In addition, all forms of fwprintf() may fail if: [EILSEQ] A wide-character code that does not correspond to a valid character has been detected. (IEEE Std.1003.1-2001 page 471, line 15515) You may wish that it was implemented differently, but that doesn't mean that the current implementation is wrong. -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200809291620.m8TGK3Xk071022>