Patrik Stridvall ps@leissner.se writes:
It would be nice if you commented on what you think about my spec2pm script for automatically generating Perl modules for calling the Windows API.
Sure; I was looking into integrating it, but found some problems. I agree generating modules automatically is a good idea; the main problem right now is that we cannot get the return type of the functions, and this breaks functions returning a string.
Yes, that is true. But it was better than nothing. Many (most?) functions, like strcpy, returns a pointer returns a pointer to one of the arguments anyway so there is little need to actually access it in the test.
But of course it should be solved.
I see two way of solving this. 1. Extend the spec files to include this information. 2. Have an exception table like the one in make_symbols
Fortunately winetest uses Perl, not Python. If we did we would have an additional problem, namely that strings in Python are read-only and passing it as an [out] or [in/out] string would break Python semantics.
Perhaps you remember me wanting to extend the .spec files with information whether a ptr/str was [in], [out], [in/out]
In Perl all string, like in C, are read/write, so I think we can live without it.
But return type would be nice to have in the .spec files.
I think I can quite easily can adapt winapi_fixup to do this automatically for all spec files if you wish.
You have to decide on the syntax though.
Also, I'm not sure that you are trying to do: The files generated by make_symbols are quite useless, they just contain a lot of LOCAL variables.
They seem to work just fine for me, but I'm no Perl expert, so if you think your approach is better I'll do it that way.
Hmm. I guess that is because you usually write Perl application without "use strict". IIRC variables defaults to global without it and to _local_ with it.
In any case, my test with "use strict" didn't work.
Anyway, my way is the offical way that is recommended in the Perl documentation and work both with and without "use strict".
As a special bonus you can now do things like:
use winerror qw(ERROR_CALL_NOT_IMPLEMENTED);
without having to, like C, include everything.
Patrik Stridvall ps@leissner.se writes:
Perhaps you remember me wanting to extend the .spec files with information whether a ptr/str was [in], [out], [in/out]
In Perl all string, like in C, are read/write, so I think we can live without it.
But return type would be nice to have in the .spec files.
We discussed this before; I agree it would be nice to have a lot more information like in/out, return values, more detailed types, etc. But I don't think the spec file is the right place for that. I'd like the spec to remain simple (and in fact to even be simplified) and to contain only the minimal info needed to generate a correct dll. All the rest that's used for debug/testing should be moved somewhere else, preferably directly into the code.