develooper Front page | perl.perl5.porters | Postings from August 2013

Re: S_is_safe_syscall and SvOK (Re: [perl.git] branch blead, updated. v5.19.3-130-gc8028aa)

Thread Previous | Thread Next
From:
Reini Urban
Date:
August 29, 2013 20:42
Subject:
Re: S_is_safe_syscall and SvOK (Re: [perl.git] branch blead, updated. v5.19.3-130-gc8028aa)
Message ID:
CAHiT=DEEmw99xP+bkYBEMyeH90g8Y_GkULYQKjdXAmjjnSTsyQ@mail.gmail.com
On Thu, Aug 29, 2013 at 11:30 AM, Craig A. Berry <craigberry@mac.com> wrote:
> In article <E1VDoFI-0004Ce-AO@camel.ams6.corp.booking.com>,
>  tony@develop-help.com ("Tony Cook") wrote:
>
>> In perl.git, the branch blead has been updated
>>
>> <http://perl5.git.perl.org/perl.git/commitdiff/c8028aa68dedb3c7683abb0bcf0fdba
>> 782a1190e?hp=5f7c1602dfa694a4a6761e9e4fc077ce794f7ff0>
>
>
>> +/*
>> +=for apidoc AiR|bool|is_safe_syscall|SV *pv|const char *what|const char
>> *op_name
>> +
>> +Test that the given C<pv> doesn't contain any internal NUL characters.
>> +If it does, set C<errno> to ENOENT, optionally warn, and return FALSE.
>> +
>> +Return TRUE if the name is safe.
>> +
>> +Used by the IS_SAFE_SYSCALL() macro.
>> +
>> +=cut
>> +*/
>> +
>> +PERL_STATIC_INLINE bool
>> +S_is_safe_syscall(pTHX_ SV *pv, const char *what, const char *op_name) {
>> +    /* While the Windows CE API provides only UCS-16 (or UTF-16) APIs
>> +     * perl itself uses xce*() functions which accept 8-bit strings.
>> +     */
>> +
>> +    PERL_ARGS_ASSERT_IS_SAFE_SYSCALL;
>> +
>> +    if (SvPOK(pv) && SvCUR(pv) >= 1) {
>> +        char *p = SvPVX(pv);
>> +        char *null_at;
>> +        if (UNLIKELY((null_at = (char *)memchr(p, 0, SvCUR(pv)-1)) != NULL))
>> {
>> +                SETERRNO(ENOENT, LIB_INVARG);
>> +                if (ckWARN(WARN_SYSCALLS)) {
>> +                    Perl_ck_warner(aTHX_ packWARN(WARN_SYSCALLS),
>> +                                   "Invalid \\0 character in %s for %s:
>> %s\\0%s",
>> +                                   what, op_name, p, null_at+1);
>> +                }
>> +                return FALSE;
>> +        }
>> +    }
>> +
>> +    return TRUE;
>> +}
>
> If I'm reading this right, if SvOK(pv) is false then the function
> returns true.
> Which sounds like we're saying it's safe to pass an
> undefined SV (or the null pointer it contains) to a syscall.  Is that
> because we expect cases where a null pointer is invalid to already be
> handled separately?

The cases where this macro is applied throughout the code already asserted that
the sv is a valid PV passed to a syscall, it cannot be PL_sv_undef.
If it is it will blow up in the SvPVX(sv) call to the syscall, and has
nothing to
do with this check.
-- 
Reini Urban
http://cpanel.net/   http://www.perl-compiler.org/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About