This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

New API call for path conversion


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

"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
bytes.

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]