in reply to perlxs + blackbox testing

I've read your post several times but I don't really understand what you are trying to achieve. Please provide more background information about the bigger picture, what you are trying to achieve. Are you writing your own black box testing framework or using one written by someone else? If the latter, which one are you using? Do you want to test some .xs code? Or do you want to use .xs code in your test harness? Where does the .xml file you speak of come from?

Replies are listed 'Best First'.
Re^2: perlxs + blackbox testing
by nostromo (Sexton) on Jun 12, 2006 at 22:31 UTC
    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 :)

      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.