Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:86801 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 83638 invoked from network); 23 Jun 2015 00:57:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Jun 2015 00:57:39 -0000 Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain lerdorf.com designates 209.85.192.49 as permitted sender) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 209.85.192.49 mail-qg0-f49.google.com Received: from [209.85.192.49] ([209.85.192.49:33734] helo=mail-qg0-f49.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 79/9A-07834-10FA8855 for ; Mon, 22 Jun 2015 20:57:38 -0400 Received: by qged89 with SMTP id d89so58861432qge.0 for ; Mon, 22 Jun 2015 17:57:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=BhYXf0AphjxJzn/sKXtd7y+RTKyV8UIths7tDNBTj/o=; b=JmvPOQvSLe9AbtUaxvBTDBxtJwhLVwb1isCXAAjixvafBX2wzQgrU3wpBo6sD68Gam vS0aoWXDtSYP48F9e+Dy0rSjYMAmDs44k3feTno6Q/ZYmkRF24+F40xh0Jlkep7fnT4W cYSiFUG78xFZJxvVhqK6vDJy/tRiKAU3v1VMom5fgijGD03rrVRhWb6RvrkuSiTB8aLw 81UGn/n30z5qa1DaNPnsPc/C6vN78L61Dp63rNrgWLFk1ZcDRwJronoJ8Y+8icSlPTfL W1DNv3qHJQMbcWc0UtgAoWReIWVZvs99aAhPrNfFvWSAemB/SPr+OzxvnYRzsxahFq24 XZmQ== X-Gm-Message-State: ALoCoQlvDTGcE3jrlyyNnxryfa31ZRCh/RUTNsh2Pd5mkFwG/BCnjH+MlKiHSPmq76AoTqhB2jtK X-Received: by 10.55.23.195 with SMTP id 64mr52396791qkx.9.1435021055108; Mon, 22 Jun 2015 17:57:35 -0700 (PDT) Received: from [192.168.101.253] (rrcs-24-136-125-201.nyc.biz.rr.com. [24.136.125.201]) by mx.google.com with ESMTPSA id f196sm690331qhe.49.2015.06.22.17.57.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jun 2015 17:57:33 -0700 (PDT) Message-ID: <5588AEFC.1030409@lerdorf.com> Date: Mon, 22 Jun 2015 20:57:32 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stanislav Malyshev , Dmitry Stogov CC: Bob Weinand , Anatol Belski , Kalle Sommer Nielsen , Nikita Popov , PHP internals References: <5586E5D1.4010901@lerdorf.com> <55870947.4060304@lerdorf.com> <5587334C.2080401@lerdorf.com> <55873676.6050706@gmail.com> <55876B29.90804@lerdorf.com> <55881A72.4090403@lerdorf.com> <5588477E.7050109@lerdorf.com> <5588A02C.4040602@gmail.com> In-Reply-To: <5588A02C.4040602@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="I5rohbCJV8920aX0XTR4bpUCpkwl1b72I" Subject: Re: [PHP-DEV] hasType() for internal function parameters? From: rasmus@lerdorf.com (Rasmus Lerdorf) --I5rohbCJV8920aX0XTR4bpUCpkwl1b72I Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/22/2015 07:54 PM, Stanislav Malyshev wrote: > Hi! >=20 > So I tried to remove the checks for ZEND_ACC_HAS_TYPE_HINTS: > https://github.com/php/php-src/pull/1354 >=20 > Turns out there is a lot of tests that assume function with wrong > arguments throws Error, but ZPP and type checks work differently - ZPP > first checks argument number (and doesn't throw if number is wrong but > instead creates warning), while type checks (that shouldn't really > happen on internals but do) check types first and not check argument nu= mber. >=20 > So I wonder which way is the best to proceed here. Looks like this come= s > from 5.6 where internal function types were verified in executor: > https://github.com/php/php-src/blob/PHP-5.6/Zend/zend_vm_def.h#L1974 >=20 > I'm not sure what to do with it - on one side, I think ZPP should handl= e > it for internal functions, otherwise we're doing the same work twice. O= n > the other side, that would be pretty substantial, even if maybe correct= , > BC break. Should we keep the ZEND_ACC_HAS_TYPE_HINTS type checks and > accept the fact that this way we're checking everything twice, or shoul= d > be clean it up? Is it a BC break against real code though? Fixing tests isn't a big deal. What kind of real code would break by turning calls with the wrong number of args from an error to a warning? I suppose it is a bit late in the game to fix this, but it really does seem very broken to the point where I wonder if we shouldn't just disable reflection on internal functions entirely since the arginfo is so woefully incomplete. Plus the double-checking is super messy. -Rasmus --I5rohbCJV8920aX0XTR4bpUCpkwl1b72I Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlWIrvwACgkQlxayKTuqOuDIZACfe70pWpESxD0YEKPYkOwYtc+/ iHQAn1zASmtlc97FYXiFcIbq+n3hf6Ya =nwz5 -----END PGP SIGNATURE----- --I5rohbCJV8920aX0XTR4bpUCpkwl1b72I--