This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: cygwin_conv_path POSIX->WIN_A conversion
On Nov 14 11:33, Corinna Vinschen wrote:
> 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,
Does nobody have an opinion here?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat