This is the mail archive of the cygwin-developers mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

cygwin_conv_path POSIX->WIN_A conversion


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

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


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]