Re: vfork always fail problem
>>> On Tue, 18 May 2010 10:31:36 -0400
>>> Christopher Faylor said:
>>2010-05-18 Kazuhiro Fujida
I mistyped my name in ChangeLog.
Please correct Fujida to Fujieda on the first opportunity.
>>- WCHAR corefile[strlen (p) + sizeof (".stackdump")];
>>+ WCHAR corefile[wcslen (p) + sizeof (L".stackdump")];
> ^^
> No L" is needed here, AFAICT.
You are right.
> I've checked this in, removing the L.
Thank you.
> Next time maybe you could send this to cygwin-patches?
Yes, I will do so.
--
Kazuhiro Fujieda
fuji...@acm.org
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: vfork always fail problem
>>> On Fri, 14 May 2010 21:22:02 +0200
>>> Corinna Vinschen said:
> That sounds a bit weird. The joke of using the ...W functions is that
> the string parameters are always given in UTF-16. GBK is a multibyte
> charset and can only be used in conjunction with the ...A functions.
> However, I'm on vacation so I can't test this scenario right now.
GetModuleFileName used in pinfo_basic::pinfo_basic disturbs the
order. This function uses ANSI codepage. 'fork' for a file whose
name contains multibyte characters doesn't work well in UTF-8 locales.
This call should be GetModuleFileNameW and the type of progname
in _pinfo should be wide characters. I attached the patch.
--
Kazuhiro Fujieda
fuji...@acm.org
2010-05-18 Kazuhiro Fujida
* environ.cc (regopt): Change the first argument to wide char string.
(environ_init): Accommodate change to the first argument of regopt.
* exception.cc (open_stackdumpfile): Accommodate change to the type
of progname in _pinfo.
* external.cc (fillout_pinfo): Ditto.
* fhandler_process.cc (format_process_winexename): Ditto.
(format_process_stat): Ditto.
* fork.cc (fork::parent): Ditto.
* pinfo.cc (pinfo_basic::pinfo_basic): Call GetModuleFileNameW
instead of GetModuleFileName.
(pinfo::thisproc): Accommodate change to the type of progname in
_pinfo.
(pinfo_init): Ditto.
* pinfo.h (_pinfo): Change the type of progname to a wide char array.
* registry.h (reg_key::get_int): Change the first argument from
constant point to pointer to constant.
(reg_key::get_string): Ditto. Change the last argument likewise.
* registry.cc (reg_key::get_int): Accommodate change to the
declaration.
(reg_key::get_string): Ditto.
* strace.cc (strace::hello): Accommodate change to the type of
progname in _pinfo.
(strace::vsprntf): Ditto.
Index: environ.cc
===
RCS file: /cvs/src/src/winsup/cygwin/environ.cc,v
retrieving revision 1.182
diff -u -r1.182 environ.cc
--- environ.cc 16 Nov 2009 20:05:49 - 1.182
+++ environ.cc 18 May 2010 05:31:45 -
@@ -29,6 +29,7 @@
#include "registry.h"
#include "environ.h"
#include "child_info.h"
+#include "ntdll.h"
extern bool dos_file_warning;
extern bool ignore_case_with_glob;
@@ -698,18 +699,24 @@
/* Set options from the registry. */
static bool __stdcall
-regopt (const char *name, char *buf)
+regopt (const WCHAR *name, char *buf)
{
bool parsed_something = false;
- char lname[strlen (name) + 1];
- strlwr (strcpy (lname, name));
+ UNICODE_STRING lname;
+ size_t len = (wcslen(name) + 1) * sizeof (WCHAR);
+ RtlInitEmptyUnicodeString(&lname, (PWCHAR) alloca (len), len);
+ wcscpy(lname.Buffer, name);
+ RtlDowncaseUnicodeString(&lname, &lname, FALSE);
for (int i = 0; i < 2; i++)
{
reg_key r (i, KEY_READ, CYGWIN_INFO_PROGRAM_OPTIONS_NAME, NULL);
- if (r.get_string (lname, buf, NT_MAX_PATH, "") == ERROR_SUCCESS)
+ if (r.get_string (lname.Buffer, (PWCHAR) buf, NT_MAX_PATH, L"") ==
ERROR_SUCCESS)
{
+ char *newp;
+ sys_wcstombs_alloc(&newp, HEAP_NOTHEAP, (PWCHAR) buf);
+ strcpy(buf, newp);
parse_options (buf);
parsed_something = true;
break;
@@ -747,7 +754,7 @@
}
char *tmpbuf = tp.t_get ();
- got_something_from_registry = regopt ("default", tmpbuf);
+ got_something_from_registry = regopt (L"default", tmpbuf);
if (myself->progname[0])
got_something_from_registry = regopt (myself->progname, tmpbuf)
|| got_something_from_registry;
Index: exceptions.cc
===
RCS file: /cvs/src/src/winsup/cygwin/exceptions.cc,v
retrieving revision 1.343
diff -u -r1.343 exceptions.cc
--- exceptions.cc 20 Apr 2010 10:44:52 - 1.343
+++ exceptions.cc 18 May 2010 05:31:45 -
@@ -130,24 +130,21 @@
{
if (myself->progname[0])
{
- const char *p;
+ const WCHAR *p;
/* write to progname.stackdump if possible */
if (!myself->progname[0])
- p = "unknown";
- else if ((p = strrchr (myself->progname, '\\')))
+ p = L"unknown";
+ else if ((p = wcsrchr (myself->progname, L'\\')))
p++;
else
p = myself->progname;
- WCHAR corefile[strlen (p) + sizeof (".stackdump")];
+ WCHAR corefile[wcslen (p) + sizeof (L".stackdump")];
+ wcscpy(corefile, p);
UNICODE_STRING ucore;
OBJECT_ATTRIBUTES attr;
/* Create the UNICODE variation of .stackdump. */
-
Re: strftime %b is broken on ja_JP locale
>>> On Fri, 14 May 2010 21:27:16 +0200 >>> Corinna Vinschen said: >> It should return "5\u6708" in Japanese and "5\uc6d4" in >> Korea. MSDN in Japanese describes so. It, however, returns "5" >> in both locales. > > Can you please tell us the number of the knowledge base article saying > so? There is only a Japanese article: http://msdn.microsoft.com/ja-jp/library/cc422084.aspx This article says GetDateTimeFormat returns "1\u6708", "2\u6708", and so on for the format string "MMM" with the use of LOCALE_SABBREVMONTHNAME. > Does this really only affect the lcids 411 and 412? As far as I know, Yes. -- Kazuhiro Fujieda fuji...@acm.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: strftime %b is broken on ja_JP locale
>>> On Wed, 12 May 2010 17:31:18 +0200
>>> Corinna Vinschen said:
> No, that's not broken, even if it seems so. Cygwin fetches the
> localized strings from the underlying OS, not from a Cygwin-specific
> locale database. What you see as results above is what *Windows*
> returns for the full and abbreviated month strings.
Windows has a bug in Japanese and Korean locales. In these
locales, strings reterned by GetLocaleInfoW for
LOCALE_SABBREVMONTHNAME* miss suffixes representing a month.
It should return "5\u6708" in Japanese and "5\c6d4" in
Korea. MSDN in Japanese describes so. It, however, returns "5"
in both locales. In Chenese, it returns "\u4e94\6708" with the
suffix.
We can solve this problem with LOCALE_SMONTHNAME* instead of
LOCALE_SABBREVMONTHNAME* in these locales. I attathed the patch.
--
Kazuhiro Fujieda
fuji...@acm.org
2010-05-14 Kazuhiro Fujieda
* nlsfuncs.cc (__set_lc_time_from_win): Use LOCALE_SMONTHNAME1
instead of LOCALE_SABBREVMONTHNAME1 in Japanese and Korean
locales to get abbreviated month names.
Index: nlsfuncs.cc
===
RCS file: /cvs/src/src/winsup/cygwin/nlsfuncs.cc,v
retrieving revision 1.31
diff -u -r1.31 nlsfuncs.cc
--- nlsfuncs.cc 28 Apr 2010 10:00:24 - 1.31
+++ nlsfuncs.cc 14 May 2010 01:45:05 -
@@ -554,7 +554,11 @@
for (int i = 0; i < 12; ++i)
{
_time_locale->wmon[i] = getlocaleinfo (time,
-LOCALE_SABBREVMONTHNAME1 + i);
+((lcid == 0x0411 ||
+ lcid == 0x0412)
+ ? LOCALE_SMONTHNAME1
+ : LOCALE_SABBREVMONTHNAME1)
+ + i);
_time_locale->mon[i] = charfromwchar (time, wmon[i]);
}
/* month and alt_month */
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Japanese/Chinese language question
>>> On Thu, 21 Jan 2010 14:40:55 +0100 >>> Corinna Vinschen said: > When comparing strings linguistically (strcoll/wcscoll), > > - are Hiragana and Katakana forms of the same character to be > treated as equal or as different? They should be treated as different. > - are half-width and full-width forms of the same CJK character > treated as equal or as different? Different, too. It is difficult to implement the collation algorithm from scratch. I recommend to use LCMapString to generate sort keys. -- Kazuhiro Fujieda -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Please support CP932. (I have problem using subversion with SJIS)
>>> On Tue, 26 Jan 2010 18:28:53 + >>> Andy Koppe said: > Another example is X11, which has its own locale system independent > from Cygwin's. There, "ja_JP" implies eucJP already. This means that > with LANG=ja_JP, xterm uses eucJP, while filenames and programs > currently use the system's ANSI codepage, i.e. CP932 on Japanese > systems. Result: mojibake. It does work correctly with > LANG=ja_JP.SJIS. You should set an appropriate alias in locale.aliases. When the i18n framework in X11 was implemented, The default character encoding in the Japanese locale wasn't necessarily EUC-JP. I remember there was a conditional macro in the source of locale.aliases to adjust it about 20 years ago. The default encoding in the X11 locale should be adjusted to the system locale. It is a natural way of solving this problem. -- Kazuhiro Fujieda -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Please support CP932. (I have problem using subversion with SJIS)
>>> On Tue, 26 Jan 2010 18:06:15 +0100 >>> Corinna Vinschen said: > As for the default charset, now that we get extended NLS > support, there are packages out there which have messages > files for ja_JP encoded in eucJP. These are not shown > correctly if SJIS is the default. The runtime library of NLS convert messages encoded in EUC-JP to the character encoding obtained by nl_langinfo(CODESET). We can properly see Japanese messages. > > There is no difference between SJIS and eucJP on Cygwin > > command line for the sake of the implementation of i18n API. > > If there is any difference, we should correct it. To change > > the default to eucJP isn't adequate. > > I don't understand this one. Andy said `Seems SJIS really isn't suited for Unix command line use.' I said there is no problem, no difference with EUC-JP, and no need to change the default. > The difference is the character encoding which is compatible > with other POSIX systems in the "ja_JP" locale when eucJP is > the default. The default character encoding in the Japanese locale has become UTF-8 in other POSIX systems. In most of all Linux distributions, the default is UTF-8. In OpenSolaris, the default is also UTF-8. On the other hand, the default is SJIS in HP-UX. I believe there is no need to change the default in Cygwin to EUC-JP. -- Kazuhiro Fujieda -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Please support CP932. (I have problem using subversion with SJIS)
>>> On Sun, 24 Jan 2010 17:23:58 +0100 >>> Corinna Vinschen said: > The Unix consensus is apparently EUC-JP and that's what Cygwin 1.7.2 > will use as default as well. If you want UTF-8, just use "ja_JP.UTF-8". To change the default codeset of ja_JP to eucJP is ridiculous. Any users of Japanese version of Windows don't use eucJP as typical euncoding scheme. It will cause unnecessary confusion. There is no difference between SJIS and eucJP on Cygwin command line for the sake of the implementation of i18n API. If there is any difference, we should correct it. To change the default to eucJP isn't adequate. Regards, -- Kazuhiro Fujieda -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rebuild libc.a with MB_CAPABLE defined
>>> On Fri, 11 Jan 2002 12:22:39 +1100 >>> "Robert Collins" <[EMAIL PROTECTED]> said: > At a guess, you'll need to do more than just define MB_CAPABLE. Chances > are, it's disabled because cygwin is not MB_CAPABLE :}. You misunderstand the role of the MB_CAPABLE definition in newlib. The feature enabled by this definition can work on any platform. | AIST Kazuhiro Fujieda <[EMAIL PROTECTED]> | HOKURIKU Center for Information Science o_/ 1990 Japan Advanced Institute of Science and Technology -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Configurable behaviour when remapping cygdrive - please!
>>> On Mon, 03 Dec 2001 16:04:25 +0100 >>> Rune Enggaard Jensen <[EMAIL PROTECTED]> said: > such that all my drives -- including those mapped to network drives -- > were automagically mapped to /c, /d, /w etc. > > I therefore suggest that the behaviour is made configurable, e.g. by an > environment variable, such that the default is the "old" behaviour where > /cygdrive was not "cd-able". Is that possible and acceptable? I hope `mount -c /' exceptionally behave the same as the old one. If we can see all drives on the cygwin root directory, we can't avoid deleting all files with typing `rm -rf /' on the FAT file system. | AIST Kazuhiro Fujieda <[EMAIL PROTECTED]> | HOKURIKU Center for Information Science o_/ 1990 Japan Advanced Institute of Science and Technology -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
