Re: [PHP-DEV] libpcre version requirements
On 11.08.2015 at 22:46, Anatol Belski wrote: -Original Message- From: Christoph Becker [mailto:cmbecke...@gmx.de] Sent: Tuesday, August 11, 2015 6:46 PM To: PHP internals internals@lists.php.net Subject: [PHP-DEV] libpcre version requirements What is the minimum libpcre version that is supported as external libpcre for ext/pcre? According to config0.m4 it is PCRE 6.6 (2006-02-06), but is this still valid and do we really have to support such old versions? I'm asking because of bug #70232 which can easily be fixed, but that requires PCRE 8.00 (2009-10-19). If we have to support older PCRE versions, we'd probably need a fallback to the current behavior (which would obviously keep the bug). IMHO the dependent version shouldn't be raised. But not sure what is meant by implementing for lower versions. Probably if it's missing in PCRE, so is it. We should avoid reimplementing it, but just doing what is done in the other exts, fe curl. Users can choose to upgrade the dependency or to miss the feature. So a compile time PCRE version check were enough. The difference to cURL, AIUI, is that this is not about an option that can be supplied by the user (and checked for existance in user-land code, by e.g. defined(CURLOPT_*)), but rather something that is for internal use only, and therefore much less obvious for user-land developers. IOW: fixing bug #70232 is trivial, but the bug would still persist for libpcre 7.2 - 7.9. If that's not regarded as a general issue, I'm fine with it. Still, I would suggest to raise the libpcre requirements to PCRE = 8.0 for PHP 7.0 or at least for PHP 7.1. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack
Hi all,
On Mon, Aug 10, 2015 at 6:57 PM, Craig Francis cr...@craigfrancis.co.uk
wrote:
I have been reading your conversation with great interest.
But I would urge you to see Matts suggestion as a simple addition to the
language (it's simpler than my suggestion), where his RFC seems to have
already addressed your concerns (and he seems to have a working proof of
concept).
Personally I would like to see any one of these solutions being added to
the core language, as there are far too many PHP programmers making
ridiculous mistakes that the core language can be (and should be)
identifying. That said, I am still biased to my suggestion, which also
tries to consider other problems like XSS.
But anyway...
Take the code below, it is obviously wrong, but it executes without any
complaints, and unless someone is checking every line of code that is
written (note: PHP is doing so already), then the developer will just move
on without thinking anything is wrong:
http://php.net/manual/en/pdo.exec.php
$dbh-exec(DELETE FROM fruit WHERE colour = '{$_GET['colour']}');
This is awful... It seems someone already fixed the doc.
Over the years I've heard many people say things like use static
analysis or prepared statements fix everything, but I don't think these
are enough.
I fully agree prepared statements fix everything is simply wrong.
To be secure truly, secure API must split command and all others completely
_and_ command part must be programmer supplied constant/static/validated
string.
(i.e. Perfectly secure API must prohibit command injections at all)
Prepared statement does not satisfy both conditions.
Many APIs, that are considered secure API, are not perfectly secure
because command part must be programmer supplied constant/static/validated
string condition is not checked. It's left to developers.
e.g. execl/execv splits command and arguments, only single command is
allowed,
but if command is user parameter, it cannot be secure.
You only have to skim read things like the second comment (with 27 up
votes) on the PDO prepare page to see that these problems are happening all
the time:
http://php.net/manual/en/pdo.prepare.php#111458
SELECT * FROM users WHERE $search=:email
So accept that education alone is not enough, and that the basic building
blocks like prepared statements or ORMs are not enough, and look at these
proposals and see how they will make the language better... because I can
assure you, having a simple tainting system that can be switched on to show
your mistakes, is considerably better than what we have today (i.e.
nothing... or maybe using some half baked / expensive static analysis tool).
Or are you scared that this will highlight the mistakes you have made in
your own (probably over-complicated) code? as this is why I want this
feature, because I know I have made mistakes, and with OOP, it is very easy
todo so (abstractions like ORMs have a tendency to allow for these mistakes
to creep in extremely easily).
I don't think the proposal is useless nor ineffective.
Taint system is nice to have, but the proposal does not seem preferable
resolution.
Don't get me wrong. I agree with your discussion overall.
I tend to dislike all or nothing choice for security related
issues especially, nonetheless
nothing is my choice this time...
Regards,
P.S. There are many outputs other than SQL. Context aware automatic
escaping/use of
secure API/validation for various outputs would be nice to have. This would
be new API
and wouldn't help users shooting their own foot, though. I don't have
concrete idea now,
but PHP may have features help it.
--
Yasuo Ohgaki
yohg...@ohgaki.net
[PHP-DEV] Re: com php-src: Export argument type checking functions:Zend/zend_execute.c Zend/zend_execute.h
Hi Dmitry, On 11.08.2015 at 18:11, Dmitry Stogov wrote: Commit:a658465ef2ff7e47fc93b4988e4caa6f42d4ae49 Author:Dmitry Stogov dmi...@zend.com Tue, 11 Aug 2015 19:11:21 +0300 Parents: 5b017ba8be49fc0a07d4e5e1e43f1d0e635f336f Branches: master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=a658465ef2ff7e47fc93b4988e4caa6f42d4ae49 Log: Export argument type checking functions Changed paths: M Zend/zend_execute.c M Zend/zend_execute.h It seems that this commit breaks building on Windows: c:\users\cmb\php\sdk\phpdev\vc14\x64\php-src\zend\zend_execute.h(52): error C2059: syntax error: 'type' (compiling source file sapi\cli\php_cli_process_title.c) etc. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Benchmark Results for PHP Master 2015-08-11
Results for project php-src-nightly, build date 2015-08-11 05:00:00+03:00 commit: 9f37f5f344076a696be607c829a7e17873a6dfe5 revision_date:2015-08-11 01:43:40+02:00 environment: Haswell-EP cpu: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB mem: 128 GB os: CentOS 7.1 kernel: Linux 3.10.0-229.4.2.el7.x86_64 Note: Baseline results were generated using release php-7.0.0beta1, with hash ad8a73dd55c087de465ad80e8715611693bb1460 from 2015-07-07 16:02:13+00:00 benchmark executable unit change since change since yesterday php-7.0.0beta1 Wordpress 4.2.2 cgi -T1 php opc=on fps 0.59% 0.78% Drupal 7.36 cgi -T1 php opc=on fps 0.08% 1.80% MediaWiki 1.23.9 cgi -T5000 php opc=on fps 0.51% 1.38% bench.php cgi -T1 php opc=on sec 1.43% -3.67% micro_bench.php cgi -T1 php opc=on sec 2.95% 3.98% mandelbrot.php cgi -T1 php opc=on sec 4.29% -0.22% Our lab does a nightly source pull and build of the PHP project and measures performance changes against the previous stable version and the previous nightly measurement. This is provided as a service to the community so that quality issues with current hardware can be identified quickly. Intel technologies' features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document. Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade. This document may contain information on products, services and/or processes in development. Contact your Intel representative to obtain the latest forecast, schedule, specifications and roadmaps. The products and services described may contain defects or errors known as errata which may cause deviations from published specifications. Current characterized errata are available on request. (C) 2015 Intel Corporation.
Re: [PHP-DEV] LDAP module requirements?
On 2015-08-11 00:36, Rainer Jung wrote:
The current problems should be mostly around the above four compiler warnings.
I can test any patches you want me to test.
Can you test including the attached file in ext/ldap/ldap.c, and not defining
HAVE_3ARG_SETREBINDPROC and LDAP_CONTROL_PAGEDRESULTS ?
void ldap_memvfree( void **value )
{
ldap_value_free(value);
}
int
ldap_initialize( LDAP **ldp, LDAP_CONST char *url )
{
*ldp = ldap_open(url);
return LDAP_SUCCESS;
}
signature.asc
Description: OpenPGP digital signature
[PHP-DEV] libpcre version requirements
Hi all! What is the minimum libpcre version that is supported as external libpcre for ext/pcre? According to config0.m4 it is PCRE 6.6 (2006-02-06), but is this still valid and do we really have to support such old versions? I'm asking because of bug #70232 which can easily be fixed, but that requires PCRE 8.00 (2009-10-19). If we have to support older PCRE versions, we'd probably need a fallback to the current behavior (which would obviously keep the bug). -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libpcre version requirements
On 11 August 2015 at 09:46, Christoph Becker cmbecke...@gmx.de wrote: What is the minimum libpcre version that is supported as external libpcre for ext/pcre? According to config0.m4 it is PCRE 6.6 (2006-02-06), but is this still valid and do we really have to support such old versions? CentOS/RHEL 5 provides libpcre 6.6, which is probably where that specific minimum version comes from. Someone out there is probably still building packages that rely on this. I'm asking because of bug #70232 which can easily be fixed, but that requires PCRE 8.00 (2009-10-19). If we have to support older PCRE versions, we'd probably need a fallback to the current behavior (which would obviously keep the bug). I guess the question's really whether we should still support an _external_ libpcre that old, since we bundle much newer versions. I think the argument against changing it has always been that it works and we didn't need anything newer, but if we have a reason now then that doesn't really hold. One problem is that I don't think we can really change the minimum requirement on a stable branch, so for 5.5 and 5.6 we're going to have to implement something that works with older versions regardless, but I'd be for bumping the minimum version requirement for 7.0 if it makes the code cleaner (on that branch, at least) moving forward. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Parameter parsing for zval type?
Hi Dmitry, all, Help me understand this. :-) It's been more puzzling to me recently since just coming to the part of optimizing traditional ZPP (sharing part with FAST_ZPP...). With the FAST_ZPP inline macros, why is there a Z_PARAM_ZVAL and Z_PARAM_ZVAL_DEREF? It seems the zpp 'z' specifier is always like ZVAL_DEREF, right? So Z_PARAM_ZVAL has no equivalent in traditional zpp. At the very least, this would seem to suggest a difference in behavior/functionality. But I haven't found any (or bug reports, if tests didn't cover something). At first I assumed Z_PARAM_ZVAL would keep IS_REFERENCE types, since it doesn't do ZVAL_DEREF(), but this obviously isn't happening with references. (It seems they're getting DEREF()'d in VM when sending params, I guess...?) So is there never a need for ZVAL_DEREF() when parsing params? Shouldn't have 2 FAST_ZPP ZVAL types? Otherwise, why the inconsistency zpp's 'z'? What am I missing, if anything?? Thanks! - Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libpcre version requirements
On 11.08.2015 at 19:01, Adam Harvey wrote: On 11 August 2015 at 09:46, Christoph Becker cmbecke...@gmx.de wrote: What is the minimum libpcre version that is supported as external libpcre for ext/pcre? According to config0.m4 it is PCRE 6.6 (2006-02-06), but is this still valid and do we really have to support such old versions? CentOS/RHEL 5 provides libpcre 6.6, which is probably where that specific minimum version comes from. Someone out there is probably still building packages that rely on this. FWIW, this PCRE 6.6 requirement has been introduced with commit 1ad21d9b in May 2006, thus before CentOS/RHEL 5.0 had been released. It seems to me that nobody simply touched this requirement since then. Actually some features already require more recent libpcre, for instance, the \K modifier requires PCRE 7.2. I'm asking because of bug #70232 which can easily be fixed, but that requires PCRE 8.00 (2009-10-19). If we have to support older PCRE versions, we'd probably need a fallback to the current behavior (which would obviously keep the bug). I guess the question's really whether we should still support an _external_ libpcre that old, since we bundle much newer versions. I think the argument against changing it has always been that it works and we didn't need anything newer, but if we have a reason now then that doesn't really hold. One problem is that I don't think we can really change the minimum requirement on a stable branch, so for 5.5 and 5.6 we're going to have to implement something that works with older versions regardless, but I'd be for bumping the minimum version requirement for 7.0 if it makes the code cleaner (on that branch, at least) moving forward. I don't know if we can implement a fully working fallback for PCRE 8 in a viable way. Actually, PCRE_NOTEMPTY_ATSTART had been added to libpcre to solve the issue with \K for /g[1]. Note the wording of the commit message: | Added PCRE_NOTEMPTY_ATSTART in order to be able to correctly | implement the /g option in pcretest when the pattern contains \K, | [...] My best idea so far is to use PCRE_NOTEMPTY_ATSTART and to fallback to PCRE_NOTEMPTY, if the former is not available. Of course the bug would persist for old libpcre, but \K will not be effective for PCRE 6.6 anyway. [1] https://lists.exim.org/lurker/message/20090911.102109.6e80cce4.pt-BR.html -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Parameter parsing for zval type?
Hi again, - Original Message - From: Matt Wilmas Sent: Tuesday, August 11, 2015 Hi Dmitry, all, Help me understand this. :-) It's been more puzzling to me recently since just coming to the part of optimizing traditional ZPP (sharing part with FAST_ZPP...). With the FAST_ZPP inline macros, why is there a Z_PARAM_ZVAL and Z_PARAM_ZVAL_DEREF? It seems the zpp 'z' specifier is always like ZVAL_DEREF, right? So Z_PARAM_ZVAL has no equivalent in traditional zpp. At the very least, this would seem to suggest a difference in behavior/functionality. But I haven't found any (or bug reports, if tests didn't cover something). Oops! No, plain zpp 'z' does not have ZVAL_DEREF() applied, of course. But it's also using zend_parse_arg_zval_DEREF(), which is wrong... (in the case of z! with reference to IS_NULL?). At first I assumed Z_PARAM_ZVAL would keep IS_REFERENCE types, since it doesn't do ZVAL_DEREF(), but this obviously isn't happening with references. (It seems they're getting DEREF()'d in VM when sending params, I guess...?) Still stands though that IS_REFERENCE doesn't seem to get through anyway (and would break functions). Is any ZVAL_DEREF() *not* necessary? - Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: include/require function declaration.
On 11.08.2015 at 19:38, Florian BERBAR wrote: I try to understand the internals implementation of include and require functions. I've reading the sources code in search of the answer but i didn't found those declarations. Does anyone can give me the file where those statements are ? I suggest you start looking at http://lxr.php.net/xref/PHP_5_6/Zend/zend_language_parser.y#1265. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] include/require function declaration.
Hi list, I try to understand the internals implementation of include and require functions. I've reading the sources code in search of the answer but i didn't found those declarations. Does anyone can give me the file where those statements are ? Thank you Florian. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Parameter parsing for zval type?
Hi Matt, On Tue, Aug 11, 2015 at 9:00 PM, Matt Wilmas php_li...@realplain.com wrote: Hi again, - Original Message - From: Matt Wilmas Sent: Tuesday, August 11, 2015 Hi Dmitry, all, Help me understand this. :-) It's been more puzzling to me recently since just coming to the part of optimizing traditional ZPP (sharing part with FAST_ZPP...). With the FAST_ZPP inline macros, why is there a Z_PARAM_ZVAL and Z_PARAM_ZVAL_DEREF? It seems the zpp 'z' specifier is always like ZVAL_DEREF, right? So Z_PARAM_ZVAL has no equivalent in traditional zpp. At the very least, this would seem to suggest a difference in behavior/functionality. But I haven't found any (or bug reports, if tests didn't cover something). Oops! No, plain zpp 'z' does not have ZVAL_DEREF() applied, of course. But it's also using zend_parse_arg_zval_DEREF(), which is wrong... (in the case of z! with reference to IS_NULL?). Sorry. I don't understand you without context. If you think something is wrong in current implementation - please, demonstrate it with test cases, examples or code references. If you talk about your code, then show it. Thanks. Dmitry. At first I assumed Z_PARAM_ZVAL would keep IS_REFERENCE types, since it doesn't do ZVAL_DEREF(), but this obviously isn't happening with references. (It seems they're getting DEREF()'d in VM when sending params, I guess...?) Still stands though that IS_REFERENCE doesn't seem to get through anyway (and would break functions). Is any ZVAL_DEREF() *not* necessary? - Matt
Re: [PHP-DEV] libpcre version requirements
Hi all, On Wed, Aug 12, 2015 at 2:55 AM, Christoph Becker cmbecke...@gmx.de wrote: I'm asking because of bug #70232 which can easily be fixed, but that requires PCRE 8.00 (2009-10-19). If we have to support older PCRE versions, we'd probably need a fallback to the current behavior (which would obviously keep the bug). I guess the question's really whether we should still support an _external_ libpcre that old, since we bundle much newer versions. I think the argument against changing it has always been that it works and we didn't need anything newer, but if we have a reason now then that doesn't really hold. One problem is that I don't think we can really change the minimum requirement on a stable branch, so for 5.5 and 5.6 we're going to have to implement something that works with older versions regardless, but I'd be for bumping the minimum version requirement for 7.0 if it makes the code cleaner (on that branch, at least) moving forward. I don't know if we can implement a fully working fallback for PCRE 8 in a viable way. Actually, PCRE_NOTEMPTY_ATSTART had been added to libpcre to solve the issue with \K for /g[1]. Note the wording of the commit message: | Added PCRE_NOTEMPTY_ATSTART in order to be able to correctly | implement the /g option in pcretest when the pattern contains \K, | [...] My best idea so far is to use PCRE_NOTEMPTY_ATSTART and to fallback to PCRE_NOTEMPTY, if the former is not available. Of course the bug would persist for old libpcre, but \K will not be effective for PCRE 6.6 anyway. Isn't it normal that PHP would not support features that underlying libs do not support? We have number of such functions. Isn't it the reason why phpinfo() shows underlying library versions? Distributions prefer to use system's libraries. I suppose question is if PHP supports older systems such as RHEL/CentOS 5 or not. They are used widely. I prefer to support them if it is possible/feasible. Features that are not supported by libs could be documentation issues. IMO. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] libpcre version requirements
On Wed, Aug 12, 2015 at 4:59 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Distributions prefer to use system's libraries. I suppose question is if PHP supports older systems such as RHEL/CentOS 5 or not. They are used widely. I prefer to support them if it is possible/feasible. Features that are not supported by libs could be documentation issues. IMO. BTW, I don't think we should support very old libraries for new major release. -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Parameter parsing for zval type?
Hi Dmitry, - Original Message - From: Dmitry Stogov Sent: Tuesday, August 11, 2015 Hi Matt, On Tue, Aug 11, 2015 at 9:00 PM, Matt Wilmas php_li...@realplain.com wrote: Hi again, - Original Message - From: Matt Wilmas Sent: Tuesday, August 11, 2015 Hi Dmitry, all, Help me understand this. :-) It's been more puzzling to me recently since just coming to the part of optimizing traditional ZPP (sharing part with FAST_ZPP...). With the FAST_ZPP inline macros, why is there a Z_PARAM_ZVAL and Z_PARAM_ZVAL_DEREF? It seems the zpp 'z' specifier is always like ZVAL_DEREF, right? So Z_PARAM_ZVAL has no equivalent in traditional zpp. At the very least, this would seem to suggest a difference in behavior/functionality. But I haven't found any (or bug reports, if tests didn't cover something). Oops! No, plain zpp 'z' does not have ZVAL_DEREF() applied, of course. But it's also using zend_parse_arg_zval_DEREF(), which is wrong... (in the case of z! with reference to IS_NULL?). Sorry. I don't understand you without context. If you think something is wrong in current implementation - please, demonstrate it with test cases, examples or code references. If you talk about your code, then show it. Sorry, thought I gave enough context and code references! I can't demonstrate with a test case, which is why I'm asking about it. :-) No, not my code changes (you'll have plenty of code to see soon). I'm fine replicating the current logic exactly, as I have, but the logic of these couple parts doesn't make sense, to me. Let me try to simplify with couple examples... Look at e.g. is_numeric() or strpos() (needle). Plain zval param parsing, so NO ZVAL_DEREF() occurs (FAST_ZPP or traditional). These 2 example functions don't handle IS_REFERENCE type, so they would break. Or is there no way for them (or any function?) to get a IS_REFERENCE? Then *why* is there ZVAL_DEREF() in param parsing functions? We could remove it! Which is it...? Thanks. Dmitry. Thanks, Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Parameter parsing for zval type?
On Tue, Aug 11, 2015 at 10:10 PM, Matt Wilmas php_li...@realplain.com wrote: Hi Dmitry, - Original Message - From: Dmitry Stogov Sent: Tuesday, August 11, 2015 Hi Matt, On Tue, Aug 11, 2015 at 9:00 PM, Matt Wilmas php_li...@realplain.com wrote: Hi again, - Original Message - From: Matt Wilmas Sent: Tuesday, August 11, 2015 Hi Dmitry, all, Help me understand this. :-) It's been more puzzling to me recently since just coming to the part of optimizing traditional ZPP (sharing part with FAST_ZPP...). With the FAST_ZPP inline macros, why is there a Z_PARAM_ZVAL and Z_PARAM_ZVAL_DEREF? It seems the zpp 'z' specifier is always like ZVAL_DEREF, right? So Z_PARAM_ZVAL has no equivalent in traditional zpp. At the very least, this would seem to suggest a difference in behavior/functionality. But I haven't found any (or bug reports, if tests didn't cover something). Oops! No, plain zpp 'z' does not have ZVAL_DEREF() applied, of course. But it's also using zend_parse_arg_zval_DEREF(), which is wrong... (in the case of z! with reference to IS_NULL?). Sorry. I don't understand you without context. If you think something is wrong in current implementation - please, demonstrate it with test cases, examples or code references. If you talk about your code, then show it. Sorry, thought I gave enough context and code references! I can't demonstrate with a test case, which is why I'm asking about it. :-) No, not my code changes (you'll have plenty of code to see soon). I'm fine replicating the current logic exactly, as I have, but the logic of these couple parts doesn't make sense, to me. Let me try to simplify with couple examples... Look at e.g. is_numeric() or strpos() (needle). Plain zval param parsing, so NO ZVAL_DEREF() occurs (FAST_ZPP or traditional). These 2 example functions don't handle IS_REFERENCE type, so they would break. Or is there no way for them (or any function?) to get a IS_REFERENCE? Then *why* is there ZVAL_DEREF() in param parsing functions? We could remove it! Which is it...? Functions accepting references are specially marked in arginfo. Normal function argument can never be IS_REFERENCE. Reference arguments are always IS_REFERENCE. There is also a rarely used mixed mode where both are possible. For DEREF-or-not distinction is irrelevant for normal arguments, it's only important if an argument is already marked to accept a ref. Nikita
Re: [PHP-DEV] Parameter parsing for zval type?
On Tue, Aug 11, 2015 at 11:10 PM, Matt Wilmas php_li...@realplain.com wrote: Hi Dmitry, - Original Message - From: Dmitry Stogov Sent: Tuesday, August 11, 2015 Hi Matt, On Tue, Aug 11, 2015 at 9:00 PM, Matt Wilmas php_li...@realplain.com wrote: Hi again, - Original Message - From: Matt Wilmas Sent: Tuesday, August 11, 2015 Hi Dmitry, all, Help me understand this. :-) It's been more puzzling to me recently since just coming to the part of optimizing traditional ZPP (sharing part with FAST_ZPP...). With the FAST_ZPP inline macros, why is there a Z_PARAM_ZVAL and Z_PARAM_ZVAL_DEREF? It seems the zpp 'z' specifier is always like ZVAL_DEREF, right? So Z_PARAM_ZVAL has no equivalent in traditional zpp. At the very least, this would seem to suggest a difference in behavior/functionality. But I haven't found any (or bug reports, if tests didn't cover something). Oops! No, plain zpp 'z' does not have ZVAL_DEREF() applied, of course. But it's also using zend_parse_arg_zval_DEREF(), which is wrong... (in the case of z! with reference to IS_NULL?). Sorry. I don't understand you without context. If you think something is wrong in current implementation - please, demonstrate it with test cases, examples or code references. If you talk about your code, then show it. Sorry, thought I gave enough context and code references! I can't demonstrate with a test case, which is why I'm asking about it. :-) No, not my code changes (you'll have plenty of code to see soon). I'm fine replicating the current logic exactly, as I have, but the logic of these couple parts doesn't make sense, to me. Let me try to simplify with couple examples... Look at e.g. is_numeric() or strpos() (needle). Plain zval param parsing, so NO ZVAL_DEREF() occurs (FAST_ZPP or traditional). These 2 example functions don't handle IS_REFERENCE type, so they would break. Or is there no way for them (or any function?) to get a IS_REFERENCE? Then *why* is there ZVAL_DEREF() in param parsing functions? We could remove it! We probably may remove ZVAL_DEREF() for functions arguments passed by value, but we don't know if argument was passed by value or by reference in ZPP functions. Actually, in FAST_ZPP for scalars we may probably assume passing by value and remove ZVAL_DEREF(), but I'm not sure if this is 100% safe. Thanks. Dmitry. Which is it...? Thanks. Dmitry. Thanks, Matt
[PHP-DEV] Re: include/require function declaration.
On 11/08/2015 19:59, Christoph Becker wrote: On 11.08.2015 at 19:38, Florian BERBAR wrote: I try to understand the internals implementation of include and require functions. I've reading the sources code in search of the answer but i didn't found those declarations. Does anyone can give me the file where those statements are ? I suggest you start looking at http://lxr.php.net/xref/PHP_5_6/Zend/zend_language_parser.y#1265. Thank you Florian. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Request: marcosptf
i want to have php account to help on resolve bugs from bugs.php.net and becouse i have contributed on php-src: https://github.com/php/php-src/search?utf8=%E2%9C%93amp;q=marcosptf and i wanna contribute more and more :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] libpcre version requirements
Hi Christoph, -Original Message- From: Christoph Becker [mailto:cmbecke...@gmx.de] Sent: Tuesday, August 11, 2015 6:46 PM To: PHP internals internals@lists.php.net Subject: [PHP-DEV] libpcre version requirements Hi all! What is the minimum libpcre version that is supported as external libpcre for ext/pcre? According to config0.m4 it is PCRE 6.6 (2006-02-06), but is this still valid and do we really have to support such old versions? I'm asking because of bug #70232 which can easily be fixed, but that requires PCRE 8.00 (2009-10-19). If we have to support older PCRE versions, we'd probably need a fallback to the current behavior (which would obviously keep the bug). IMHO the dependent version shouldn't be raised. But not sure what is meant by implementing for lower versions. Probably if it's missing in PCRE, so is it. We should avoid reimplementing it, but just doing what is done in the other exts, fe curl. Users can choose to upgrade the dependency or to miss the feature. So a compile time PCRE version check were enough. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libpcre version requirements
On 11.08.2015 at 22:08, Yasuo Ohgaki wrote: On Wed, Aug 12, 2015 at 4:59 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Distributions prefer to use system's libraries. I suppose question is if PHP supports older systems such as RHEL/CentOS 5 or not. They are used widely. I prefer to support them if it is possible/feasible. Features that are not supported by libs could be documentation issues. IMO. Well, of course we can document all these details, but see, for instance, http://www.php.net/manual/en/libxml.constants.php – hard to document, hard to remember, and hard to implement for apps which are supposed to run in different environments. At least we should try to reduce the divergence as much as possible (i.e. without introducing BC breaks in revisions). BTW, I don't think we should support very old libraries for new major release. ACK. IMHO requiring PCRE = 8.0 would be fine for PHP 7. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack
On 10.08.2015 at 11:57, Craig Francis wrote: You only have to skim read things like the second comment (with 27 up votes) on the PDO prepare page to see that these problems are happening all the time: http://php.net/manual/en/pdo.prepare.php#111458 SELECT * FROM users WHERE $search=:email Skim reading things might be the problem (here). The user contributed note states: | In my case I allow the user to enter their username or email, | determine which they've entered and set $search to username or | email. As this value is not entered by the user there is no | potential for SQL injection and thus safe to use as I have done. So to me that note looks pretty fine. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
