Stringwise comparisons (Inline::C)

[David Mertens]

Now now, let's not be too hasty. Using an undocumented function is
generally not advised, and documenting how to use an undocumented function
is generally frowned upon. As such I see two possibilities here:

1. Use pp_scmp and document it with lots of caveats indicating that the
function is not part of Perl's public API.
2. Ask p5p if pp_scmp (and any other handy UTF8 string functions) can be
added to the public API, as well as how you might go about doing that. The
difference between public and private API for Perl, as far as I know, is
just the decision to document the thing. So this probably means simply
adding the docs for the function. I could help out with this.

Would you like me to email p5p and get their ideas about it?

David

----- Original Message ----- From: "David Oswald"

I wouldn't be calling out to a subroutine implemented in Perl, but
rather, to a Perl internal built-in that does comparisons.
request for suggestions. Max Maischein (Corion) has been helpful,
Corion says: I think you'll need to call the appropriate OP,
which seems (wildly guessing) to be pp_scmp in pp.c.
Or appropriate the code from there.

Yep, if you can't re-structure the code to call a perl sub then, afaik,
you'll have to do as Corion has suggested.
Once I figure it out it actually may make a good addition to the

Inline::C cookbook.

Yes, I think so.
Cheers,
Rob

[David Mertens]

To those not CC'd:

I posted a question on p5p and Nicholas Clark pointed out that sv_cmp looks
like it's *exactly* what you need, both as a general comperator, and as a
means to implement eq, lt, gt, etc. Does this look right?

David

Post by David Mertens
Now now, let's not be too hasty. Using an undocumented function is
generally not advised, and documenting how to use an undocumented function
1. Use pp_scmp and document it with lots of caveats indicating that
the function is not part of Perl's public API.
2. Ask p5p if pp_scmp (and any other handy UTF8 string functions) can
be added to the public API, as well as how you might go about doing that.
The difference between public and private API for Perl, as far as I know,
is just the decision to document the thing. So this probably means simply
adding the docs for the function. I could help out with this.
Would you like me to email p5p and get their ideas about it?
David

----- Original Message ----- From: "David Oswald"

I wouldn't be calling out to a subroutine implemented in Perl, but
rather, to a Perl internal built-in that does comparisons.
request for suggestions. Max Maischein (Corion) has been helpful,
Corion says: I think you'll need to call the appropriate OP,
which seems (wildly guessing) to be pp_scmp in pp.c.
Or appropriate the code from there.

Yep, if you can't re-structure the code to call a perl sub then, afaik,
you'll have to do as Corion has suggested.
Once I figure it out it actually may make a good addition to the

Inline::C cookbook.

Yes, I think so.
Cheers,
Rob

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan

[Steffen Mueller]

Post by David Mertens
Now now, let's not be too hasty. Using an undocumented function is
generally not advised, and documenting how to use an undocumented
1. Use pp_scmp and document it with lots of caveats indicating that the
function is not part of Perl's public API.
2. Ask p5p if pp_scmp (and any other handy UTF8 string functions) can
be added to the public API, as well as how you might go about doing
that. The difference between public and private API for Perl, as far
as I know, is just the decision to document the thing. So this
probably means simply adding the docs for the function. I could help
out with this.

Sorry, part of 2. is wrong. It's not just documentation. On win32, for
example, you can't access symbols that weren't explicitly exported. This
being said, making functions public isn't *technically* difficult, just
brings up considerations about whether the current interface is
something we want to commit to for eternity.

--Steffen