ok, i'll retry to explain my basic problem. i hope it brings
some light into my ideas :)
i want to write a blackbox-tester in perl. this means that the object to be analyzed is a linux shared-library - the ".so"-files. they provide various functions one can call by including this library. in my case the exact working principle of a function is not clear to the tester. instead, it gets input from a .xml-file that describes what values can be fed to a certain function, what name this function has, and what _might_ be an expected output. so, for example, a library, let's call it hello_world(.so) provides a function called "hello", that takes an integer as argument, where this argument defines how often the string "hello world\n" shall be printed to STDOUT. thus my blackbox-tester would read (theoretically up to now): "func: hello; arg: int; ret: string" and run a test on the function "hello" provided by hello_world.so handing over an integer. the given output from this function can then later be processed for further investigation, but is expected to be a string in this case.
pretty long, but i hope this makes it a bit more clear to you. chromatics hint taking a closer look at P5NCI was very very helpful. P5NCI seems to be just what i need and it does it's job much better than DynaLoader oder perlxs. i already tried it on my sample library and it worked perfectly :) | [reply] |
OK, thanks, much clearer now. Yep, P5NCI is what you want.
Notice that P5NCI is currently limited to C functions
taking up to four arguments -- which is why it took
so long to build, since p5NCI.xs
contains over 100,000 lines of code covering all
type combinations of up to 4 arguments.
The only way to avoid this brute-force approach is
to manipulate the call stack with non-portable assembler,
which I assume is how it's done by
Win32::API
and libffi (now maintained as part of GCC).
See also Win32::API equivalent for Unix and Re: Disputation of g0n on the power and efficacy of XS.
| [reply] |