New API call for path conversion

Christopher Faylor
Fri Feb 22 21:36:00 GMT 2008

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

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

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


More information about the Cygwin-developers mailing list