This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
cygwin_conv_path POSIX->WIN_A conversion
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Fri, 11 Nov 2011 15:46:46 +0100
- Subject: cygwin_conv_path POSIX->WIN_A conversion
- Reply-to: cygwin-developers at cygwin dot com
Hi,
today it occured to me that there might be a bug in cygwin_conv_path.
Before I change something to the worse, I thought I should discuss this
first. Here's the problem:
The conversion CCP_POSIX_TO_WIN_A, from POSIX to multibyte native
Windows path, uses the internal sys_wcstombs function to convert the
WCHAR path to multibyte. That means, the destination charset is the
Cygwin charset. So, if Cygwin is operating in default UTF-8, the
resulting Windows path will be in UTF-8 as well.
In most languages, the Windows ANSI charset is NOT UTF-8. So, if the
path gets converted to UTF-8, using the resulting path in a Win32 ANSI
function (CreateFileA or whatever) will fail.
So I was wondering if the CCP_POSIX_TO_WIN_A function shouldn't be
changed so that it converts the pathname to the current ANSI or OEM
charset instead, depending on the value returned by the AreFileApisANSI
function.
I think this would be more correct than converting to the current Cygwin
multibyte charset. The downside is, that this *might* break backward
compatibility. However, if an application converts a Cygwin POSIX path
to a native Windows multibyte path, isn't it always for the sake of
calling a Win32 ANSI function or to submit the path to a native Windows
application?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat