New API call for path conversion

Corinna Vinschen
Fri Feb 22 12:20:00 GMT 2008


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

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

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);

"size" is the size of the "to" buffer in bytes (not in characters).

If size is 0, cygwin_conv_path returns the required buffer size in

Otherwise, it returns 0 on success, or -1 on error and errno is set to
one of the below values:

  EINVAL        what has an invalid value.
  EFAULT        from or to point into nirvana.
  ENAMETOOLONG  the resulting path is longer than 32K, or, in case
                of what == CCP_POSIX_TO_WIN_A, longer than MAX_PATH.
  ENOSPC        size is less than required for the conversion.

This doesn't cover path list conversions so far, of course.  They could
probably just use equivalent cygwin_conv_path_t values.

Maybe we should add another function which always allocates the required
buffer, along these lines:

  void *cygwin_create_path (cygwin_conv_path_t what,
                            const void *from);

Return value is the pointer to the converted path or NULL with errno set
as above.

The old conversion functions should continue to work.  They should just
be guarded against resulting paths longer than MAX_PATH and exit with an
api_fatal error if the resulting path would be longer.  This could help to
convert applications using the old API to the new one.

Does that sound reasonable?


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

More information about the Cygwin-developers mailing list