This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: New API call for path conversion
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