Re: cygwin_conv_path POSIX->WIN_A conversion

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Nov 11 09:27, Eric Blake wrote:
> On 11/11/2011 07:46 AM, Corinna Vinschen wrote:
> > 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.
> 
> Yes, that sounds right to me,
> 
> > 
> > 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?
> 
> Precisely for this reason - the only sane reason to convert to native is
> to use the resulting string in native calls.

I'm just worried that this would open a can of worms.

If CCP_POSIX_TO_WIN_A always converts to ANSI/OEM, shouldn't
CCP_WIN_A_TO_POSIX always convert from ANSI/OEM?  However, if the DOS
path has been entered on the Cygwin command line, it will very likely
not be given in the current ANSI/OEM CP, but rather in the Cygwin
charset.

Having said that, I'm wondering if we shouldn't leave the current
conversion alone and rather add new flags to cygwin_conv_path, so that
the *caller* can specify whether the conversion should be done using the
Cygwin or the Windows multibyte charset, or always UTF-8.  Something
along these lines:

  CCP_CYGWIN_CODESET = 0,	<-- Do you have a better idea?
  CCP_WIN32_ANSI_CP  = 0x10,
  CCP_WIN32_OEM_CP   = 0x20,
  CCP_UTF8_CODESET   = 0x30,


Corinna

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