From: Jun T <takimoto-j@kba.biglobe.ne.jp>
To: newlib@sourceware.org
Subject: wctomb() accepts out-of-range character in C-locale
Date: Mon, 25 Mar 2024 16:45:33 +0900 [thread overview]
Message-ID: <C6B0B594-6587-4D51-A894-9B265DF9B0AC@kba.biglobe.ne.jp> (raw)
Dear newlib developers,
(this is the first time I post to this list)
On recent Cygwin, the following C code output '1' (i.e., wide character
0x80 can be converted into a valid single-byte character in C-locale):
---------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <locale.h>
int main() {
char buf[MB_CUR_MAX];
setlocale(LC_ALL, "C");
printf("%d\n", wctomb(buf, 0x80));
return 0;
}
---------------------------------------
On Linux it outputs '-1'.
It seems this is due to the following commit:
------------------------------------------------
commit 8a4318943875cd922601d34e54ce8a83ad2e733c
Author: Corinna Vinschen <corinna@vinschen.de>
Date: Mon Jul 31 12:44:16 2023 +0200
Revert "* libc/stdlib/mbtowc_r.c (__ascii_mbtowc): Disallow conversion of"
This reverts commit 2b77087a48ea56e77fca5aeab478c922f6473d7c.
For some reason lost in time, commit 2b77087a48ea5 introduced
Cygwin-specific code treating single byte characters outside the
portable character set as illegal chars. However, Cygwin was
always alone with this over-correct behaviour and it leads to
stuff like gnulib replacing functions defined in Cygwin with
their own implementation just due to that.
------------------------------------------------
Probably the function __ascii_wctomb() is used not only in C-locale
but also in some other locales, and the commit is for "fixing"
some problems in these locales?
But a wide character >= 0x80 can't be converted into a valid
character in C-loccale (7bit), I think.
next reply other threads:[~2024-03-25 7:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 7:45 Jun T [this message]
2024-03-25 10:32 ` Corinna Vinschen
2024-03-25 11:26 ` Bruno Haible
2024-03-25 11:34 ` Corinna Vinschen
2024-03-25 14:07 ` Jun. T
2024-03-25 20:18 ` brian.inglis
2024-03-26 1:43 ` Jun. T
[not found] ` <IBDYAS.IT0GDL3WNBOQ@att.net>
2024-03-26 11:48 ` Steven J Abner
2024-03-27 8:01 ` Jun. T
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C6B0B594-6587-4D51-A894-9B265DF9B0AC@kba.biglobe.ne.jp \
--to=takimoto-j@kba.biglobe.ne.jp \
--cc=newlib@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).