New API call for path conversion

[Christopher Faylor]

Corinna Vinschen wrote:
>Yes, I considered it and I don't think cygwin_internal is feasible.
>It's a sort of swiss-army knife for almost every dubious purpose a
>Cyvwin tool could have, but it's lacking a cleanliness of definition
>which I think is required for a well-defined path conversion API.

So, that would be a "Yes.  I wanted the strict argument checking."

On Fri, Feb 22, 2008 at 12:45:05PM -0800, Brian Dessent wrote:
>I think it's also kind of a PITA to have to pass things in va_args.  You
>don't get any help from the compiler if you goof it, for example. 
>There's also the code efficiency thing, where I see there's a precedent
>for marking up frequently used functions with regparm.  I don't think
>that's possible with varargs, but I could be wrong.

I must not be communicating very clearly.  I thought that by adding
this:

"Maybe we need the extra argument checking, which is not possible with
cygwin_internal"

I was making it clear that there were limitations.  It isn't all that
much different from a "syscall" interface but, then, those aren't
supposed to be used by the end-user programs.  I don't see any
indication that syscall is used directly by anything other than
libc.so in linux-land.

The one limitation of adding a new non-standard function is that we are
stuck with it forever even if we don't get it right the first time,
possibly resulting in a "cygwin_conv_pathEx".  The cygwin_internal
interface means that a program could be written which detects which
version of cygwin it was working with and drop back to the old method if
CYGWIN_CONV_PATH is not available.

Also, who is the expected consumer of this function?  A linux program
doesn't need it.  And it doesn't really matter if it's not 100% clean if
the only real consumers of the function are programs which are entirely
under our control like mount or cygcheck.

I actually don't care if we add a new function but I thought some
neutral examination of the pros and cons was called for.

cgf