in reply to Re: perlxs + blackbox testing
in thread perlxs + blackbox testing

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 :)

Replies are listed 'Best First'.
Re^3: perlxs + blackbox testing
by eyepopslikeamosquito (Archbishop) on Jun 13, 2006 at 00:58 UTC

    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.