Inline C has no tests for prototypes for generated XSubs.

[daoswald]

PROTOTYPES: DISABLE appears to be the default for Inline-generated xsubs. There appears to be no way to change that, and we haven't provided a means for authors to specify prototypes for a specific Inline-generated subroutine anyway.

Proposal:

use Inline Config => PROTOTYPE => { subname => 'perl prototype', another_subname, => 'some other prototype' };

Internally this should invert the "PROTOTYPES: DISABLED" to "ENABLED". It should also apply the correct prototype(s) to the subname(s) listed. It should further override "ENABLED" for any subs not listed, setting those that are unlisted specifically to "DISABLED".

Fixing this in Inline::C would allow Inline::CPP to benefit from the same feature.

[sisyphus]

I did stick some rudimentary support for this beginning 0.53_01. t/25proto.t tests (and the proto*.p files) test some aspects of the behaviour. According to the docs:

PROTOTYPE Corresponds to the XS keyword 'PROTOTYPE'. See the perlxs documentation for both 'PROTOTYPES' and 'PROTOTYPE'. As an example, the following will set the PROTOTYPE of the 'foo' function to '$', and disable prototyping for the 'bar' function.

    use Inline C => Config => PROTOTYPE => {foo => '$', bar => 'DISABLE'}

PROTOTYPES Corresponds to the XS keyword 'PROTOTYPES'. Can take only values of 'ENABLE' or 'DISABLE'. (Contrary to XS, default value is 'DISABLE'). See the perlxs documentation for both 'PROTOTYPES' and 'PROTOTYPE'.

    use Inline C => Config => PROTOTYPES => 'ENABLE';

I'm sure it could do with some enhancements, though I think it provides good flexibility as regards switching between ENABLE/DISABLE even within the same XS file. If the chosen approach is fundamentally flawed then now is certainly the time to change it.

Cheers, Rob

[daoswald]

Looks like you've got it, and my 'issue' was outdated before I ever posted it. On Jul 17, 2014 6:49 AM, "sisyphus" notifications@github.com wrote:

I did stick some rudimentary support for this beginning 0.53_01. t/25proto.t tests (and the proto*.p files) test some aspects of the behaviour. According to the docs:

PROTOTYPE Corresponds to the XS keyword 'PROTOTYPE'. See the perlxs documentation for both 'PROTOTYPES' and 'PROTOTYPE'. As an example, the following will set the PROTOTYPE of the 'foo' function to '$', and disable prototyping for the 'bar' function.

use Inline C => Config => PROTOTYPE => {foo => '$', bar => 'DISABLE'}

PROTOTYPES Corresponds to the XS keyword 'PROTOTYPES'. Can take only values of 'ENABLE' or 'DISABLE'. (Contrary to XS, default value is 'DISABLE'). See the perlxs documentation for both 'PROTOTYPES' and 'PROTOTYPE'.

use Inline C => Config => PROTOTYPES => 'ENABLE';

I'm sure it could do with some enhancements, though I think it provides good flexibility as regards switching between ENABLE/DISABLE even within the same XS file. If the chosen approach is fundamentally flawed then now is certainly the time to change it.

Cheers, Rob

— Reply to this email directly or view it on GitHub https://github.com/ingydotnet/inline-c-pm/issues/9#issuecomment-49301881 .

[sisyphus]

I remember we discussed this issue a while back, so I stuck it in. (The polite thing would have been for me to draw your attention to that.) It would be good if there were some actual working scripts kicking about that gave this feature a decent workout. I don't put it to use at all.

[daoswald]

I'm going to close this now. Someday I should pull one function out of List::BinarySearch::XS, convert it to Inline::C, and put it in examples/prototypes.pl, within the Inline::C distribution. But that's a different concern. The feature is implemented.

[mohawk2]

Surely we can just add to test 25 a snippet of C with a prototype, and then on perl-side (if the $] is right), test its prototype()?