Skip to content

Commit 28873a5

Browse files
committed
perlapi: Consolidate the sv_eq and svstr_eq entries
These functions do the same thing, differing in details. Consolidation makes perlapi more compact, and makes it easier for the reader to see the similarities and differences between the functions. Note that the cryptic sentence "It correctly handles the UTF8 flag" in the sv_streq entry has been removed. It turns out that meant that the code looks at the UTF8ness of each SV, except when 'use bytes' is in effect.
1 parent ef56cbf commit 28873a5

File tree

1 file changed

+27
-35
lines changed

1 file changed

+27
-35
lines changed

sv.c

Lines changed: 27 additions & 35 deletions
Original file line numberDiff line numberDiff line change
@@ -8581,19 +8581,37 @@ S_assert_uft8_cache_coherent(pTHX_ const char *const func, STRLEN from_cache,
85818581

85828582
/*
85838583
=for apidoc sv_eq
8584+
=for apidoc_item sv_streq
85848585
=for apidoc_item sv_eq_flags
8586+
=for apidoc_item sv_streq_flags
85858587

8586-
These each return a boolean indicating whether or not the strings in the two
8587-
SVs are equal. If S<C<'use bytes'>> is in effect, the comparison is
8588-
byte-by-byte; otherwise character-by-character. Each will coerce its args to
8589-
strings if necessary.
8588+
These each return a boolean indicating if the strings in the two SV arguments
8589+
are identical, coercing them to strings if necessary, basically behaving like
8590+
the Perl code S<C<$sv1 eq $sv2>>.
8591+
8592+
A NULL SV is treated as C<undef>.
8593+
8594+
The comparison is character-by-character, based on the UTF8ness of each SV,
8595+
unless S<C<use bytes>> is in effect, in which case the comparison is
8596+
byte-by-byte.
8597+
8598+
C<sv_eq> and C<sv_streq> always perform 'get' magic.
8599+
C<sv_eq_flags> and C<sv_streq_flags> perform 'get' magic only if C<flags> has
8600+
the C<SV_GMAGIC> bit set.
85908601

8591-
They differ only in that C<sv_eq> always processes get magic, while
8592-
C<sv_eq_flags> processes get magic only when the C<flags> parameter has the
8593-
C<SV_GMAGIC> bit set.
8602+
C<sv_eq> and C<sv_eq_flags> do not check for overloading, always using regular
8603+
string comparison.
85948604

8595-
These functions do not handle operator overloading. For versions that do,
8596-
see instead C<L</sv_streq>> or C<L</sv_streq_flags>>.
8605+
C<sv_streq> always checks for, and if present, handles C<eq> overloading. If
8606+
not present, regular string comparison is used instead.
8607+
8608+
C<sv_streq_flags> normally checks for, and if present, handles C<eq>
8609+
overloading, but setting the C<SV_SKIP_OVERLOAD> bit set in C<flags> causes it
8610+
to use regular string comparison.
8611+
8612+
Otherwise, the functions behave identically.
8613+
8614+
=for apidoc Amnh||SV_SKIP_OVERLOAD
85978615

85988616
=cut
85998617
*/
@@ -8649,32 +8667,6 @@ Perl_sv_eq_flags(pTHX_ SV *sv1, SV *sv2, const U32 flags)
86498667
return 0;
86508668
}
86518669

8652-
/*
8653-
=for apidoc sv_streq
8654-
=for apidoc_item sv_streq_flags
8655-
8656-
These each return a boolean indicating whether the strings in the two SVs are
8657-
identical.
8658-
8659-
C<sv_streq_flags> is the more general form, having a C<flags> argument that
8660-
affects its behavior in two ways. It coerces its args to strings if necessary,
8661-
treating a C<NULL> argument as C<undef>. It correctly handles the UTF8 flag.
8662-
8663-
If C<flags> has the C<SV_GMAGIC> bit set, 'get' magic will be handled.
8664-
8665-
If flags does not have the C<SV_SKIP_OVERLOAD> bit set, an attempt to use
8666-
C<eq> overloading will be made. If such overloading does not exist or the
8667-
flag is set, then regular string comparison will be used instead.
8668-
8669-
C<sv_streq> merely calls C<sv_streq_flags> with C<flags> set to just
8670-
C<SV_GMAGIC>. This function basically behaves like the Perl code
8671-
S<C<$sv1 eq $sv2>>.
8672-
8673-
=for apidoc Amnh||SV_SKIP_OVERLOAD
8674-
8675-
=cut
8676-
*/
8677-
86788670
bool
86798671
Perl_sv_streq_flags(pTHX_ SV *sv1, SV *sv2, const U32 flags)
86808672
{

0 commit comments

Comments
 (0)