Patrik Stridvall wrote:
> > Excuse me.... since when did this list turn into the
> > linux-kernel mailing
> > list??? (And I'm gonna add to it.. crap)
>
> I don't think we are there quite yet. :-)
>
hehe.. Yeah.. you are right.. we haven't stooped that low just yet.
[SNIP]
>
> But nevermind, I don't think it is worth wasting
> more time arguing about it...
>
Yeah.
>
> > So... let's see.. how much processing time did we waste going from
> > ASCII->Unicode->UTF8... hmmmm.... 2*N (where N is number of
> > characters).
> > I think I can live with that. Hell, I'd even be willing to
> > live with more
> > than that.
>
> ... so lets instead concentrate on making the currently
> used solution as fast and maintainable as possible.
>
Well, the currently used solution is kind of mixed up... some A->W, some
W->A (not really possible, but done anyway)
>
> As to fast I really don't have any idea except for
> obious ones like using alloca and allocate on the
> stack whenever possible.
>
That's a good idea.
>
> Whatever we decide on almost all conversion functions will
> be the same so it might be benefical to automatically
> generate them.
>
> Perhaps is the spec files something like:
>
> @ convert FooA(str) FooW
> @ stdcall FooW(wtr) FooW
>
> Which will generate
>
> DWORD WINAPI FooA(LPSTR str)
> {
> LPWSTR wstr = HEAP_strdupAtoW(str);
> DWORD dwResult = FooW(wstr);
> HeapFree(wstr);
> return dwResult;
> }
> or whatever we agree is the most correct and/or efficient.
>
Using the spec files may not be the best way to go. I would suggest a
facility strictly for generating conversion functions given a specific set
of parameters. Somewhat like the glue generation now? In fact, maybe we
could make glue more modular and let it handle this stuff too.
>
> One problem is that there are functions that don't use zero
> termininated strings. But perhaps we could mark them somehow
> with * or something, like:
>
> @ convert BarA(str*long) BarW
> @ stdcall BarW(wtr*long) BarW
>
> Which will generate
>
> DWORD WINAPI BarA(LPSTR str, INT length)
> {
> LPWSTR wstr = HEAP_strndupAtoW(str, length);
> DWORD dwResult = FooW(wstr, length);
> HeapFree(wstr);
> return dwResult;
> }
>
> Another problem is that the spec files do not specify
> the return type, but perhaps using DWORD will do.
> It will not work for 64-bit returns, but then we can
> simply forbid auto conversion for them, they are few
> anyway.
>
> Comments?
Well, that is why I would suggest using the glue instead of spec files.
Also, it would be nice if we could just put a "START GLUE" "END GLUE" around
the functions header and maybe come up with a standard naming convention for
the strings that need to be converted, and the lengths of those strings.
Maybe something like:
lpString1, cbString1, lbString2, cbString2 (I *THINK* that is the right
notation for that) Then you could have several string parameters and the
glue would automatically be generated. If the length is not available, then
it simply assumes NULL terminated.
So an example function that is generated would be:
DWORD BarA( LPSTR lpString1, DWORD cbString1 )
{
LPWSTR lpWString1 = HEAP_strndupAtoW(lpString1, cbString1);
DWORD dwResult = BarW(lpWString1, cbString1);
HeapFree(lpWString1);
return dwResult;
}
Which would be generated from a function like:
/* START ATOW */
DWORD BarW( LPSTR lpString1, DWORD cbString1 )
/* END ATOW */
{
/* DO STUFF */
return 0;
}
There is also possibly the issue of converting back from W->A when a
parameter is used to return a string. That is easily taken care of by
adding a "Ret" or something to the variable name.
The only drawback I see to this is that it forces a certain naming
convention on the parameters of all the string functions. Then again, that
may be a good side effect!
-Dave
