New API call for path conversion

Corinna Vinschen corinna-cygwin@cygwin.com
Fri Feb 22 18:02:00 GMT 2008


On Feb 22 06:55, Eric Blake wrote:
> According to Corinna Vinschen on 2/22/2008 5:19 AM:
> I like the name, and the idea of an enum for making a single entry point 
> more flexible than a multitude of converters.  Shouldn't you use restrict 
> on the two pointers, to guarantee non-overlap between the buffers and for 
> potentially better code generation?  (That opens a different can of worms - 
> cygwin could certainly use restrict in a lot more places).

I'm not sure about this restrict stuff.  Since we don't use it at
all in Cygwin, it's a bit strange to use it now.  I agree with the
can of worms metaphor.

>> "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.
>
> Including or excluding the trailing NUL?  I'd argue for excluding.

Oh, hmm, I would have argued for including the trailing 0.  It's simply
safer.  We're talking about a buffer size, not about a string length.
After all, the buffer size in bytes for a wchar_t string is quite
different from the number of characters.  In the wchar_t case you also
have the additional potential point of failure

  size = cygwin_conv_path();
  buf = malloc (size + 1/*!!!*/);
  cygwin_conv_path(buf);  /* boof */

That's why I talk about buffer size.  It's not snprintf semantic.

> nonnegative result means success, -1 on error (I guess that means 
> converting "" should set errno to ENOENT and return -1, rather than 
> returning 0?).

Oh, yes, that's right.  ENOENT candidates are also long Windows paths
not starting with \\?\ etc.

>>   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.
>
> Now that MAX_PATH is 4k, don't you mean longer than Window's pathetic 256 
> byte limit?

You got that wrong.  PATH_MAX is 4K.  MAX_PATH is the Windows constant
for short path names up to 260 characters.  This value will never
change.  Win32 ANSI paths are always restricted to MAX_PATH and Cygwin
can do nothing about that.  There are a handful of Win32 functions which
are able to return ANSI paths of arbitrary length, for instance
GetModuleFileName, but they are not usable as input to other Win32
functions.

>>   ENOSPC        size is less than required for the conversion.
>
> Hmm - based on my above argument (snprintf-like semantics of always 
> returning the necessary size and a truncated conversion), you'd never fail 
> with ENOSPC.  On the other hand, a truncated path is potentially dangerous, 
> as it can lead to operations on the wrong file if the code did not check 
> for the result being larger than the input size.  So your idea of returning 
> -1 and ENOSPC on insufficient non-zero buffer size is better after all.  
> And maybe for safety, we should try to set the output buffer to "" on 
> failure

That's ok.  It's not really important for the API definition but
it might be a good idea to do that.  OTOH, somebody could argue that
the output buffer shouldn't be changed if the function returns with
an error...

> However, I'd still like the success result to be the size of the 
> conversion in bytes, rather than 0, since it may be smaller than the size 
> of my input buffer, and since it avoids me having to revisit the buffer 
> contents with strlen to find something that the converter already knew.

That's ok, but the size should rather include the terminating 0 as
outlined above, IMHO.

>> Return value is the pointer to the converted path or NULL with errno set
>> as above.
>
> or to ENOMEM if malloc failed.

Yep.

>> The old conversion functions should continue to work.  They should just
>> be guarded against resulting paths longer than MAX_PATH 
>
> MAX_PATH, or 256?

See above ;)

Thanks for your input!


Corinna

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