Before getting into details, what is the over-riding reason for mucking with the existing 'int main()' interface?

DrWhy writes:

"This code is mostly in one big long 'int main(int argc, char **argv)'. I just turned this into a 'regular' function and modified the argument list to contain slots for all the important formerly-command line options. Then I'm writing serveral different XSUBs that will call this with different arguments representing the major different modes of functionality provided."

I don't know why you need separate XSUBs. Couldn't you have pure perl subs for the different "modes" and have those call a single XS interface?

"These XSUBs need to return differnt data depending on whether they are called in scalar or array context, so they have PPCODE sections that manipulate the stack directly. That somewhat lengthy code that sets up the return values on the stack is identical in all the XSUBs. "

I have not problem with duplicating code in XSUBs, this usually happens. I don't see where you're losing anything.

"So I'm wondering, why not just have the central function (which is not going to be an XSUB itself -- it's in the .xs file above the MODULE line) do the stack manipulation itself. "

You got a little ahead of me here. The XSUBs, once run through xsubpp do more that just stack manipulation. ( This , I think, is the breeze to your house of cards. Nevertheless, indulge me while I continue... ) Otherwise I think that you're talking about writing a native perl extension. While there is no technical reason why you couldn't do this I think there are practical reasons why you shouldn't do this.

For maintainability I would want the new code to be in perl as far as possible, unless it meant standing on my head. This to minimize the amount of time spent thinking in both C and perl. I would also want to keep code-that-someone-else wrote untouched. If you didn't touch it then you can't be the one that broke it.

Yes, it would have been nice if the author had provided multiple interfaces, but he didn't. Trying to patch the code so that it has them seem to be going in the wrong direction. "Sewing new cloth on old clothes." In addition the new code would be neither C++ nor perl. It would no longer be testable as a standalone.

The effort spent on modifing the existing C interface would be better spent defining a new, testable, perl interface. Then backing in functions written in pure perl.

And finaly, refering to perlxs:

Of course, one could write such glue code directly in C. However, this would be a tedious task, especially if one needs to write glue for multiple C functions, and/or one is not familiar enough with the Perl stack discipline and other such arcana.

While you may be familiar with "such arcane" the poor guy maintaining the code after you wont be. Have pitty.

Nevertheless, Thank you for your question. It really got the gray matter churning. I hope I wasn't to harsh. I also appologize if I mis-understood what you were trying to do.