New API call for path conversion

[Christopher Faylor]

On Fri, Feb 22, 2008 at 01:19:57PM +0100, Corinna Vinschen wrote:
>Hi,
>
>I'm mulling over a new API call for the path conversion between POSIX
>and Win32 paths.  The old API (cygwin_conv_to_full_win32_path, etc) is
>just not feasible anymore.  They don't allow to request the required
>buffer lengths except for the path_list functions.  They don't allow to
>give the buffer size as parameter but simply assume they are big enough,
>which is quite dangerous.  They don't allow to specify Win32 paths in
>WCHAR.
>
>Win32 paths could come or could be required in two flavours, ANSI or
>WCHAR.  ANSI paths can only be MAX_PATH, while WCHAR paths can be 32K in
>length.  POSIX paths only come in one flavor, which is the current
>codepage (ansi/oem/utf8), and they are theoretically of arbitrary
>length.
>
>I don't think the cygwin_internal interface is the right way to go for
>the new path conversion function.  It's an unintuitive API which should
>only be used for internals mostly by Cygwin utils.
>
>Therefore, as a first cut, I'd propose something along the lines of:
>
>  typedef enum
>    {
>      CCP_WIN_A_TO_POSIX, /* from is char*, to is char*     */
>      CCP_WIN_W_TO_POSIX, /* from is wchar_t*, to is char*  */
>      CCP_POSIX_TO_WIN_A, /* from is char*, to is char*     */
>      CCP_POSIX_TO_WIN_W  /* from is char*, to is wchar_t*  */
>    } cygwin_conv_path_t;
>
>  ssize_t cygwin_conv_path (cygwin_conv_path_t what, const void *from,
>                            void *to, size_t size);

One of the reasons I implemented the cygwin_internal stuff was to reduce
the need to add a new function every time we thought to expose something
non-POSIXy.

Maybe we need the extra argument checking, which is not possible with
cygwin_internal, but did you consider using that and rejected it for
that reason?

cgf