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 ClarkThread Previous | Thread Next