Front page | perl.perl5.porters |
Postings from August 2021
On Fri, Aug 20, 2021 at 11:55:00AM +0100, Paul "LeoNerd" Evans wrote:
> The behaviour in perl's `eq` operator is exposed to XS authors via
>
> BOOL sv_eq(SV *left, SV *right);
>
> Nice and simple.
That's not quite accurate. Overloaded comparison is handled one level out:
PP(pp_seq)
{
dSP;
tryAMAGICbin_MG(seq_amg, 0);
{
dPOPTOPssrl;
SETs(boolSV(sv_eq_flags(left, right, 0)));
RETURN;
}
}
> As far as I can tell there isn't an equivalent numerical one, for `==`.
> I've had to write myself a 47 line wrapper function by copying out the
> logic from Perl's (non-API-exposed) Perl_do_ncmp() function.
>
> I propose adding an API function
>
> BOOL sv_numeq(SV *left, SV *right);
>
> to cover this.
That's probably sane, but:
On Fri, Aug 20, 2021 at 01:26:37PM +0100, Paul "LeoNerd" Evans wrote:
> On Fri, 20 Aug 2021 11:55:00 +0100
> "Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:
>
> > As far as I can tell there isn't an equivalent numerical one, for
> > `==`. I've had to write myself a 47 line wrapper function by copying
> > out the logic from Perl's (non-API-exposed) Perl_do_ncmp() function.
>
> For further context:
>
> https://metacpan.org/release/PEVANS/Syntax-Keyword-Match-0.07/source/lib/Syntax/Keyword/Match.xs#L35-85
The documentation of sv_eq is:
=for apidoc sv_eq
Returns a boolean indicating whether the strings in the two SVs are
identical. Is UTF-8 and S<C<'use bytes'>> aware, handles get magic, and will
coerce its args to strings if necessary.
The code in do_ncmp() doesn't handle overloading, and also is dealing in
SvIVX() etc rather than SvIV(). So I don't think that it's totally the
right implementation to expose, on the assumption that
1) What sv_eq_flags() is a better API
2) And if it isn't, it would be better if we exposed consistent API
Nicholas Clark
Thread Previous
|
Thread Next