Re: cygwin_conv_path POSIX->WIN_A conversion

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

On Nov 18 10:57, Andy Koppe wrote:
> On 14 November 2011 10: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?
> 
> Yes, I think so.
> 
> > 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.
> 
> A program that assumes something other than the Cygwin charset for
> command line arguments is buggy.
> 
> Having said that, I assume the concern here is about pre-1.7 programs,
> where assuming the ANSI/OEM codepage for command line arguments would
> have been reasonable. However, such programs won't actually be using
> CCP_POSIX_TO_WIN_A and CCP_WIN_A_TO_POSIX, since those were only
> introduced with 1.7. Instead, they'll be using the deprecated
> cygwin_conv_to_posix_path() and its relatives.
> 
> I understand those currently do the same as their cygwin_conv_path_t
> equivalents, but that doesn't have to be that way. So how about if
> those legacy functions keep current behaviour in an attempt to
> maximise backward compatibility, 

But to maximize backward compatibility, they should use ANSI/OEM,
too, shouldn't they?  It depends on the point from where you define
backward compatibility in this case.

>  whereas CCP_POSIX_TO_WIN_A  and
> CCP_WIN_A_TO_POSIX are changed to do what they say they do?
> 
> 
> > 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,
> 
> It's a possibility, but I find it a bit confusing and unnecessary.
> Windows paths can already be converted to/from any required codeset by
> going via the wide (i.e. WIN_W) version of the path and converting
> with the appropriate choice of
> MultiByteToWideChar/WideCharToMultiByte/mbstowcs/wcstombs.

Along the lines of what Daniel wrote you're right, I guess.  It's
a lot easier to implement only one choice, too.


Corinna

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