Re: [PHP-DEV] Consolidation of Traversable and array operations
Hi! On Thu, Jul 16, 2015 at 6:39 PM Michael Wallner m...@php.net wrote: On 16/07/15 11:26, Rowan Collins wrote: Benjamin Eberlei wrote on 15/07/2015 21:19: But instanceof and anything related to Reflection or get_class or relevant code will fail on array. Ah, yes, I hadn't thought of reflection type things. I don't think instanceof would be a problem, because checking for any class or interface other than Traversable would correctly return false; not sure if it would make sense for array() instanceof Traversable to return true or not... Maybe some pseudotype like callable (e.g. iteratable) makes more sense then? I'm okay with a pseudo type. My opinion on the matter at this point is such that I care more about providing an API of sorts to support both kinds of structures, so that any developer can write an extension that can leverage this capability and make this available in user-land. Having array_some() and array_every() support this doesn't have to be documented for all I care, if anything it serves as an example of what can be done. The most immediate feedback I would like is: a) whether it's useful to add as an API, b) a review of the code in `php_traversal.[ch]` -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Consolidation of Traversable and array operations
Hi!
A few weeks ago I resurrected a two year old proposal for adding two array
functions, namely array_every() and array_some(), modelled after their
JavaScript equivalent.
https://github.com/php/php-src/pull/1385
The most notable comment was that it would be nice to support Traversable
as well as arrays; instead of only supporting this for my own functions,
I've generalised this so that other functions can take advantage of this as
well. These are the additions:
1. A ZPP argument; the t (for traversable) argument type has been added
that checks for either an array or implementation of zend_ce_traversable.
2. A generic iteration function, called php_traverse(); it accepts:
a. the zval* to iterate over,
b. a step-wise function that receives the value and key, and returns a
boolean that determines whether iteration should continue or not,
c. a traversal mode (only values, or keys and values),
d. a context that's sent to the step-wise function.
3. A concrete implementation of a step-wise iteration function,
php_traverse_until, that gets called as part of array_every() and
array_some().
The implementation of above proposal can be found in the PR itself. With
more functions adopting this idea, you could see this work:
var_dump(array_reduce((function() {
yield 1;
yield 2;
yield 3;
})(), function($total, $current) {
return $total + $current;
}, 0); // int(6)
Let me know what you think!
Re: [PHP-DEV] Possible Bug or Bad Expectations?
On Sun, Jul 12, 2015 at 2:52 AM Ralph Schindler ra...@ralphschindler.com wrote: Hi all, I am conflicted as per if what I experience in this code should be throwing a notice in E_STRICT: http://3v4l.org/srm5f ?php error_reporting(E_ALL); $foo = ['bar' = ['baz' = 5]]; $bar = ['box' = 'baz']; // this will Notice: Undefined index: boom var_dump(isset($foo['bar'][$bar['boom']])); Essentially, my expectation is that anything inside an isset() would be immune from notices of undefined indexes, but that is not the case with nested array key lookups. You're not getting a notice for the undefined index `$foo['bar'][null]`, that's basically what isset() is made to do. If you want to guard against undefined indices in an array that you're using to dereference `$foo` you need this: var_dump(isset($bar['boom'], $foo['bar'][$bar['boom']])); Is this a bad expectation to have? Or should isset() silence the nested undefined index as well? I also realized this has always been the behavior leading me to believe I might have a bad expectation here. In any case wanted to check. Thanks, -ralph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PR #1325 - array_column() for array of objects
On 12 Jun 2015, at 10:00 am, Xinchen Hui larue...@php.net wrote: Hey: On Fri, Jun 12, 2015 at 9:31 AM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Hi, I've created a PR here: https://github.com/php/php-src/pull/1325 This enhancement allows for properties on objects to work in the same way as arrays for the inner elements of the main array. IMO, it is called (array)_column... Please read more carefully, it's about supporting objects as the *inner elements* of an array, not instead of an array. and if you really want do it against object, you can always easily convert the object to array. thanks It also supports the __get() method, provided that also __isset() is implemented and returns true for the addressed property. The only BC I can imagine is when an array is populated with a mixed set of objects and arrays; any professional would baulk at the idea, but rules of the jungle are pervasive. Before I merge this, are there any objections to shipping this with 7.0? -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PR #1325 - array_column() for array of objects
Hi, I've created a PR here: https://github.com/php/php-src/pull/1325 This enhancement allows for properties on objects to work in the same way as arrays for the inner elements of the main array. It also supports the __get() method, provided that also __isset() is implemented and returns true for the addressed property. The only BC I can imagine is when an array is populated with a mixed set of objects and arrays; any professional would baulk at the idea, but rules of the jungle are pervasive. Before I merge this, are there any objections to shipping this with 7.0?
Re: [PHP-DEV] [VOTE] Abstract final / Static classes
On 13 Dec 2014, at 00:35, guilhermebla...@gmail.com wrote:
RFC is updated exposing both possible usages with both explanations.
Hope it doesn't confuse even more.
Hi, in your As static class” example, it doesn’t really demonstrate that you
can omit the “static” modifier from the function declarations.
Also, it’s not clear if the same applies to “As abstract final”.
On Fri, Dec 12, 2014 at 11:30 AM, Florian Margaine flor...@margaine.com
wrote:
Hi,
Le 12 déc. 2014 17:28, guilhermebla...@gmail.com
guilhermebla...@gmail.com a écrit :
It's part of the history of that RFC, accessible here:
https://wiki.php.net/rfc/abstract_final_class?rev=1417060830
But then it isn't clear as of right now. What is proposed? The example?
The votes? What does `final` has to do with `static`?
I'm confused.
On Fri, Dec 12, 2014 at 11:18 AM, Florian Margaine flor...@margaine.com
wrote:
Hi,
On Fri, Dec 12, 2014 at 5:12 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Hi internals,
After a good round of discussion, I updated the original abstract
final
class proposal into a static class proposal.
However, I kept both patches online so it's up to voters decide which
one
it could be implemented.
Patches are now complete and voting phase starts now and will be active
until 12/19/2014.
As this is a language update, it requires 2/3 pro or against the
feature.
https://wiki.php.net/rfc/abstract_final_class
Why does the example use `final`?
final static class Environment
{
private static $rootDirectory = '/var/www/project';
public static function getRootDirectory()
{
return self::$rootDirectory;
}
}
Also, the vote presents 2 options. The RFC is in a weird state where it
mentions abstract final but doesn't explain anything about them. The
votes don't seem to be what the example is...
Could you edit your RFC?
Happy voting!
Regards,
--
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Cheers,
--
Florian Margaine
--
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Cheers,
Florian
--
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] What ZEND_ACC_ALLOW_STATIC is supposed to do
Hi, I was looking at the documentation for DOMDocument::loadHTML() [1] that mentions the following: This function may also be called statically to load and create a DOMDocument object. The static invocation may be used when no DOMDocument properties need to be set prior to loading. However, this can’t be done in strict mode [2]: Strict Standards: Non-static method DOMDocument::loadHTML() should not be called statically in … This behaviour seems to be intended when ZEND_ACC_ALLOW_STATIC is used [3] and can be fixed by using ZEND_ACC_STATIC instead. My questions: 1) Is that the right kind of fix? 2) Is ZEND_ACC_ALLOW_STATIC meant to be used only for BC? If not, why are we raising strict errors? [1] http://php.net/manual/en/domdocument.loadhtml.php http://php.net/manual/en/domdocument.loadhtml.php [2] http://3v4l.org/JC7p0#v500 http://3v4l.org/JC7p0#v500 [3] http://lxr.php.net/xref/PHP_5_5/Zend/zend_vm_def.h#1935 http://lxr.php.net/xref/PHP_5_5/Zend/zend_vm_def.h#1935
Re: [PHP-DEV] enhance fget to accept a callback
Hi! On 24 Nov 2014, at 02:39, Bill Salak b...@devtemple.com wrote: Hi list, I'm considering writing an RFC to add a 3rd parameter to fgets which accepts a user defined function. If we had this today we wouldn't need fgetcsv with the added benefit of fgetcsv style support for data packaging formats we would otherwise create more 1 off functions for. For example, if we decided to support reading json from files in the same manner as our current fgetcsv functionality today, we would create an fgetjson function. This change unifies the way in which we support native transliteration of data packaging formats from files into php data structures through a single interface. The other major design benefit, from my point of view, is the unification of userland transliteration functions/libraries with the same modality as our native support for these types of use cases. I believe this will ultimately result in more intuitive userland code around this type of functionality. The fgets() function has a few behavioural properties that are hard to change: 1) it reads until it reaches a newline; 2) it’s expected to return a string. The above two properties prevent it from being a good candidate for reading other formats, such as CSV or JSON which may: 1) span across multiple lines and 2) almost always return something other than a string. Before I go any further in formalizing my proposal, I'd like to get feedback from list members. Thanks for your time. Bill Salak -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: fgetcsv incompatible with fputcsv
On 21 Nov 2014, at 02:14, Christoph Becker cmbecke...@gmx.de wrote: Tjerk Meesters wrote: On 20 Nov 2014, at 00:26, Christoph Becker cmbecke...@gmx.de wrote: Are you aware of https://bugs.php.net/bug.php?id=50686? It seems this very inconsistency has been reported a few years ago, but has been tagged as Wont fix back then. Actually that bug report seems to suggest that fputcsv() uses backslash to encode enclosure characters, but AFAICT it doesn’t. Apparently, there is a somewhat hidden bug, see http://3v4l.org/El5Xs for a simplified test script. The expected result is string(14) ab,a\b or maybe string(14) a\b,a\\b The actual result makes no sense to me, even though str_getcsv() parses it correctly”. That works exactly for the wrong reasons: 1) upon seeing an escape character fgetcsv() will print that and the following character 2) fputcsv() actually accepts an escape character too (despite what the documentation says) but treats it in the wrong way by not escaping that and the following character The expected output, based on the given code should (imo) be: string(15) a\b,a\\\b Or: if the escape character is a double quote: string(15) “ab,”a\b”” Unfortunately I can’t satisfy all the related bug reports, some decision of “correctness” needs to be made in the form of an RFC. And then there are bug reports like https://bugs.php.net/bug.php?id=67566 which were fixed but really just made the situation worse =( ACK. https://bugs.php.net/bug.php?id=38929 also seems to deal with this inconsistency, and had been tagged as Not a bug. So maybe an RFC is appropriate? Yeah, I didn’t realise the can of worms until I opened it; I’ll round up all the bug reports and run them against whatever RFC I can get my hands on. PS: Favourite quote from the semi-authoritative spec of Perl_CSV: http://rath.ca/Misc/Perl_CSV/CSV-2.0.html#csv: Given that the essence of CSV files is simplicity, I have decided to reject all escape and escaped characters with the exception of quoation marks appearing within quotation marks … Good times :) One might argue that the essence of CSV files is being a data exchange format, so applying Postel's law would be reasonable. :) -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: fgetcsv incompatible with fputcsv
Hi list, As I was fiddling with CSV data reading and writing I noticed that fgetcsv() is inherently incompatible with fputcsv() when it comes to the enclosure escape character that’s used. Example: http://3v4l.org/LHEZj The above example code demonstrates how, by default, fputcsv() encodes a backslash as is but fgetcsv() will treat that same backslash as the enclosure escape character as well as the enclosure character itself; this is rather surprising behaviour and imho unnecessarily complicated. I would suggest changing the behaviour in such a way that: a) the default enclosure escape character for fgetcsv() is a double quote. b) fgetcsv() only treats the escape character as … an escape character. Due to the kind of change BC can’t be maintained, so I’d propose this change for PHP 7. If anyone has violent objections to the above, or thinks that an RFC should be drawn up, do let me know … otherwise I’ll commit the change into master by next week or so. Best, Tjerk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: fgetcsv incompatible with fputcsv
Hi list, As I was fiddling with CSV data reading and writing I noticed that fgetcsv() is inherently incompatible with fputcsv() when it comes to the enclosure escape character that’s used. Example: http://3v4l.org/LHEZj The above example code demonstrates how, by default, fputcsv() encodes a backslash as is but fgetcsv() will treat that same backslash as the enclosure escape character as well as the enclosure character itself; this is rather surprising behaviour and imho unnecessarily complicated. I would suggest changing the behaviour in such a way that: a) the default enclosure escape character for fgetcsv() is a double quote. b) fgetcsv() only treats the escape character as … an escape character. Due to the kind of change BC can’t be maintained, so I’d propose this change for PHP 7. If anyone has violent objections to the above, or thinks that an RFC should be drawn up, do let me know … otherwise I’ll commit the change into master by next week or so. Best, Tjerk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: fgetcsv incompatible with fputcsv
On 20 Nov 2014, at 00:26, Christoph Becker cmbecke...@gmx.de wrote: Tjerk Meesters wrote: Hi list, As I was fiddling with CSV data reading and writing I noticed that fgetcsv() is inherently incompatible with fputcsv() when it comes to the enclosure escape character that’s used. Example: http://3v4l.org/LHEZj The above example code demonstrates how, by default, fputcsv() encodes a backslash as is but fgetcsv() will treat that same backslash as the enclosure escape character as well as the enclosure character itself; this is rather surprising behaviour and imho unnecessarily complicated. I would suggest changing the behaviour in such a way that: a) the default enclosure escape character for fgetcsv() is a double quote. b) fgetcsv() only treats the escape character as … an escape character. Due to the kind of change BC can’t be maintained, so I’d propose this change for PHP 7. If anyone has violent objections to the above, or thinks that an RFC should be drawn up, do let me know … otherwise I’ll commit the change into master by next week or so. Are you aware of https://bugs.php.net/bug.php?id=50686? It seems this very inconsistency has been reported a few years ago, but has been tagged as Wont fix back then. Actually that bug report seems to suggest that fputcsv() uses backslash to encode enclosure characters, but AFAICT it doesn’t. And then there are bug reports like https://bugs.php.net/bug.php?id=67566 which were fixed but really just made the situation worse =( https://bugs.php.net/bug.php?id=38929 also seems to deal with this inconsistency, and had been tagged as Not a bug. So maybe an RFC is appropriate? Yeah, I didn’t realise the can of worms until I opened it; I’ll round up all the bug reports and run them against whatever RFC I can get my hands on. PS: Favourite quote from the semi-authoritative spec of Perl_CSV: http://rath.ca/Misc/Perl_CSV/CSV-2.0.html#csv: Given that the essence of CSV files is simplicity, I have decided to reject all escape and escaped characters with the exception of quoation marks appearing within quotation marks … Good times :) -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: PHP 7.0 timeline
On 15 Oct 2014, at 01:24, Rasmus Lerdorf ras...@lerdorf.com wrote: On 10/14/2014 10:14 AM, Stas Malyshev wrote: Hi! IMO, AST, INT64, NG, Uniforme variables style is enough for a new marjor version.. why we still need to wait? We don't need to just wait, as sit and do nothing. We need to allocate time for other features. There are also quite a few really low-level changes in master right now. It is going to take quite a bit of time to stabilize. For example, something as basic as array iteration is inadvertently different: https://bugs.php.net/68215 This is a known issue for which the test cases were marked as XFAIL because of the amount of work involved to get it fixed: https://github.com/php/php-src/commit/5831cca9576f4e0d4daed75a9915d436dfc5f4e5 PHP is a mature project with reams and reams of legacy code out there. Every single change, no matter how small, is like throwing a hand grenade in a lake. There is the initial explosion and chaos and then the ripples that go on and on. Dealing with all these ripples takes a lot more time than most people think. For people who think that 1 year from now is slow and conservative, it really isn't. It is quite aggressive given the number of really low-level changes that are already in master. Even if we froze the tree today I expect it could stretch to close to a year to stabilize. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7
On 15 Oct, 2014, at 9:23 am, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! For the array-to-object conversion, no scanning is necessary, since the internal implementation already knows which keys are integers and which strings. For the vast majority of cases, the array passed in will have Could you explain this? How you know which keys are integers and which strings without actually checking them? He means there's no additional effort required to know whether the key of each element is a string or not, because that work has already been done at the insert/update stage. object. I would strongly suspect that most objects have very few properties, and very few property names would pass a simple test of is first character a digit but subsequently fail the full is numeric test. You still have to scan through all of them, even if they have no digits at all. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] disallow non-static method calls with self/static in PHP 7
On 12 Oct 2014, at 16:37, Robert Stoll p...@tutteli.ch wrote:
Hey,
I just stumbled over a method call of a non-static method with self and was
asking myself again, why does PHP support
this behaviour. An example to outline what I am writing of:
class A{
function foo(){
self::bar();
}
function bar(){}
}
IMO it should not be allowed to call non-static methods with self or static.
Sure, it is just a small detail but for
someone who starts learning PHP it is an unnecessary supplement.
The use of self::, static:: (or parent:: for that matter) itself doesn’t make a
method call static; it’s the declaration or caller context that makes it behave
statically, i.e. $this can’t be used.
In your given example, $this is defined when A::bar() is called; interestingly,
when this class is extended it will still only call A::bar() as opposed to
calling $this-bar(). Whether this is useful behaviour is irrelevant :)
The use of static::bar() is kind of pointless, because AFAICT there’s no
difference between that and $this-bar() in this particular example.
Maybe it is too drastic to disallow it in PHP 7 but yeah. I would like to
know what you think about it and if someone
has a good reason why it is allowed nowadays then please help me out.
Cheers,
Robert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Remove support for classes without class entries: Zend/zend_API.c Zend/zend_builtin_functions.c Zend/zend_closures.c Zend/zend_execute.h Zend/zend_interfaces.c
Hi
On 10 Oct 2014, at 03:57, Dmitry Stogov dmi...@zend.com wrote:
Yeah, JavaBridge used it, but it doesn't means it need it.
zend_class_entry * _php_java_get_class_entry(zval *object TSRMLS_DC)
{
return java_class;
}
I agree, it would be better if we would discuss it on @internals, but it
would take much longer time
If you still see use cases for it, please show
If anything, could this be recorded in the UPGRADING file?
Thanks
Thanks. Dmitry.
On Thu, Oct 9, 2014 at 11:48 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
we discussed this issue with Nikita on IRC, and didn't find any use
cases for objects without ce now.
Nor in php neither in pecl.
Do you see any problems?
Those were used to create bridge APIs - like Zend's Java bridge (not
sure if supported now, probably not, and if it's still uses that), as
far as I remember. It may be that PECL does not use it but people have
internal extensions that are not published. So deleting a chunk of the
API without as much as a note on internals is not really a good idea, I
think.
IRC discussion is not a public discussion, since most of the people are
not present on the IRC and have no idea about anything being discussed
there.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fixes for (Recursive)RegexIterator
Hi, I’ve addressed bug #68128 with the following PR: https://github.com/php/php-src/pull/865 As usual, I went in fixing one thing and ended up changing more until the results started to make sense. I would appreciate another pair of eyes to glance over the changed code :) Also, I’m hoping to land this for a 5.6.x release as well; however, some existing test cases were adjusted due to the changed behaviour, so there’s some BC we have to take note of. Best, Tjerk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can someone merge `Catchable Call to a member function bar() on a non-object`?
Hi! On 16 Sep 2014, at 01:42, Timm Friebe p...@thekid.de wrote: Hi everyone, Timm Friebe p...@thekid.de hat am 16. August 2014 um 18:09 geschrieben: two weeks ago, the RFC `Catchable Call to a member function bar() on a non-object` was accepted by a vote. I don't have commit access to php-src/Zend, so I can't commit this myself. Back from my summer vacation, I thought I'd whip up this email (after bringing the pull request up-to-date and making it mergeable once again) and ask whether someone here can review[1] and then merge the PR https://github.com/php/php-src/pull/647? Thanks in advance! Any news on this? Is there anything left I need to do to get this merged? Should I apply for Zend/ karma? It’s been merged; due to my deceptive eyes and the similarity between the PR numbers (647 vs 847), I’ve merged 647 instead and then added the test cases that were written for 847. The end result should be the same and certainly all test cases passed (safe for those involving mysql tests); I’ll check the Travis results when they come back. My apologies on the somewhat messy push for this :( -Timm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regression in RecursiveRegexIterator
Hi! On 4 Oct 2014, at 03:38, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: Hello :-), Does anyone know something about this bug: https://bugs.php.net/bug.php?id=68128 ? Yeah, I’ve addressed it with a PR: https://github.com/php/php-src/pull/865 Basically, this behaviour was introduced with d81ea16ef14735b97f22702ca1a78c3674fd987e; zend_make_printable_zval () was changed to raise a warning whenever an array is passed as an argument. My suggestion is to ::accept() non-empty arrays instead of attempting to convert them into a string. I *think* that’s a reasonable change :) Thanks! -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #68063: session-related, how to fix it?
On 20 Sep, 2014, at 11:35 pm, Florian Margaine flor...@margaine.com wrote:
Hi list,
I saw this interesting bug: https://bugs.php.net/bug.php?id=68063
Basically, if `session_id('')` is run before `session_start()`, weird
things happen.
The bug reporter proposes 2 ways to fix this:
- `session_start()` should silently fix the situation
I would opt for this, if an invalid session id is given a warning should be
emitted and a new id generated.
- or `session_start()` should noisely fail
Both solutions look fine to me, but I'm not sure what PHP should do. Should
it be resilient and silently fix the situation?
Regards,
*Florian Margaine*
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internationalized Domain Name support in FILTER_VALIDATE_URL
On 19 Sep 2014, at 06:52, Andrea Faulds a...@ajf.me wrote: On 18 Sep 2014, at 21:26, Kévin Dunglas dung...@gmail.com wrote: I'm working on enhancing the FILTER_VALIDATE_URL filter ( https://github.com/php/php-src/pull/826). The current implementation does not support validation of internationalized domain names (i.e: http://www.académie-française.fr/ http://www.xn--acadmie-franaise-npb1a.fr/). Support of IDN validation can be easily added using ICU's uidna_toASCII() function. Is it acceptable to add a dependency to ICU for ext/filter? Another option is to add a HAVE_ICU constant in main/php_config.h and to validate IDN only if ICU is present. What strategy is preferred? Perhaps add a new filter that covers normal URLs and IDN ones? I just imagine it might cause problems if suddenly IDNs are accepted, if there is a backend which can’t handle them. We don’t need a new filter, you can simply add a filter flag for FILTER_VALIDATE_URL, e.g. FILTER_FLAG_ALLOW_IDN. Of course, the ICU dependency should be optional :) -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Internationalized Domain Name support in FILTER_VALIDATE_URL
On Fri, Sep 19, 2014 at 1:24 PM, Kévin Dunglas dung...@gmail.com wrote: Hi, The flag is a good idea to handle old systems but the feature must be enabled by default (at least for PHP 7) and disablable through the flag. IDN RFCs are more than 10 years old. All major browsers and registrars support IDN. My apologies, I meant the inverse. If ICU is enabled we should make FILTER_VALIDATE_URL check IDN by default and add a flag to allow malformed IDN. However, it should not enforce the dependency on ICU itself; if it's there, it will be used, otherwise it will allow malformed IDN by default (if present). Personally I wouldn't mind having this for 5.6 as well if the upgrade path is clean, but the cleanest path I could think of involves having two flags that do the opposite action :) Le vendredi 19 septembre 2014, Tjerk Meesters tjerk.meest...@gmail.com a écrit : On 19 Sep 2014, at 06:52, Andrea Faulds a...@ajf.me wrote: On 18 Sep 2014, at 21:26, Kévin Dunglas dung...@gmail.com wrote: I'm working on enhancing the FILTER_VALIDATE_URL filter ( https://github.com/php/php-src/pull/826). The current implementation does not support validation of internationalized domain names (i.e: http://www.académie-française.fr/ http://www.xn--acadmie-franaise-npb1a.fr/ http://www.xn--acadmie-franaise-npb1a.fr/). Support of IDN validation can be easily added using ICU's uidna_toASCII() function. Is it acceptable to add a dependency to ICU for ext/filter? Another option is to add a HAVE_ICU constant in main/php_config.h and to validate IDN only if ICU is present. What strategy is preferred? Perhaps add a new filter that covers normal URLs and IDN ones? I just imagine it might cause problems if suddenly IDNs are accepted, if there is a backend which can’t handle them. We don’t need a new filter, you can simply add a filter flag for FILTER_VALIDATE_URL, e.g. FILTER_FLAG_ALLOW_IDN. Of course, the ICU dependency should be optional :) -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Kévin Dunglas Consultant et développeur freelance http://dunglas.fr Tél. : 06 60 91 20 20 -- -- Tjerk
[PHP-DEV] Fix for #68021
Hi, I’ve authored a fix for browscap: https://github.com/php/php-src/pull/827 Bug report: https://bugs.php.net/bug.php?id=68021 It replaces the current expression delimiters of \xA7 with a tilde (~) that’s ASCII compatible and therefore plays nice with UTF-8. Seems like a no-brainer to apply this to 5.4 onwards, but perhaps somebody has a compelling reason why those section symbols are an absolute necessity. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecated functions
Hi Alex,
On 10 Sep 2014, at 13:59, Alexander Lisachenko lisachenko...@gmail.com wrote:
Hi!
Maybe it will be better to do this in another way: introduce an RFC to
add 'deprecated' keyword into the syntax like 'final' or 'protected'.
There are many frameworks that want to deprecate some methods or
classes. Currently it's only possible via @deprecated tag in the
phpDoc-block, but this tag doesn't influence on method invocation, so
no warnings are generated.
Any decent IDE should tell you that a function is deprecated by observing
DocBlock; I believe PhpStorm uses strike-through to indicate deprecated
functionality.
Symfony uses trigger_error($message, E_USER_DEPRECATED) explicitly in
deprecated methods to trigger this warning (see
https://github.com/symfony/symfony/pull/6180), but this is not a
transparent solution.
I agree that having a ‘deprecated’ keyword would simplify matters, but I don’t
think that alone is worth making it a language feature.
This could be a good case for annotations, though, if we ever get such a thing
:)
This can be look like this:
class Test {
deprecated protected $someProperty;
deprecated public function foo() {}
public function bar() {}
}
deprecated class OldStuff {}
deprecated function someOldFunction() {}
This RFC will give more control over 'deprecated' functionality and
can be easily tested.
Thoughts?
2014-09-10 9:42 GMT+04:00 Tjerk Meesters tjerk.meest...@gmail.com:
Hi,
When I was fixing test cases on my `kill-ereg` branch I noticed a Reflection
test case for `ReflectionFunction::isDeprecated()`.
The problem with such a test case is that you’d be chasing deprecated
functions to tests against as we move along; this is the current list of
deprecated functions as taken from a typical 5.4 installation:
Since 4.1.0: call_user_method, call_user_method_array
Since 4.3.7: mysql_list_tables, mysql_listtables
Since 5.3 : ereg, ereg_replace, eregi, eregi_replace, split, spliti,
sql_regcase, mysql_db_query, magic_quotes_runtime, set_magic_quotes_runtime,
set_socket_blocking
Since 5.4 : mysql_list_dbs
The above are, as far as I’m concerned, all potential candidates for removal
in PHP 7, so in order to reliably test a deprecated function I would suggest
introducing a hidden function with this signature:
void __deprecated__() { }
And mark that function as eternally deprecated using the ZEND_ACC_DEPRECATED
flag.
Thoughts?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Deprecated functions
Hi,
When I was fixing test cases on my `kill-ereg` branch I noticed a Reflection
test case for `ReflectionFunction::isDeprecated()`.
The problem with such a test case is that you’d be chasing deprecated functions
to tests against as we move along; this is the current list of deprecated
functions as taken from a typical 5.4 installation:
Since 4.1.0: call_user_method, call_user_method_array
Since 4.3.7: mysql_list_tables, mysql_listtables
Since 5.3 : ereg, ereg_replace, eregi, eregi_replace, split, spliti,
sql_regcase, mysql_db_query, magic_quotes_runtime, set_magic_quotes_runtime,
set_socket_blocking
Since 5.4 : mysql_list_dbs
The above are, as far as I’m concerned, all potential candidates for removal in
PHP 7, so in order to reliably test a deprecated function I would suggest
introducing a hidden function with this signature:
void __deprecated__() { }
And mark that function as eternally deprecated using the ZEND_ACC_DEPRECATED
flag.
Thoughts?
Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736
Hi! On Sat, Sep 6, 2014 at 5:38 AM, Florian Margaine flor...@margaine.com wrote: Hi, This is a minor BC break, but still a BC break, so worth discussing on this ML. When a second setcookie() is done with the same name, a warning is emitted, because the ietf rfc 6265 says it *should* only send one Set-Cookie header per name. This is fine when display_errors is set to off. When it's set to on, the warning prevents the header from being added because headers already sent (which is the minor BC break, as current PHP just sends 2 Set-Cookie headers with the same name). Yeah, it would prevent any header() or setcookie() following that warning from taking place. How about delaying that warning until the headers are sent? So, should it be merged? What should be done to comply with the ietf rfc 6265? PR: https://github.com/php/php-src/pull/795/ PHP issue: https://bugs.php.net/bug.php?id=67736 Regards, *Florian Margaine* -- -- Tjerk
Re: [PHP-DEV] Kill ereg with fire
Hi Ferenc, On 31 Aug, 2014, at 7:00 pm, Ferenc Kovacs tyr...@gmail.com wrote: On Sun, Aug 31, 2014 at 7:08 AM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Hi internals (again), Recently I’ve done a small assessment on how feasible it is to remove ext/ereg from the project for the next major version. This is the result (so far): https://github.com/datibbaw/php-src/compare/kill-ereg I’ve replaced two instances of ereg with their pcre equivalents, OPcache and PGSQL. Btw, simply using ‘pcreposix.h’ didn’t work out for OPcache, I would get this error: Error Blacklist compilation: invalid argument to regex routine Perhaps I’ve missed something obvious, but porting it wasn’t hard either. Thoughts? Afair we have a patch floating around, but never made it into the repo, but everybody seemed to agree to remove the core dependency of ereg and make it optional to enable. You mean make it optional to install via PECL, right? I agree ;-) Package maintainers can always choose to ship their php packages with ereg as a means to keep supporting it, regardless of how it’s provided (bundled or PECL). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] Loosening heredoc/nowdoc scanner
Hi Stas, On 30 Aug, 2014, at 2:08 pm, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I would like to propose a few changes to our heredoc / nowdoc scanner to make it less awkward to use inside other constructs. https://wiki.php.net/rfc/heredoc-scanner-loosening Let me know your thoughts :) With this proposal, you will not be able to use the delimiter inside the text at the beginning of the line, which is a BC break and may be a problem for some code. Yes, that’s also mentioned in the RFC; although it would happen more easily when restrictions are completely removed, there’s a slim chance it would happen with the limited set of valid terminators. That said, I would like to quote from the RFC itself: […] it should be noted that the developer is in complete control of choosing the name for their enclosures; it's important to choose an enclosure that doesn't occur naturally inside the quotation. I'm not sure saving one variable assignment, at the expense of making scripts less readable and breaking BC, is really worth it. How often you need an array of heredocs or concatenate two heredocs? There’s no real objective measure with which I can answer such questions :) The closest I could come to a rebuttal is if there’s no real need to make the syntax so restrictive, why not make it less restrictive? How often it is a good idea, readability-wise? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Making parse_ini_*() aware of types
Hi internals, I was going through the bug list and found this report: https://bugs.php.net/bug.php?id=38409 It discusses the fact that `parse_ini_file()` and `parse_ini_string()` throw away type information; for instance, the flag “on” doesn’t translate into a bool(true) but string(“1”). The report has had 21 votes and an average score of 4.3 +- 0.7, so it seems to have some traction with users. Simply changing this behaviour would cause BC, so I’ve found a way in which this can be solved with a separate scanner mode; e.g.: $data = parse_ini_file(‘/path/to/file’, true, INI_SCANNER_TYPED); A patch for the lexer can be found here, together with a simple test case: https://github.com/datibbaw/php-src/compare/php:master...datibbaw:ini-scanner-plus It currently distinguishes between booleans, numbers and NULL (it was mentioned in the ticket by someone else, not entirely sure of its usefulness, though). I haven’t benchmarked it, but the impact on performance should be quite minimal. Thoughts? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] destructors and output_buffering
On 31 Aug, 2014, at 9:33 am, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
I was looking at bug https://bugs.php.net/bug.php?id=67644 and it looks
like we have a bit of a problem with output buffering and dtors on
shutdown. Basically, right now our code looks like this:
/* 2. Call all possible __destruct() functions */
zend_try {
zend_call_destructors(TSRMLS_C);
} zend_end_try();
/* 3. Flush all output buffers */
zend_try {
// And here we go flushing output buffers
Now, since ob functions can have userland handlers, these handlers can
create new objects. And these objects will not benefit from orderly dtor
round that zend_call_destructors(TSRMLS_C) is providing - instead their
dtors will be called from zend_objects_store_free_object_storage() and
by then their environment may already be ruined and their dtors can not
run properly.
OTOH, moving __destruct after output buffers may not be good either, as
dtors may output something.
The problem seems to be resolved if I either duplicate
zend_call_destructors(TSRMLS_C); after the output buffers flushing or put
zend_objects_store_mark_destructed(EG(objects_store) TSRMLS_CC);
there.
Of course, the second solution has the downside of not calling the dtors
of objects that were created while flushing ob buffers. The
zend_call_destructors would work but since output buffering is supposed
to be shut down by then, I wonder if it won't also have bad consequences
if these dtors do something with output buffering.
I'm leaning towards the second solution - if you create the objects so
late on shutdown stage, you shouldn't really expect them to be destroyed
normally, otherwise the cycle would never end. However, we could
consider the first option too. Any thoughts?
This is just a thought; could we delay the call to `zend_call_destructors` ONLY
IF there’s output buffering taking place (i.e. ob_get_level() 0)?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Loosening heredoc/nowdoc scanner
On 31 Aug, 2014, at 6:12 am, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! There’s no real objective measure with which I can answer such questions :) The closest I could come to a rebuttal is if there’s no real need to make the syntax so restrictive, why not make it less restrictive? Why not is usually not a very good reason for a change in the language syntax. There is, however, a reason why it is restrictive - so that there would be less chance for the end tag to collide with the actual text being heredoc'ed, and so that the end of the text would be clearly demarcated (since the text itself, being taken verbatim, can not be properly indented/delimited within the text). I agree, but I can see how this argument is going in circles; my point (and that of Nikita) is that if the enclosure naturally occurs within the quotation, it’s a bad enclosure and a better one should be picked. The rule of requiring a newline directly following the closing delimiter is more of a hindrance than it is helpful imo. My belief is that the change have positive value of changing something for the better minus changing something for the worse and so far I'm not really convinced as of now that this change has it, especially given the BC break potential. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] destructors and output_buffering
On 31 Aug, 2014, at 12:40 pm, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! This is just a thought; could we delay the call to `zend_call_destructors` ONLY IF there’s output buffering taking place (i.e. ob_get_level() 0)? That wouldn't help - imagine this: 1. ob_start is set 2. shutdown is starting 3. ob functions shut down, call function foo 4. function foo creates an object of class FooBar 5. ob shutdown ends, all output is flushed, etc. 6. FooBar::__destruct is run and tries to output something So let it output something ... Trying to output something in a destructor after flushing the output seems rather fishy; at the same time I’m quite aware that it’s impossible to predict what some developers would expect to happen in such cases. That scenario still may have a problem. I'll check more into if it's really a big deal outputting after OB shutdown (after all, some other things may lead to it too) but conditioning dtor move does not solve this problem. If it works this way we may as well move them there permanently. Yeah, I can see now how my suggestion doesn’t really need the condition then :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Kill ereg with fire
Hi internals (again), Recently I’ve done a small assessment on how feasible it is to remove ext/ereg from the project for the next major version. This is the result (so far): https://github.com/datibbaw/php-src/compare/kill-ereg I’ve replaced two instances of ereg with their pcre equivalents, OPcache and PGSQL. Btw, simply using ‘pcreposix.h’ didn’t work out for OPcache, I would get this error: Error Blacklist compilation: invalid argument to regex routine Perhaps I’ve missed something obvious, but porting it wasn’t hard either. Thoughts?
[PHP-DEV] [RFC] Loosening heredoc/nowdoc scanner
Hi internals, I would like to propose a few changes to our heredoc / nowdoc scanner to make it less awkward to use inside other constructs. https://wiki.php.net/rfc/heredoc-scanner-loosening Let me know your thoughts :) Best, Tjerk (@datibbaw) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Documentation error
Hi Alain, On 29 Aug, 2014, at 8:43 am, Alain Williams a...@phcomp.co.uk wrote: I notice that in the precedence chart the new **= operator is missing: http://uk1.php.net/manual/en/language.operators.precedence.php The announcement (below) says that it is right associative, but the precedent chart above says that it is left associative. From the example it seems to be right associative. Thanks for spotting that; I’ll fix that later today if nobody beats me to it. http://php.net/migration56.new-features -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Fast Parameter Parsing API
Hi all, Now that we’re slowly settling into the new big changes that were recently pushed into master, perhaps it’s a good time to review the Fast_ZPP proposal and put it to a vote. It’s already present in functions that are deemed to benefit most from this optimisation, which is what it was meant for anyway. The RFC mentions this as well (in friendly bolded text), but it’s worth mentioning again that this is NOT a replacement for ZPP; if you don’t want to use this new API, you can always use Johannes’ plugin for clang to still get warnings about type mismatches. Best, Tjerk (@datibbaw) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: zpp and zend_string
Hi internals, With the recent merge of int64 the `zend_string` type now uses `size_t` to store its length, but ZPP (and friends) still use `int *` to store the parsed string lengths. http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_API.c#519 This look like an oversight. Will this be fixed as well? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: date extension broken tests
Hi! On 25 Aug, 2014, at 5:43 pm, Dmitry Stogov dmi...@zend.com wrote: Hi Derick, Could you please take a look into these tests failures. I actually, think that the new behavior is right. Calls to parent::__constructor() shouldn't change value of already constructed $this. I think the following commit is relevant to the discussion: http://git.php.net/?p=php-src.git;a=commit;h=c749fe2067d29615df250e59c9a891a63dcc7e7f I’ve also added that to the discussion on the #67118 itself: https://bugs.php.net/bug.php?id=67118#1408926078 The expectation of ext/data/tests/bug67118_2.phpt looks completely wrong. The actual output of ext/data/tests/bug67118.phpt seems right. I was going to look at those test cases this week, but I’m glad this is now in more than capable hands :) I'm going to change expectation of these tests in master if you don't object. Thanks. Dmitry. -- Forwarded message -- From: Dmitry Stogov dmi...@zend.com Date: Mon, Aug 25, 2014 at 1:28 PM Subject: Re: date extension broken tests To: Lior Kaplan lio...@zend.com Cc: Anatol Belski a...@php.net Hi Lior, This is known phpng related problem described here https://wiki.php.net/phpng#known_problems Thanks. Dmitry. On Mon, Aug 25, 2014 at 1:09 PM, Lior Kaplan lio...@zend.com wrote: Hi Anatol, It seems you've done some changes to the date extension recently, could you take a look at these two failures. Dmitry - FYI in case it's phpng related. Bug #67118 crashes in DateTime when this used after failed __construct [ext/date/tests/bug67118.phpt] Regression introduce in fix for Bug #67118 - Invalid code [ext/date/tests/bug67118_2.phpt] Kaplan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Binary String Comparison
On Tue, Aug 19, 2014 at 11:07 AM, Tjerk Meesters tjerk.meest...@gmail.com
wrote:
On Mon, Aug 18, 2014 at 11:30 PM, Johannes Schlüter
johan...@schlueters.de wrote:
On Mon, 2014-08-18 at 23:09 +0800, Tjerk Meesters wrote:
On 18 Aug, 2014, at 10:47 pm, Johannes Schlüter
johan...@schlueters.de wrote:
On Mon, 2014-08-18 at 14:44 +0200, Marc Bennewitz wrote:
The question isn't What's wrong with ===, strcmp()? but What's
wrong
with ==, , ?.
We have a standard way to compare two operands but currently we do
some
magic things to solve something that don't need to be solved.
Still it is a key property of the language which we can't simply
change.
Also mind this: All input data are strings and some databases also
return data as string. So code like
if ($_GET['id'] 0)
or
if ($db-fetchRow()[0] == 12)
which is common will break.
Those two cases will actually not be affected, it's strictly
string=string comparisons that's being discussed here.
Meaning that simple code you find everywhere, in every second tutorial
foreach ($db-query(SELECT id, title FROM entries) as $row) {
echo trtd;
if ($row[0] == $_GET['highlight_id']) {
echo background='#ff';
}
echo .htmlentities($row[1])./td/tr;
}
will suddenly fail. How wonderful! (irony)
Not necessarily and certainly not by definition; reasons for failure are
less obvious such as (but not limited to):
0 == 0.0
11 == 11 (but note that 11 == 11 currently yields false)
0 ==
I had mistakenly assumed that 0 == would currently yield true, but it
doesn't. My apologies for that. The other two statements are still valid,
though. So are these:
0 == 0x0
0 == 00
I'm not arguing for or against this behaviour change, but I found it
necessary to clear up some apparent confusion as to what repercussions this
proposal carries.
Another approach of attempting to solve the common issue of comparing big
numbers with '==' is to only enforce string-wise comparison if a number
cast would cause precision loss.
johannes
ps. yes, the example might be done nicer and better, it still represents
a common pattern.
--
--
Tjerk
--
--
Tjerk
Re: [PHP-DEV] [RFC] Binary String Comparison
On 18 Aug, 2014, at 10:47 pm, Johannes Schlüter johan...@schlueters.de wrote: On Mon, 2014-08-18 at 14:44 +0200, Marc Bennewitz wrote: The question isn't What's wrong with ===, strcmp()? but What's wrong with ==, , ?. We have a standard way to compare two operands but currently we do some magic things to solve something that don't need to be solved. Still it is a key property of the language which we can't simply change. Also mind this: All input data are strings and some databases also return data as string. So code like if ($_GET['id'] 0) or if ($db-fetchRow()[0] == 12) which is common will break. Those two cases will actually not be affected, it's strictly string=string comparisons that's being discussed here. Maybe using different sets of operators would have been better, but that should have happened 20 years ago not now. Also mind consistency: If you change this you probably also have to change other places where implicit conversion happens, i.e. array keys. In the end you get a complete new incompatible language and can throw away most libraries and so on. So in case you have a Tardis, DeLorean with Flux Capacitor or any other time machine I'm happy to support you in the past, but not this late. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Binary String Comparison
On Mon, Aug 18, 2014 at 11:30 PM, Johannes Schlüter johan...@schlueters.de
wrote:
On Mon, 2014-08-18 at 23:09 +0800, Tjerk Meesters wrote:
On 18 Aug, 2014, at 10:47 pm, Johannes Schlüter
johan...@schlueters.de wrote:
On Mon, 2014-08-18 at 14:44 +0200, Marc Bennewitz wrote:
The question isn't What's wrong with ===, strcmp()? but What's
wrong
with ==, , ?.
We have a standard way to compare two operands but currently we do
some
magic things to solve something that don't need to be solved.
Still it is a key property of the language which we can't simply
change.
Also mind this: All input data are strings and some databases also
return data as string. So code like
if ($_GET['id'] 0)
or
if ($db-fetchRow()[0] == 12)
which is common will break.
Those two cases will actually not be affected, it's strictly
string=string comparisons that's being discussed here.
Meaning that simple code you find everywhere, in every second tutorial
foreach ($db-query(SELECT id, title FROM entries) as $row) {
echo trtd;
if ($row[0] == $_GET['highlight_id']) {
echo background='#ff';
}
echo .htmlentities($row[1])./td/tr;
}
will suddenly fail. How wonderful! (irony)
Not necessarily and certainly not by definition; reasons for failure are
less obvious such as (but not limited to):
0 == 0.0
11 == 11 (but note that 11 == 11 currently yields false)
0 ==
I'm not arguing for or against this behaviour change, but I found it
necessary to clear up some apparent confusion as to what repercussions this
proposal carries.
Another approach of attempting to solve the common issue of comparing big
numbers with '==' is to only enforce string-wise comparison if a number
cast would cause precision loss.
johannes
ps. yes, the example might be done nicer and better, it still represents
a common pattern.
--
--
Tjerk
[PHP-DEV] Evaluation of constructor arguments if there's no constructor
Hi internals, I was sifting through the bucket o’ bugs and found these two related issues: https://bugs.php.net/bug.php?id=67829 https://bugs.php.net/bug.php?id=54162 (closed) They concern the behaviour of the engine when a class defines no constructor or if the class to be instantiated doesn’t exist, which can be seen here: http://3v4l.org/jOQY0 This is obviously a design decision, but doesn’t seem to have a mention in the documentation nor the spec (I couldn’t find it under the ‘new’ operator). I can add a paragraph in the documentation for it; the question is whether it should also be added to the spec, seeing how HHVM and PHP behave differently in this respect? It could be added as implementation dependent behaviour I suppose? — @datibbaw -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Simplified Array API for extensions
On 12 Aug, 2014, at 5:03 am, Andrea Faulds a...@ajf.me wrote: On 11 Aug 2014, at 22:00, Hannes Magnusson hannes.magnus...@gmail.com wrote: I think it would be fantastic if this would be included in 5.6. Too late for 5.6, but 5.7 perhaps (can we please have this? 7 will break BC and I’d like to get some stuff in next year, not in 2 years). Can this API be retained as is when NG gets merged? I would hate to see developers put in effort to take advantage of this simplified API in 5.x only to have to make changes again for 7. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is fgetss() useless?
Hi Maciej, On Mon, Jul 28, 2014 at 7:21 PM, Maciej Sobaczewski msobaczew...@gmail.com wrote: Hello guys, so... fgetss(). We have such a beautiful function in PHP. As it's described in the manual: Get line from file pointer and strip HTML tags. I'm wondering if it has any differences/advantages over using just strip_tags(fgets($stream)). The `fgetss()` function keeps the strip_tags state between reads to provide consistent results; observe the following example: hello html ?php echo we don't want this; ? /html world This should rightfully output only hello world (and some newlines); if you would apply `strip_tags()` on each individually read line, you would also get stuff you don't want. I'm going to write an RFC proposing deprecation and then removal of it, but first I want to ensure that this function is as useless (IMHO) as I think. Best regards, Maciej. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- -- Tjerk
Re: [PHP-DEV] signed long hash index for PHP7?
Hi, On Wed, Jul 30, 2014 at 10:37 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, Current Zend hash uses ulong for numeric array indexes. This causes bug #67693 https://bugs.php.net/bug.php?id=67693 Signed/unsigned mismatch is the root cause of this bug. Since PHP's int is signed by default, it might be better to change Zend hash index to signed long. Instead of doing that, why not simply disallow negative array indices to be used as integers? In other words, negative indices are treated as if you had used strings so that it doesn't upset the the last numeric index kept in the array structure. From what I can tell, it should be a pretty simply patch. Thoughts? I would like to hear comments who understand Zend internals. If there aren't issues, we may have signed long index for PHP7. I also would like to hear comments for possible fix in released versions. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- -- Tjerk
Re: [PHP-DEV] RFC: Move phpng to master
Hi Dmitry, On 25 Jul, 2014, at 6:09 am, Dmitry Stogov dmi...@zend.com wrote: any one may vote according to their thoughts I'm not going to persuade any one. I already know the opinion of the majority. Unfortunately, now many people lessen to the guys who speaks a lot. I was never able to do it :), but ... look into results we provide. They are more expressive than any words. First of all, kudos for all the hard you and the team have been putting into this :) From a developer’s point of view it would be nice to see a write-up of some of the changes that were made to the API's; I’m currently aware of the array (hash) API changes which are definitely an improvement over the old one, but there may be more that could also use an “idiom conversion guide”. Thanks. Dmitry, On Fri, Jul 25, 2014 at 1:39 AM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 24, 2014 at 1:37 PM, Dmitry Stogov dmi...@zend.com wrote: one week - two weeks - months - years. I'll wait. I know what I'm doing. I'll make it. Dmitry. On Fri, Jul 25, 2014 at 12:26 AM, Pierre Joye pierre@gmail.com wrote: On Jul 24, 2014 10:13 PM, Dmitry Stogov dmi...@zend.com wrote: agree, I just don't see any blockers, except for Pierre. Come on Dmitry, I am not the only who has asked that. Just to throw in my usual two-cents, it seems to me that this RFC is very premature. It's the same sort of over-eagerness I saw in the front-page news post a few weeks back. I understand what you guys are trying to accomplish and I applaud you for it, but as far as I can see, it's still quite a ways away from being ready for prime time. And yet, you seem to be acting like it's already there. Aside from the code needing to be ready/tested, you also need to have a more matured collaboration with community folks outside your project like Pierre, which at the moment appears to be downright hostile. Even if the code looked great and everything else was in place, I would never vote to switch over to such a drastic new schema when there's this much animosity and controversy surrounding it. I keep reading complaints about questions being ignored and conflicting stories about secrecy and process. I also think there's some merit to the concern raised about the ambiguity being a prelude to patches being rejected over trivial concerns. I think you guys need to slow down and mend a few fences if you want to make this happen. As much as I like the goals of this project, I'm forced to vote -1 for now, as well. I just think you're jumping the gun when there are too many unanswered questions/concerns still out there. --Kris Best, Tjerk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php interactive shell: save history on SIGINT exit
On 23 Jul, 2014, at 8:38 pm, Johannes Schlüter johan...@schlueters.de wrote: On Mon, 2014-07-21 at 18:17 +0400, Dmitry Saprykin wrote: changed write_history at the end to append_history after each cli_is_valid_code. Now it is -1 line, +1 line commit and completely looks like bug fix. ) Have you tested with libedit? - A quick grep on my system shows no append_history() call, haven't checked further, though. Yes, compilation fails with libedit (mac): Undefined symbols for architecture x86_64: _append_history, referenced from: _readline_shell_run in readline_cli.o johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Fix bug #67064 = Countable interface inconsistency
Hi!
On Wed, Jul 23, 2014 at 4:26 PM, Remi Collet r...@famillecollet.com wrote:
Notice,
All Internal classes, implementing Countable still doesn't accept this
optional parameter.
Ex:
Method [ internal:SPL, prototype Countable public method count ]
{
- Parameters [0] {
}
Indeed, all Spl classes still use zend_parse_parameters_none().
This work, because count($a) doesn't use the method, but the
count_elements handler.
Actually, the count_elements handler doesn't actually use the mode, so
that's another inconsistency; fixing that will cause a binary
incompatibility, though. Are we allowed to fix that so close to a release?
Unless the current changes are reverted, at the very least all SPL classes
that implement Countable must support the optional argument for `::count()`.
If a internal class doesn't implement the handler, it will be hit by
this change.
Both solution should fix this:
- adding the count_elements handler
- accepting the optional mode
Not sure whether you meant to say that any of those solutions work, because
either only the latter is implemented or both; i.e. you can't implement
count_elements handler and then not accept the optional mode :)
But, Reflection still not correct, and count($a) still raise the
Warning: Imagick::count() expects exactly 0 parameters, 1 given in
/work/GIT/imagick/tests/021-countable.phpt on line 19
I think this is not consistent (internal vs userland)
Agreed!
Remi.
P.S. discovered on imagick
See: https://github.com/mkoppanen/imagick/pull/35
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
--
Tjerk
Re: [PHP-DEV] Deprecating GD functions imagettftext/bbox
Hi Lonny, On Wed, Jul 23, 2014 at 3:01 AM, Lonny Kapelushnik lo...@lonnylot.com wrote: Morning, I propose deprecating two GD functions: imagettftext and imagettfbbox. The reasons I would like to deprecate them are: 1. Their functionality is a subset of imagefttext and imageftbbox 2. The imagettf* functions have the same requirements as the imageft* functions 3. The imagettf* functions parameters are compatible with the imageft* functions parameters As far as I can tell the original reason for having both functions was because PHP LIBGD is a custom implementation of LIBGD that had additional functionality from the actual LIBGD. While this is still the case it seems that now the required functions (gdImageStringFT and gdImageStringFTEx) exist in both libraries. The only difference between imagettf* and imageft* functions is the imagettf* functions do not provide the optional ‘extrainfo’ parameter The only step to migrate from the imagettf* functions to imageft* functions is to change the function names from ‘imagettf*’ to ‘imageft*' I'm glad to see you've taken the time to write this down after our small discussion on chat the other day :) According to the release process, an x+1.0.0 release may break API, so that would technically mean they can be removed for php.next granted an RFC is submitted and accepted before then. That said, I didn't see any clear guidelines as to how deprecation periods should be outlined, so I would expect some discussions to arise from that .. I would like to create a timeline to deprecate and remove the imagettf* functions. Providing a timeline will allow for: 1. Clarity for which PHP functions to use going forward 2. Ability to plan a migration to the new PHP functions 3. Clarity for which PHP functions to improve in php-src 4. Ability to clean up some of the GD code in php-src From what I could tell, the clean up will be relatively small because both functions already call the same underlying php_image*_common() function. I will hold off on proposing an actual timeline for now. I can implement any coding changes needed. Please let me know the general thoughts to deprecating these functions. If the reception is positive I would like to create an RFC to discuss this in full and come up with a timeline. Personally I think, although the current functions are used a lot more often (~ 3x based on Google results), the simple fix makes it relatively easy to port existing code. From what I could tell you don't have a Wiki account yet, so that would be the first step :) ––– Hakuna Matata! Lonny Kapelushnik https://www.lonnylot.com 732.685.9175 -- -- Tjerk
Re: [PHP-DEV] What's wrong with these hashtable iteration code?
On Mon, Jul 21, 2014 at 11:12 AM, Aaron Lewis the.warl0ck.1...@gmail.com
wrote:
Hi,
I'm trying to iterate through a hash table,
But the zend_hash_get_current_key() doesn't seem to move forward:
I'm getting duplicate output at the 'fprintf' part.
for(zend_hash_internal_pointer_reset_ex(ht, pos);
zend_hash_has_more_elements_ex(ht, pos) == SUCCESS;
zend_hash_move_forward_ex(ht, pos))
{
if (zend_hash_get_current_key (ht, string_key, num_key, 0)
!= HASH_KEY_IS_STRING)
continue;
fprintf (stderr, string key: %s\n, string_key);
}
The _ex() hash iteration functions allow for iterating a hash without
modifying its internal pointer, but zend_hash_get_current_key() uses only
the internal pointer.
The function you need to use is: zend_hash_get_current_key_ex() and pass
pos to it.
Any ideas?
--
Best Regards,
Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/
Finger Print: 9F67 391B B770 8FF6 99DC D92D 87F6 2602 1371 4D33
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
--
Tjerk
Re: [PHP-DEV] crypt() BC issue
On Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Tjerk, On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Why should `password_verify()` work on a hash that wasn't generated with `password_hash()`? The fact that it uses `crypt()` internally should not leak outside of its API, imho. password_*() is designed as crypt() wrapper and this fact is documented since it was released. Obsolete password hash is easy to verify with password_needs_rehash(). Developers can check password database easily with password_needs_rehash(). The documentation states that the `hash` argument to both `password_needs_rehash()` and `password_verify()` is: hash - A hash created by password_hash(). Passing a value from your own crypt() implementation may work, but that shouldn't be relied upon. I certainly wouldn't classify it as a problem that should be fixed in the password api. i.e. They don't have to parse password hash to detect obsolete hash. Therefore, using password_*() for crypt() generated passwords makes sense. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- -- Tjerk
Re: [PHP-DEV] [RFC] intdiv()
On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds a...@ajf.me wrote: On 17 Jul 2014, at 10:24, Nikita Popov nikita@gmail.com wrote: This is already what is currently happening, see http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#1067. Andreas proposal is only useful in the case that the numbers don't divide exactly and you need round-down/truncation behavior and your numbers are in a range where the indirection through double arithmetic results in precision loss. It’s still useful regardless as it saves you implementing it in terms of floats. I mean, you can implement a right shift (rarely used outside bit masks) in terms of multiplication and exponentiation, but that doesn’t mean you shouldn’t have a right shift. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php There seems to be a pretty even split on this. Personally, I'm a +1 for it. PHP has tons of obscure, rarely used functions. Even if the gain is relatively minor, there's really no cost that I can think of. So from a cost-benefit standpoint, even a minor improvement is still desirable when there's no practical downside to it. Given the number of options that are coming up, I'd suggest you break the RFC down into two votes: A simple yes/no vote followed by an if yes, how should it be implemented? vote with the various options (the operators, functions, etc). If the RFC passes, then whichever option got a plurality of the votes would be the implemented option. This makes it more complicated because a language change requires 2/3 majority while a new function requires 50% + 1. To make things simpler - and I believe it had been proposed before - the main vote should include the implementation as a function and the secondary vote should be for the operator. So yeah, I'd say bring it to a vote and that'll settle it one way or another. --Kris -- -- Tjerk
Re: [PHP-DEV] [RFC] intdiv()
On Fri, Jul 18, 2014 at 12:04 PM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 17, 2014 at 8:39 PM, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds a...@ajf.me wrote: On 17 Jul 2014, at 10:24, Nikita Popov nikita@gmail.com wrote: This is already what is currently happening, see http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#1067. Andreas proposal is only useful in the case that the numbers don't divide exactly and you need round-down/truncation behavior and your numbers are in a range where the indirection through double arithmetic results in precision loss. It’s still useful regardless as it saves you implementing it in terms of floats. I mean, you can implement a right shift (rarely used outside bit masks) in terms of multiplication and exponentiation, but that doesn’t mean you shouldn’t have a right shift. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php There seems to be a pretty even split on this. Personally, I'm a +1 for it. PHP has tons of obscure, rarely used functions. Even if the gain is relatively minor, there's really no cost that I can think of. So from a cost-benefit standpoint, even a minor improvement is still desirable when there's no practical downside to it. Given the number of options that are coming up, I'd suggest you break the RFC down into two votes: A simple yes/no vote followed by an if yes, how should it be implemented? vote with the various options (the operators, functions, etc). If the RFC passes, then whichever option got a plurality of the votes would be the implemented option. This makes it more complicated because a language change requires 2/3 majority while a new function requires 50% + 1. To make things simpler - and I believe it had been proposed before - the main vote should include the implementation as a function and the secondary vote should be for the operator. So yeah, I'd say bring it to a vote and that'll settle it one way or another. --Kris -- -- Tjerk The problem is that, since that suggestion, other variations have been proposed with no clear favorite. How should we decide *which* proposed operator, for example? There have been several mentioned. If the author can't settle on a particular operator, then a third vote would be necessary for those who vote to have an operator in the first place; perhaps a simple majority required for that. --Kris -- -- Tjerk
Re: [PHP-DEV] [RFC] intdiv()
Hi Sara,
On Thu, Jul 17, 2014 at 8:25 AM, Sara Golemon poll...@php.net wrote:
On Wed, Jul 16, 2014 at 8:15 AM, Andrea Faulds a...@ajf.me wrote:
Nikita Popov doesn’t seem to be a fan of the %% syntax, so it may be
subject to change, though I think it’s the best I’ve heard so far. ;)
Nor am I. Here's a thought though: How about just making / return int
when there's no remainder.
Looking at this code, you might think it's inefficent:
double dres = a / b;
long lres = a / b;
if (a % b) {
return dres;
} else {
return lres;
}
But in fact at -O1, gcc will optimize this (probably clang and others
as well) to a single idivq instruction and only do the cvtsi2sdq in
the dres case.
Just out of curiosity, does the compiler optimise it into something like
this?
if (a % b) {
return a / b;
} else {
return (double)a / b;
}
Or, would writing it like that skip the optimisation of being able to fetch
the division result from %rax?
My point being, we can just make division with an integral result
return a result of integer division without altering the syntax or
adding a perf hit.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
--
Tjerk
Re: [PHP-DEV] crypt() BC issue
Hi,
On Thu, Jul 17, 2014 at 9:06 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Sara,
On Thu, Jul 17, 2014 at 8:53 AM, Sara Golemon poll...@php.net wrote:
At the risk of perhaps missing the point, wouldn't it be more useful
to encourage users in some way (perhaps through documentation only) to
use password_hash()/password_verify() instead? It was designed with
migration paths in mind.
I'll add them.
Apps which are currently using crypt() for their own password systems
(the ones you would have migrate to crypt() + 1000 rounds) should be
pointed at the right solution, not placated with an okay for now, but
may need to be migrated again later route.
As far as I'm aware, the only reason for not marking crypt()
E_DEPRECATED right now is for compatibility with external systems, and
as far as those go, changing a default won't effect anything.
Instead of relaxing crypt(), how about relax password_verify()?
?php
$h='$6$rounds=10$qNElXs2yMnL2.GNS3kiM7DqmGbFLdQfIwu2691aJgT3xgJazPLtw7RPKz3Dp8RIc4b5fmJ7qvlq/mPN8a.rE40';
$p='salasana';
$c=crypt($p,$h);
echo HASH: $h\n;
echo CRYPT: $c\n;
if ($c == $h) {
echo MATCH OK\n;
} else {
echo NO MATCH\n;
}
var_dump(password_verify($p, $h)); // Fails since password_verify() is
crypt() wrapper
$h2='$6$rounds=1000$qNElXs2yMnL2.GNS$/q7trYkbKkoJernsumbObt2IysdXGRx/ytFaG0HBC97rHHhYRQvUcyEuRHP6h5yj8V.fH7XKEw5hjofVmYONw1';
var_dump(password_verify($p, $h2)); // Success since it has 1000 rounds
?
Current password_verify() is using the same hard coded 1000 rounds
limitation, but
it could be relaxed. This would be the best solution.
Why should `password_verify()` work on a hash that wasn't generated with
`password_hash()`? The fact that it uses `crypt()` internally should not
leak outside of its API, imho.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
--
Tjerk
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On 13 Jul, 2014, at 11:17 pm, Rowan Collins rowan.coll...@gmail.com wrote:
On 13/07/2014 15:59, Jocelyn Fournier wrote:
From my point of view, if the type annotations are doing implicit cast (with
or without E_NOTICE/E_STRICT warning), they should behave exactly the same
than an explicit cast. If it behaves differently, I'll be really difficult
for a developer to guess what will be the PHP behaviour with this new syntax.
The problem is, in PHP an explicit type cast never fails - (int)'abc' simply
gives you the value 0, not an error. If you let scalar typehints just
generate unchecked casts, we'd have this:
wants_object(object $foo) { var_dump($foo); }
wants_int(int $foo) { var_dump($foo); }
wants_object('abc'); // fails with E_RECOVERABLE_ERROR
wants_int('abc'); // succeeds and prints int(0)
Depending on the final implementation, the latter may raise a notice about
information loss.
That seems both inconsistent and less useful than a hybrid juggling +
validation approach.
While this is indeed inconsistent, scalars and objects aren’t the same thing,
though, and I think it’s okay to treat them differently.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Travis CI for pull requests
Hi guys, After making another commit into my ucwords() pr and waiting for an hour or so I noticed that Travis CI hasn’t picked it up yet; in fact, the previous commit wasn’t picked up either. Other pr’s that were created before or after mine were processed, though. Is this a known issue? It would be nice to have the added confidence of a passing test suite before merging changes :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Travis CI for pull requests
Hi! On 11 Jul, 2014, at 4:29 pm, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! And while I was trying to figure out what does that mean, or why should that prevent the travis build, I've just remembered that we don't allow travis builds for PHP-5.3 and PHP-5.4 branches: http://git.php.net/?p=php-src.git;a=blob;f=.travis.yml;h=f1a333adcb3e6c35f3fe19c27fbd7a28d99fe7de;hb=refs/heads/PHP-5.4 So probably it is because of that. All feature pulls should be done against master only. They will be merged to appropriate branch but as pulls it should always be master unless it is a fix specific to particular version. I see, though I would have the same issue if this was a fix instead of a feature, right? :) In any case, I reasoned that it would be easier to start at the lowest version where this feature could peacefully coexist and then merge it up to 5.5, 5.6 and finally master. Should I do this in another way then? :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] not_null function
On Sat, Jul 5, 2014 at 9:22 AM, Kris Craig kris.cr...@gmail.com wrote: On Fri, Jul 4, 2014 at 2:38 PM, Xen x...@dds.nl wrote: On Fri, 4 Jul 2014, Levi Morrison wrote: For completeness, it is available in Perl and I believe Perl had it first; not completely sure though. Okay, I never used Perl. I don't think changing isset would be beneficial, sadly. I wish it only checked that a variable exists and didn't do the not null check but it's used very, very widely. As long as people don't have to use isset anymore to check for a not-null, perhaps over time this widespreadedness would become less. As soon as you can use unless (is_null()) to check whether a variable exists and is not null, the need for using isset for this should greatly diminish... Just my perspective. I don't know what other people think, the boogieman of this list seems to not want to discuss anything related to this, so I don't know. I mean for me it means having to rethink my thinking, i.e. to get used to this new statement. But it would probably become very natural? I would imagine a lot of people becoming enthusiastic about an unless statement. It is also a sexy thing to introduce and it doesn't require any changes to existing code. Again, just my perspective. Curious what other people really think at this point. Regards, Bart -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I'm not much into Perl or Ruby, either, but I agree that an unless keyword would be a very nice thing to have. However, I'm still not sure how that would solve the isset problem. If the variable doesn't exist, are you saying that encapsulating it within the unless arg would prevent an undefined variable notice from being thrown? If so, could someone elaborate on why that is? And if not, then while I do agree it's a good idea on its own merits, I don't think it solves the issue we're mulling over here. Currently, this is what's available for checking a variable's status without throwing any errors: Variable exists and !== NULL: isset( $var ) Variable === NULL or doesn't exist: !isset( $var ) Variable == NULL or doesn't exist: empty( $var ) Variable exists and != NULL: !empty( $var ) Variable exists (including NULL): Yep, nothing exists for that; we have a whole bunch of `_exists()` functions, but not e.g. `variable_exists()` or even a dedicated `exists` opcode. Variable exists and === NULL: That's simply `@$var === null` or `@is_null($var)` of course ;-) It's those last two cases that we currently don't have any streamlined approach for. If a variable is NULL and you use isset() on it, the return will be FALSE. So if you were to do something like isset( $var ) $var === NULL, that statement will always return FALSE, even you set the variable with $var = NULL beforehand. You'll get the same problem using empty(). In other words, as far as I can tell, there's currently no way to tell if a variable is set and NULL (or just set with any value including NULL) in PHP. The closest thing I could find that accomplishes this is property_exists(). That function will return TRUE even on NULL values. But as I understand it, that function only works on properties; i.e. variables that are a part of a class. There doesn't seem to be any option for doing this with procedural variables. We know that setting a variable to NULL in PHP is not the same as unsetting it because referring to it later won't throw an undefined notice, but aside from catching that notice itself, there doesn't seem to be any way to accomplish this. Am I missing something? I realize it's an edge case, but it still needs to be covered. --Kris -- -- Tjerk
Re: [PHP-DEV] not_null function
On Sat, Jul 5, 2014 at 3:39 PM, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Sat, Jul 5, 2014 at 9:22 AM, Kris Craig kris.cr...@gmail.com wrote: On Fri, Jul 4, 2014 at 2:38 PM, Xen x...@dds.nl wrote: On Fri, 4 Jul 2014, Levi Morrison wrote: For completeness, it is available in Perl and I believe Perl had it first; not completely sure though. Okay, I never used Perl. I don't think changing isset would be beneficial, sadly. I wish it only checked that a variable exists and didn't do the not null check but it's used very, very widely. As long as people don't have to use isset anymore to check for a not-null, perhaps over time this widespreadedness would become less. As soon as you can use unless (is_null()) to check whether a variable exists and is not null, the need for using isset for this should greatly diminish... Just my perspective. I don't know what other people think, the boogieman of this list seems to not want to discuss anything related to this, so I don't know. I mean for me it means having to rethink my thinking, i.e. to get used to this new statement. But it would probably become very natural? I would imagine a lot of people becoming enthusiastic about an unless statement. It is also a sexy thing to introduce and it doesn't require any changes to existing code. Again, just my perspective. Curious what other people really think at this point. Regards, Bart -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I'm not much into Perl or Ruby, either, but I agree that an unless keyword would be a very nice thing to have. However, I'm still not sure how that would solve the isset problem. If the variable doesn't exist, are you saying that encapsulating it within the unless arg would prevent an undefined variable notice from being thrown? If so, could someone elaborate on why that is? And if not, then while I do agree it's a good idea on its own merits, I don't think it solves the issue we're mulling over here. Currently, this is what's available for checking a variable's status without throwing any errors: Variable exists and !== NULL: isset( $var ) Variable === NULL or doesn't exist: !isset( $var ) Variable == NULL or doesn't exist: empty( $var ) Variable exists and != NULL: !empty( $var ) Variable exists (including NULL): Yep, nothing exists for that; we have a whole bunch of `_exists()` functions, but not e.g. `variable_exists()` or even a dedicated `exists` opcode. Variable exists and === NULL: That's simply `@$var === null` or `@is_null($var)` of course ;-) Obviously spoke to soon ... what I've written there is basically an ugly `!isset($var)`. Sorry for the extra noise. It's those last two cases that we currently don't have any streamlined approach for. If a variable is NULL and you use isset() on it, the return will be FALSE. So if you were to do something like isset( $var ) $var === NULL, that statement will always return FALSE, even you set the variable with $var = NULL beforehand. You'll get the same problem using empty(). In other words, as far as I can tell, there's currently no way to tell if a variable is set and NULL (or just set with any value including NULL) in PHP. The closest thing I could find that accomplishes this is property_exists(). That function will return TRUE even on NULL values. But as I understand it, that function only works on properties; i.e. variables that are a part of a class. There doesn't seem to be any option for doing this with procedural variables. We know that setting a variable to NULL in PHP is not the same as unsetting it because referring to it later won't throw an undefined notice, but aside from catching that notice itself, there doesn't seem to be any way to accomplish this. Am I missing something? I realize it's an edge case, but it still needs to be covered. --Kris -- -- Tjerk -- -- Tjerk
[PHP-DEV] Bug tracker stats oddity
Hi, It felt a bit weird to report a bug about the bug tracker, so I decided to post it here. I came across this random bug: https://bugs.php.net/bug.php?id=64386 The stats are: Votes:105Avg. Score:2.1 ± 1.0Reproduced:1 of 12 (8.3%)Same Version:25769803765 (2576980376500.0%)Same OS:30064771059 (3006477105900.0%) That doesn't look quite kosher, unless 5x the world's population has had the same OS ;-) -- -- Tjerk
Re: [PHP-DEV] RFC: Expectations
On Mon, Oct 21, 2013 at 4:16 PM, Michael Wallner m...@php.net wrote: On 21 October 2013 10:13, Patrick Schaaf b...@bof.de wrote: Am 21.10.2013 03:52 schrieb Joe Watkins krak...@php.net: So looks like we need a new name ?? Ideas ?? abstract EXPRESSION wat? abstract is already a keyword, so no BC. abstract is not concrete so alludes a bit to the might-be-or-might-not-be-checked nature of the test abstract is the name for the short summary intro part of scientific papers, and these conditions are kind of a summary of what is known (preconditions) and concluded (postconditions). Ah, ok well. I'd rather go for expected() or except() then... Since we're throwing around terms, here's another one: predicate expr; It should be understood by most programmers what it means (though, admittedly, it doesn't carry an obvious severity) and isn't used anywhere in the language (afaik). -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- -- Tjerk
Re: [PHP-DEV] Wiki karma, por favor.
Bump. On 3 Oct, 2013, at 3:23 AM, Madara Uchiha mad...@tchizik.com wrote: +1! This guy is epic! On Mon, Sep 30, 2013 at 10:56 PM, Daniel Lowrey rdlow...@gmail.com wrote: Good day, security-conscious internals people. I'm ready to float an RFC + patch for default SSL/TLS peer verification and TLSv1.1/TLSv1.2 support as mentioned in this thread: http://news.php.net/php.internals/69375 If someone would be kind enough to grant me the requisite wiki karma (user: rdlowrey) I'll dive right in. Thanks in advance. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
On Sat, Sep 28, 2013 at 6:47 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Leigh, On Fri, Sep 27, 2013 at 7:12 PM, Leigh lei...@gmail.com wrote: So on a successful session hijack (correct SID, new IP) the attacker gets a new SID and keeps the valid session while the legitimate user gets kicked out. Not seeing how that improves things at all. There are 2 improvements 1. Generally speaking, more frequent session ID regeneration is more security. This could make it more difficult for an attacker to take advantage, but then I would like to see other changes as well, for instance: a) Enable session.use_strict_mode by default. b) Enable session.use_only_cookies by default c) Enable session.cookie_httponly by default. d) Use a stronger session.hash_function with more session.hash_bits_per_character by default. e) Enable session.cookie_secure on secure connections (I know this is not going to be fool proof). There are probably more settings we could change to more security aware values. 2. Detection/indication of attacks is good for security. This is an interesting aspect; when an old session identifier is presented, from the end-user's perspective, either: a) They get redirected to the site's login page; the user gets redirected to the login page and unless they suspect their session was compromised (if that's indeed what happened), they will sign in again (the browser may have remembered the credentials, so it's a single click operation and they're back), or b) If the system uses a (naive) remember me feature, a new session gets created automatically and they don't notice a thing. From the server-side's perspective, the cookie value could simply not be found, assuming that the regeneration also deletes the previous session data; there's no discernible difference between an old session and a compromised session afaict. This would be a different story if the session engine would keep track of past values as well. Btw, what I'm also missing from this proposal is the ability to hash against other factors, i.e. user agent. ISP's may use a transparent HTTP(s) proxy, most companies use an NAT, so being able to detect user agent changes may improve detection further. The bottom line is: if the system can make it easier to detect intrusion, it should be in the system and it should be easy :) Showing active sessions and possible intrusion/source of intrusion is applications task, but session ID regeneration upon IP change is easy and simple task for session module. Why not have it as optional feature? It would be better than nothing if end user has chance to know the attack. IMHO. Many systems have notification mail when password or important information have changed. Damage has already done if it is an attack, but user could know there were attack. Session ID regeneration is the same kind of counter measure. If app supports number of active sessions, user could verify if they are under session hijack attack or not. It's up to app, though. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- -- Tjerk
Re: [PHP-DEV] Failing builds on Travis
Hi Mike, On Fri, Sep 27, 2013 at 3:27 PM, Michael Wallner m...@php.net wrote: On 27 September 2013 04:37, Tjerk Meesters tjerk.meest...@gmail.com wrote: Hi, The success of builds on Travis seems to hinge on a particular test case: ext/standard/tests/file/disk_free_space_basic.phpt It asserts that if a file is written to, the free space after the write must always be lower than the previously recorded value. On a busy system the free space is affected by many factors that can cause this assertion to fail and thus developers get a nasty looking (X) on their pull requests. I actually committed a fix some time ago and didn't see a build of PHP-5.5+ failing for that reason? Ah, I just saw that you've changed the file size to 0x bytes now. The fact that my topic branch is 2806 commits behind master probably has something to do with that then ;-) Rebasing my branch should fix it. Sorry for the noise! Regards, Mike -- -- Tjerk
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Hi, On Fri, Sep 27, 2013 at 6:54 PM, Leigh lei...@gmail.com wrote: On 27 September 2013 11:39, Peter Lind peter.e.l...@gmail.com wrote: On 27 September 2013 12:12, Leigh lei...@gmail.com wrote: So on a successful session hijack (correct SID, new IP) the attacker gets a new SID and keeps the valid session while the legitimate user gets kicked out. Not seeing how that improves things at all. In your scenario, user gets booted and thus knows somethings wrong. Much better than the attacker hijacking the session without the user knowing anything at all. Regards Peter And what is done to invalidate the session now gained by the attacker? Since this is a proposal to handle such things internally. Do you really think random user X will think something is wrong beyond the site they were using just kicking them out for no reason? So now what do they do now? Log in again? The attacker still has the previously valid session, so nothing is gained. Yes, much more is required to actually provide tangible benefits in terms of security. The site would have to keep track of the last five invalidated session identifiers and if any of those is presented, it would delete all sessions for that user. The core can practically only do a fraction of that for you, so I would agree that on the whole, this patch would not lead to a secure-by-default sessions implementation. This is exactly why this kind of logic belongs as user code. We're starting to define rules for a system that should be agnostic to how it is being used. -- -- Tjerk
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Hi, On Thu, Sep 26, 2013 at 6:19 PM, Leigh lei...@gmail.com wrote: On Sep 24, 2013 3:43 AM, Laruence larue...@php.net wrote: I don't think this is language concerning issue. it could be done in user script.. thanks I agree entirely with Laurence (and others). This shouldn't be a core feature. It's not one size fits all. There's several scenarios where a users IP changes and you don't want to drop their session. (That doesn't mean it should simply have an option to disable it either) Let's be clear here: this won't happen (in most cases), because the client will simply get a new cookie and the session will keep working; it's like what you would implement if your user level goes from anonymous to logged in and vice versa. Many people still have dynamic IP addresses for their home connections, but the group who would suffer the most would be mobile users. It's pretty frustrating to use most sites with a phone as it is, without being kicked off every time you switch between grps or hsdpa or whatever. Aha! I'm glad that you brought up mobile devices, because for those it's more likely that in certain cases the updated cookie is not received while the server believes that it was; scenario: I stepped into an elevator and was disconnected when I got out.. This makes it an unattractive option to have enabled by default. -- -- Tjerk
Re: [PHP-DEV] PR 287 - added use_keys argument to array_filter() [Discussion]
Hi, On 27 Sep, 2013, at 12:31 AM, Andrea Faulds a...@ajf.me wrote: On 26/09/2013 05:42, Tjerk Meesters wrote: Hi, I've updated my patch to allow a range of values to be passed as the third argument: pass key, pass value or pass both. Instead of using OR-able constants, I went with an enumeration type because there are only going to be three options; it just felt wrong to have `ARRAY_FILTER_USE_KEY | ARRAY_FILTER_USE_VALUE` instead of a simpler `ARRAY_FILTER_USE_BOTH` or even just `true`. I suggest the following change: ext/standard/php_array.h:119: #define ARRAY_FILTER_USE_BOTH 1 #define ARRAY_FILTER_USE_KEY 2 #define ARRAY_FILTER_USE_VALUE 3 becomes: ext/standard/php_array.h:119: #define ARRAY_FILTER_USE_KEY 1 #define ARRAY_FILTER_USE_VALUE 2 #define ARRAY_FILTER_USE_BOTH 3 Such that we have the best of both worlds, either `ARRAY_FILTER_USE_BOTH` or `ARRAY_FILTER_USE_KEY | ARRAY_FILTER_USE_VALUE` :D I deliberately chose these values so that I can simply specify `true` to mean pass both values. Bit masks seem cumbersome in this situation. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PR 287 - added use_keys argument to array_filter() [Discussion]
On Fri, Sep 27, 2013 at 7:11 AM, Sherif Ramadan theanomaly...@gmail.comwrote: On Thu, Sep 26, 2013 at 6:51 PM, Tjerk Meesters tjerk.meest...@gmail.comwrote: I deliberately chose these values so that I can simply specify `true` to mean pass both values. Bit masks seem cumbersome in this situation. The default behavior is already to pass the value to the callback. Requiring the argument only breaks backwards compatibility here. There is no need for introducing 3 new constants. Simply use PASS_KEY or PASS_BOTH to solve this problem with the default behavior is pass value if the argument is omitted. I agree that only two constants are necessary here to accomplish the same effect; I'll update the code. I didn't quite understand how the current implementation would have BC issues, though. Would you care to elaborate on that?
[PHP-DEV] Failing builds on Travis
Hi, The success of builds on Travis seems to hinge on a particular test case: ext/standard/tests/file/disk_free_space_basic.phpt It asserts that if a file is written to, the free space after the write must always be lower than the previously recorded value. On a busy system the free space is affected by many factors that can cause this assertion to fail and thus developers get a nasty looking (X) on their pull requests. Can't we just assert that the function returns a float, hurray! instead? -- -- Tjerk
Re: [PHP-DEV] PR 287 - added use_keys argument to array_filter() [Discussion]
Hi, I've updated my patch to allow a range of values to be passed as the third argument: pass key, pass value or pass both. Instead of using OR-able constants, I went with an enumeration type because there are only going to be three options; it just felt wrong to have `ARRAY_FILTER_USE_KEY | ARRAY_FILTER_USE_VALUE` instead of a simpler `ARRAY_FILTER_USE_BOTH` or even just `true`. Updated examples can be found here: https://github.com/php/php-src/pull/287 Let me know if there are any major objections to the patch. On Wed, Jun 19, 2013 at 7:15 AM, Tjerk Meesters tjerk.meest...@gmail.comwrote: On 19 Jun, 2013, at 1:04 AM, Patrick Schaaf b...@bof.de wrote: var_dump(array_filter(['foo', '', 'bar'], 'strlen', true)); Warning: strlen() expects exactly 1 parameter, 2 given in - on line 1 Not only do we trigger the error handler (a large enough array causes a performance issue), but we also get back an empty array as a result. That's BC and performance loss that's simply unacceptable, so defaulting the behavior to pass the key is simply out of the question. Existing code won't pass that third, true, argument to array_filter(), and thus will not break. Nevertheless, I'd say go with a new array_filter_key() function, because that permits using existing one-parameter functions like that strlen as a callback, instead of forcing two-parameter callback functions. I've mirrored the behaviour of this feature from JavaScript as much as possible (but obviously without passing the array itself as the third argument). As such I don't feel there's a need to introduce yet another function just so that the key is passed as the first argument. And to use both key and value forces the developer to use closures instead of just any callback unless this means the second argument passed to the callback is the array :) Another alternative might be to go with a third argument to array_filter(), but make that an integer with ORable constants ARRAY_FILTER_KEY, ARRAY_FILTER_VAL - only one of them set calls with a single argument, both set call with two arguments. I see some potential here, albeit a bit more magical :) Let's see how the discussion progresses. best regards Patrick -- -- Tjerk
Re: [PHP-DEV] Parsing PUT data
On Tue, Sep 24, 2013 at 1:19 PM, Dave catch.d...@gmail.com wrote: Hi All, Firstly, let me know if this is particularly spammy/inappropriate for this list. I just wanted to get some feedback on a long-time feature request (2011) about treating PUT the same as POST in terms of re-using the existing form parser. See https://bugs.php.net/bug.php?id=55815 for details. Normally, I wouldn't have posted this to internals, but as you can see, there's been no movement on this for a long time. In short, in order to provide a proper REST service that supports multipart form data, we need someway to parse data sent via PUT (data is available via php://input, but it needs to be parsed). Could be as simple as adding $_PUT / $_FILES for PUT data. Perhaps it might be a better idea to expose the multipart parser as a function, so that you can bind the decoded body to either an object or array. The trick is to keep `is_uploaded_file()`, etc. working, though. What's the best way to move this forward? Do I need to create a patch/RFC? Or is this something someone can just pick up? Thanks, Dave -- -- Tjerk
Re: [PHP-DEV] Re: crc32() and ip2long() return values
Hi,
On 30 Aug, 2013, at 11:29 PM, Rasmus Schultz ras...@mindplay.dk wrote:
No replies probably means no one cares. oh well.
For the record, the examples I posted are wrong - the correct way to
convert the long values consistently appears to be:
list($v) = array_values(unpack('l', pack('l', ip2long('255.255.255.0';
I recognise this from a comment on one of my SO answers here:
http://stackoverflow.com/questions/13419921/how-should-a-crc32-be-stored-in-mysql/13420281#13420281
Instead of using list() and array_values() you can use current() on the return
value to get the first array element from unpack()'s result.
echo current(unpack('l', pack('l', crc32(...;
Admittedly only makes it marginally nicer to look at :)
I missed the fact that array_values() returns an array, and for some reason
the return-value from unpack() is base-1 with apparently no way to change
the key to a 0.
As an aside, the information I posted on the manual pages in the comments
is wrong, and the site currently offers no way to edit or remove a
comment... dangit...
On Tue, Aug 27, 2013 at 12:05 PM, Rasmus Schultz ras...@mindplay.dk wrote:
Dear list,
I recently ran into big problems with crc32() and ip2long() both of which
I was using in the same codebase.
I know these issues have been debated at length in the past, but this
really needs to be fixed.
Anytime you persist these values (to any external medium, files or
databases) you're sitting on a time bomb.
I realize some of you have countless technical arguments why these
functions work as they're supposed to, but php is a high-level language,
and these functions do not work consistently across platforms.
It can't be the developer's responsibility to write unit-tests for
return-values on internal functions - nor should we need to write elaborate
wrapper-functions for these functions to get them to work consistently.
There are dozens (if not nearing 100) different user-land solutions to
this problem, so it's not like the need isn't there - anyone who has ever
used these functions probably needed a work-around. The need for an
enormous red WARNING label, and elaborate explanation on the crc32()
documentation page says it all - nothing this simple, that has been
standardized for this long, should require an elaborate explanation,
complicated work-arounds or for that matter a lot of thought on the
developer's side.
Since a signed 32-bit integer value is the lowest common denominator,
that's what the functions ought to return, so that at least the return
value is consistent across platforms, and you can decide (for example)
whether to persist it to a signed or unsigned INT in a database, and except
it to work the same everywhere. (Databases at large, and at least MySQL,
correctly persists either signer or unsigned INT values across platforms.)
The simplest work-around I have been able to come up with so far, is this:
var_dump(unpack('l', pack('l', ip2long('255.255.255.0';
var_dump(unpack('l', pack('l', crc32('123456789_00_0';
Forcing the value into smaller (on some platforms) 32-bit integer, and
then unpacking it, provides a consistent value on 32-bit and 64-bit
systems, and on Windows.
Of course there is backwards compatibility to consider for this broken
behavior, so I propose the simplest solutions is to just add a new pair of
replacement functions. You don't need to deprecate the existing functions,
because they work as prescribed, however useless they may be for any
practical applications.
The new functions and backwards compatible implementations for older
versions of php might look like this:
/**
* @param string
* @return int a signed (32-bit) integer value
*/
function ip2int($ip_string) {
return unpack('l', pack('l', ip2long($ip_string)));
}
/**
* @param int a signed integer value
* @return string
*/
function int2ip($ip_int) {
return long2ip($ip_int);
}
/**
* @param string
* @return int a signed integer value
*/
function crc32i($string) {
return unpack('l', pack('l', crc32($string)));
}
int2ip() would just be an alias for long2ip().
I spent almost a full day fighting with these functions and testing
work-arounds, and I bet every php developer who encounters a need for one
of these functions will some day sooner or later go through the same.
Userland solutions are not solutions to fundamental problems that affect
everyone who uses the functions.
Arguing that this behavior is correct by some technical definition, is
futile - the behavior is problematic for practical reasons, so technical
circumstances don't really matter here. Core functions need to actually
work consistently and predictably for as many users as possible -
optimizing for C developers and people with deep technical knowledge of
operating system and compiler specifics does not make sense for a language
like php.
Please look for reasons to
Re: [PHP-DEV] Request #65501 uniqid(): More entropy parameter should be true by default
Hi, On 22 Aug, 2013, at 6:58 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, I realized that not many users are using more entropy parameter Therefore, I made Request #65501 uniqid(): More entropy parameter should be true by default https://bugs.php.net/bug.php?id=65501 The comment title explains what this FR is. Any comments? I would like to mention that the return value would become 10 characters longer if we enable this by default. This could break applications that store the value in a database column such as VARCHAR(20). -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: hex2bin: E_WARNING is too much for odd string?
Sent from my iPhone On 27 Jun, 2013, at 11:05 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Sherif, I would like to have consistent behavior at least within a function. 2013/6/27 Sherif Ramadan theanomaly...@gmail.com I thought you wanted to add an extra error for malformed hex, which I would have been fine with, but removing the error entirely? The error is useful. It informs the user that they may have buggy code since the function is clearly documented to expect even length hex encoded strings. It is good to have additional errors for invalid inputs. It would be beneficial for many users. I've checked some conversion(decoder) functions quickly. Functions raise E_WARNING / E_NOTICE for invalid inputs unserialize() convert_uudecode() xmlreader module Functions simply return FALSE for invalid inputs base64_decode() pg_unescape_bytea() mb_decode_mimiheader() mb_decode_numericentity() mb_convert_kana() mb_convert_encoding() mb_convert_variables() Note: mbstring functions raise errors for invalid encoding, otherwise simply return FALSE. Functions do not check validity quoted_printable_decode() xml_utf8_decode() - replaces bad chars to '?' Functions have separate error message function json_decode() - returns FALSE, but can get errors via json_last_error() Decoding errors are usually a bug or some kind of attack, so I agree to add E_NOTICEs. Exception is decoders that supposed to accept external inputs. e.g. base64_decode() and mbstring functions. I think pg_unescape_bytea() should raise E_WARNING, so I'll add it later. Adding E_WARNING to it will never be BC issue. It's obvious bug. hex2bin() will not be used for handling external inputs almost always, so raising E_WARNING make sense. I've updated pull request. (Added E_WARNING for bad hex) https://github.com/php/php-src/pull/369 Everyone is OK with this? The thread started with the assertion that it raises a warning and the commits first remove the warning and then adds it again later, so isn't the whole PR a noop? :) Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: hex2bin: E_WARNING is too much for odd string?
On Fri, Jun 28, 2013 at 9:27 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Tjerk, 2013/6/27 Tjerk Meesters tjerk.meest...@gmail.com The thread started with the assertion that it raises a warning and the commits first remove the warning and then adds it again later, so isn't the whole PR a noop? :) The issue is inconsistent behavior of hex2bin against invalid inputs. Both removing and adding E_WARNING provide consistency. I didn't look close enough apparently :) Adding E_WARNING is better than removing as a result discussion, IMO. Given the sizeable number of functions that don't raise warnings, should this behaviour then be extended to those as well, e.g. base64_decode(), mb_*()? Of course, doing so puts the onus on the developer to validate their inputs first to prevent warnings, but personally I feel the gauge on likelihood to user input exposure conflicts with consistency concerns. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.netHi -- -- Tjerk
Re: [PHP-DEV] PR 287 - added use_keys argument to array_filter() [Discussion]
On 19 Jun, 2013, at 1:04 AM, Patrick Schaaf b...@bof.de wrote: var_dump(array_filter(['foo', '', 'bar'], 'strlen', true)); Warning: strlen() expects exactly 1 parameter, 2 given in - on line 1 Not only do we trigger the error handler (a large enough array causes a performance issue), but we also get back an empty array as a result. That's BC and performance loss that's simply unacceptable, so defaulting the behavior to pass the key is simply out of the question. Existing code won't pass that third, true, argument to array_filter(), and thus will not break. Nevertheless, I'd say go with a new array_filter_key() function, because that permits using existing one-parameter functions like that strlen as a callback, instead of forcing two-parameter callback functions. I've mirrored the behaviour of this feature from JavaScript as much as possible (but obviously without passing the array itself as the third argument). As such I don't feel there's a need to introduce yet another function just so that the key is passed as the first argument. And to use both key and value forces the developer to use closures instead of just any callback unless this means the second argument passed to the callback is the array :) Another alternative might be to go with a third argument to array_filter(), but make that an integer with ORable constants ARRAY_FILTER_KEY, ARRAY_FILTER_VAL - only one of them set calls with a single argument, both set call with two arguments. I see some potential here, albeit a bit more magical :) Let's see how the discussion progresses. best regards Patrick
Re: [PHP-DEV] Method check - Can someone create a RFC for it?
On 21 Mar, 2013, at 2:08 AM, Carlos Rodrigues carlos.v...@gmail.com wrote:
Hi,
I'd like to suggest a new functionality for PHP. I don't know the
internals, and i can't create a patch implementing this. I'm writing
here in case someone likes this idea and write a RFC.
We've had a problem recently where one of our developers forgot an if.
So instead of writing
if ($obj-image) {
echo $obj-image-getUrl();
}
He wrote:
echo $obj-image-getUrl();
Here, locally, it was working cause we had the image. But when we
updated the online version we got a Fatal error: Call to a member
function getUrl() on a non-object cause someone didn't upload the
image in one of the records that we're on the home page.
Fatal errors like this can't be catched by a try/catch. And since this
getUrl() was not essential for the page, we'd better output an empty
string then having the site offline.
You can register a shutdown function with register_shutdown_function() and
check for error_get_last() inside.
In most cases you can't really handle this particular error very well anyway.
At least with this you can have the full error emailed to you if you wish and
print some kind of error message on the page.
One might say: you guys should have tested it better, or The image
field should be mandatory in the back end.
And it's true, he should have written that extra if {}.
Examining this problem we happened to stumble open Ruby's and
Coffescript's method check.
Something like this:
$obj-image?-getUrl()?;
So my suggestion is:
Create something like $foo-bar?() or $foo-bar()?, where you don't
care whether the function exists, or if $foo is an object. If it
doesn't exist you just return null.
I guess there are plenty of systems out there where it's better to
output an empty string than having your site offline, just cause the
programmer couldn't test it completely.
Thanks for reading it.
Carlos Rodrigues
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
Sent from my iPhone On 5 Feb, 2013, at 9:20 PM, Martin Keckeis martin.kecke...@gmail.com wrote: http://w3techs.com/**technologies/history_details/**pl-php/5http://w3techs.com/technologies/history_details/pl-php/5use of PHP5.1 is slowing faster than 5.4 use is growing. This is wrong. At May 2012: PHP 5.1 starts with 4.9% PHP 5.4 start with 0.1 % In Februar 2013: PHP 5.1 has now 3.2% = lose of 1.7% PHP 5.4 has now 2.2% = grow of 2.1% One does not simply apply growth calculations by mere subtractions. PHP 5.1 shrank by 34% PHP 5.4 grew by 2100% :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] stream_get_line behaviour Bug #63240
Sent from my iPhone On 10 Oct, 2012, at 6:39 PM, Nicolai Scheer nicolai.sch...@gmail.com wrote: Hi again! Thanks for your help an comments on the issue. cataphract commented on the stream_get_line behaviour (returning false when used on an empty file) on the bug report page. I do agree that reading on an empty file can be considered an error thus returning false, because there's nothing to read. Unfortunately, and that's why we stumbled upon this in the first place, feof does not return true when opening an empty file. I did not have a look at the internals, but my guess is that feof just does not return true because no one did a read on the file handle yet. To my mind if would be sensible to return true using feof on an empty file, so that one does not actually try a read... That wouldn't be right. Technically the EOF should be discovered, not deduced from other information like stat(). Also, some streams don't support reporting an appropriate size. What do you think? Greetings Nico -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Support negative indexes for arrays and strings
On 4 Sep, 2012, at 3:59 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! The terminology negative indexing seems to imply that the feature should work with arrays. To restrict it to just strings might involve creating a term one would only associate with strings. I do not see any way to change behavior of $array[-1] that would make sense. So either only strings get it or nobody gets it. I suppose one could still extend ArrayAccess and have their own negative indices support for arrays :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Support negative indexes for arrays and strings
On 1 Sep, 2012, at 1:11 AM, Rasmus Schultz ras...@mindplay.dk wrote: Yes, typo! sorry. $array = array(1001, 1002, 1003, 1004); $number = $array[-1]; // = 1004 $array[-1] = 1005; $number = $array[-1]; // = Looking at the resulting code, I would like to point out also that it's extremely misleading... because $array[-1] references two completely different elements depending on whether you're reading or writing the value... unless $array[-1] = 1005 would actually overwrite the last element in the array - in which case it gets even more dangerous, as well as breaking backwards compatibility... That might actually be something I could use :) But the fun for me begins here: $numbers = array(); $numbers[-1] = 5; $numbers[] = 6; What would have happened to the keys? Normally [] is equivalent to [count($numbers)]. Perhaps this is why JS treats negative indices as properties instead :) On Fri, Aug 31, 2012 at 9:24 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Fri, Aug 31, 2012 at 3:14 PM, Rasmus Schultz ras...@mindplay.dk wrote: Having thought about this for a while, I think this is a bad idea - here's why: $array = array(1001, 1002, 1003, 1004); $number = $array[-1]; // = 1004 $number[-1] = 1005; $number = $array[-1]; // = Obviously, the last statement must return 1005, since otherwise that value would be inaccessible. maybe you wanted to write $array[-1] = 1005; instead of $number[-1] = 1005; ? otherwise I can't see the problem that you are mentioning. could you clarify? -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Combined assignment operator for short ternary
Sent from my iPhone On 18 Aug, 2012, at 5:41 AM, Sebastian Krebs krebs@gmail.com wrote: Hi, Don't know, how complicated this is (and also someone (not me) must implement it, because I can't :X), but to be in sync with the operators the short ternary operator should be usable in conjunction with the assignment like the other binary operators. Don't know, if anybody understands me :D So here is an example // instead of $foo = $foo ?: 'default'; // Just $foo ?:= 'default'; Why not just: $foo ?= 'default'; I have many of this default assigments and yes: This is just syntactic sugar. Regards, Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] common issue with version_compare()
On 21 Jul, 2012, at 2:22 PM, Kris Craig kris.cr...@gmail.com wrote: 1.01 eq 1.1 Could you explain this one to me? In every versioning system I've ever used, 1.1 would be greater than 1.01, not equal. Because 01 is just a padded version of 1, probably used to make it easier for regular string comparisons (until you reach major version 10). On Fri, Jul 20, 2012 at 5:07 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! For example, I was not the only one who found it odd that 1.0 is considered less than 1.0.0 - wouldn't it make sense to pad the shortest version-number with zeroes? e.g. 1.0 if compared against 1.0.0 would be padded with zeroes at the end, e.g. as 1.0.0. 1.0.0 and 1.0 are different things. If you want to make a comparison that takes into account only two components, you can just cut them both to two components, then compare. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add hash_pbkdf2 function
On 19 Jun, 2012, at 2:24 PM, Adam Jon Richardson adamj...@gmail.com wrote: On Mon, Jun 18, 2012 at 7:14 PM, Anthony Ferrara ircmax...@gmail.com wrote: https://wiki.php.net/rfc/hash_pbkdf2 What are your thoughts? That's very nice, indeed. One thing I'm wondering about is whether the last parameter could be changed from: raw_output = false To something like: output = hex (also allowing output = raw, output = base64) That wouldn't be consistent with the rest of the hash_ family though :) Just thinking that most of the time I'd prefer storing the hashed passwords as base64-encoded strings just because it's more compact, but this isn't a big deal, just a thought. Really nice work! Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] domdocument loadhtml and encoding
Gentlemen, Regarding this bug report: https://bugs.php.net/bug.php?id=49705 As more developers move away from using regular expressions to parse HTML and start using DOMDocument, I've noticed that quite a few stumble over encoding issues. They're not bugs, because it's documented (I think) that if a document is loaded using ::loadHTMLFile() or if it contains a content-type meta tag which specifies the character encoding it will work as expected. So far I've suggested a hack that involves adding the meta-tag in front of the string that contains the HTML. As horrible as it seems, that does the job! That said, I'm hoping to get enough internals support to add a parameter to ::loadHTML() that set / overrides the default character set when processing the document; when given, any meta tags pertaining to character set encoding should be ignored (AFAIK that's also the browser's behavior). Btw, there's another patch that also introduces a new parameter to ::parseHTML() which has gone into 5.4 branch (https://bugs.php.net/bug.php?id=54037), so it looks like this would be the second (optional) parameter then. Thoughts? -- -- Tjerk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)
On 25 Apr, 2012, at 5:42 AM, Kris Craig kris.cr...@gmail.com wrote: On Tue, Apr 24, 2012 at 1:10 PM, Tom Boutell t...@punkave.com wrote: * The RFC starts off immediately talking about file extensions, but the actual implementation proposed doesn't rely on file extensions or suggest any enforcement of them. That disparity should be addressed for clarity. Did you read the whole RFC? Please refer to the Naming Conventions section. It addresses this explicitly. Are you saying that section wasn't sufficiently clear or did you just miss it? I think what he means is that the abstract section should be, well, abstract. Currently it appears more detailed than it should be by referring to file extensions on the let go. I would phrase that section in a way that doesn't rely on another section to explain the used terminology. Also, references such as .phpp are used throughout the document to indicate a particular type of source file rather than an actual file extension. As such I would recommend moving your terminology section to right underneath abstract. This would improve the readability. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Some Stats
Maybe this has been suggested before, but it would be nice if comments in, ahem, request for comments could be consolidated into one spot, the RFC page itself. Facebook comments come to mind, though I'm sure there are other solutions based on OpenID, etc. Sent from my iPhone On 18 Apr, 2012, at 5:07 AM, Tom Boutell t...@punkave.com wrote: The author of an RFC does need to respond to concerns raised (although possibly not the same concerns over and over). On Tue, Apr 17, 2012 at 3:46 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 04/17/2012 11:41 AM, Kris Craig wrote: On Mon, Apr 16, 2012 at 11:57 PM, Rasmus Lerdorf ras...@lerdorf.com mailto:ras...@lerdorf.com wrote: Number of posts to internals since Jan.1,2012 (top 15): [kris.cr...@gmail.com mailto:kris.cr...@gmail.com]= 249 Wooot! What's my prize? ;P Now I just need to start getting some commits in there Kris, this was actually the point of that email. You are extremely busy on this list and while I appreciate the enthusiasm, it would be good if you could try to refrain from commenting on every single thread multiple times every day. Let it sit for a while, see what everyone has to say and write a single message with your thoughts. This list is mainly for the people working on the code. Many of us are simply deleting entire threads unread at this point which isn't a healthy habit to get into. One idea for everyone on the list is a kind of self-imposed list posting quota. For every commit, bug comment, doc contribution, infrastructure contribution you make you get a post to the list. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Randomize hash-function in php
On 18 Mar, 2012, at 2:32 PM, Xinchen Hui larue...@gmail.com wrote: What if php uses salts for specific hashes only, such as GPC (or all hashes whose lifetime is limited to the current reuqest), and use a zero-value salt for all others? definitely no，thinking of pre-calculated hash. Pre-calculated hash of what? You mean binary serialisation? Or Ajax which use json_decode parse input json. That would be considered a request lifetime hash and therefore could be salted. IMO, this Make no sense but mess things up. We all have opinions. If a clear distinction between vulnerable and non vulnerable data can be reliably made, in my limited knowledge of the whole ecosystem I genuinely think this has a shot :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
On 9 Mar, 2012, at 11:20 PM, Lazare Inepologlou linep...@gmail.com wrote:
Type casting combined with passing by reference is problematic in many
ways. Just an example:
fuction foo( string $buffer) { ... }
foo( $my_buffer );
Here, $my_buffer has just been declared, so it is null. Should this be an
error? I don't know! So, I think that that passing by reference should not
be (immediately) supported.
Strictly speaking, if you add a type to a referenced variable in that way it's
only logical that you expect it to have a proper value when the function is
called. After all, it's not an output type declaration :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
On 22 Feb, 2012, at 2:03 AM, Ralf Lang l...@b1-systems.de wrote: I see no reason why it would be not desirable to have PHP raise the exception rather than putting more or less repeating code snippets all around the place. That is why I am asking. You must be returning false/null somewhere. It's the same effor to instead throw an exception or to return a Ghost family member. The $baby-mother() method cannot know if the using code just wants to collect the $mother object or execute code on it. It can also not know if having no $mother is a problem or just a fact to deal with. Unconditionally raising an exception is a bit overkill here, at least if we would get an exception for trying to access (null)-mother(); Currently the user code must check each link of the chain if it is available, although it is only interested if it can get the final result or not. I'll follow the suggestion and write an RFC. You'll have my vote! :) bloating code with chainable checks is just crazy, something that the engine can do much more efficiently and unambiguously. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Fix for bug #55754
Hi,
Ran into this exact issue just the other day. In the pre-5.4 days, to get
the first element of a returned array I would use current(). I still think
that's correct and shouldn't raise a digital eyebrow.
On Sep 23, 2011 8:30 PM, Etienne Kneuss col...@php.net wrote:
Hi,
On Fri, Sep 23, 2011 at 14:06, Daniel K. d...@uw.no wrote:
When a built-in function is defined with ZEND_SEND_PREFER_REF, PHP will
issue a strict warning if you use an assignment expression as the
parameter.
As an example, current() show this behaviour.
current() has this arginfo defined:
ZEND_BEGIN_ARG_INFO(arginfo_current, ZEND_SEND_PREFER_REF)
ZEND_ARG_INFO(ZEND_SEND_PREFER_REF, arg)
ZEND_END_ARG_INFO()
and a call like:
?php
current($foo = array(bar));
?
Presents you with:
PHP Strict Standards: Only variables should be passed by reference in
%s on line %d
I think it is wrong to warn about this, because, to me, the _PREFER_
part of ZEND_SEND_PREFER_REF, conveys that we should prefer to pass by
reference, if possible, and not care otherwise.
The below patch implements the not care part that was missing until now.
This is done by having the lexer mark the result variable of the
assignment expression as not passable by reference, and changing the
function zend_do_pass_param() to ignore the marked variables when
considering if a parameter could be passed by reference or not.
I have run make test, before and after, with no regressions. The only
test affected was the one I sent earlier to specifically test for this
bug.
I am, however, not sure if this is the right approach to solve the
problem, in which case, I hope to at least have put one of you on the
right track to the _real_ solution, and to have made you interested in
fixing it properly.
The patch looks strange to me, why would you only consider stuff like
foo($a = 2) ? what about passing any other expressions:
foo(array(..)), foo(funcNotReturningARef()) etc... ?
To me it makes not much sense to distinguish different non-ref
expressions in that regard, they should all be handled the same.
Whether we want the actual error on some of our functions like
current()/end() etc.. is another question, but that should be fixed at
a totally different level.
The patch is for php-5.3.8
Daniel K.
diff --git a/Zend/zend_compile.c b/Zend/zend_compile.c
index c325a7e..df30d3d 100644
--- a/Zend/zend_compile.c
+++ b/Zend/zend_compile.c
@@ -2096,7 +2096,7 @@ void zend_do_pass_param(znode *param, zend_uchar
op, int offset TSRMLS_DC) /* {{
if (function_ptr) {
if (ARG_MAY_BE_SENT_BY_REF(function_ptr, (zend_uint)
offset)) {
- if (param-op_type (IS_VAR|IS_CV)) {
+ if (param-op_type (IS_VAR|IS_CV)
param-u.EA.type !=
ZEND_PARSED_EXPR_NO_PASS_BY_REF) {
send_by_reference = 1;
if (op == ZEND_SEND_VAR
zend_is_function_or_method_call(param)) {
/* Method call */
diff --git a/Zend/zend_compile.h b/Zend/zend_compile.h
index 15f24df..475f976 100644
--- a/Zend/zend_compile.h
+++ b/Zend/zend_compile.h
@@ -650,6 +650,7 @@ int zendlex(znode *zendlval TSRMLS_DC);
#define ZEND_PARSED_VARIABLE (14)
#define ZEND_PARSED_REFERENCE_VARIABLE (15)
#define ZEND_PARSED_NEW(16)
+#define ZEND_PARSED_EXPR_NO_PASS_BY_REF(17)
/* unset types */
diff --git a/Zend/zend_language_parser.y b/Zend/zend_language_parser.y
index 1753e97..666b9e2 100644
--- a/Zend/zend_language_parser.y
+++ b/Zend/zend_language_parser.y
@@ -578,7 +578,7 @@ non_empty_for_expr:
expr_without_variable:
T_LIST '(' { zend_do_list_init(TSRMLS_C); }
assignment_list ')' '='
expr { zend_do_list_end($$, $7 TSRMLS_CC); }
- | variable '=' expr {
zend_check_writable_variable($1);
zend_do_assign($$, $1, $3 TSRMLS_CC); }
+ | variable '=' expr {
zend_check_writable_variable($1);
zend_do_assign($$, $1, $3 TSRMLS_CC); $$.u.EA.type =
ZEND_PARSED_EXPR_NO_PASS_BY_REF; }
| variable '=' '' variable {
zend_check_writable_variable($1);
zend_do_end_variable_parse($4, BP_VAR_W, 1 TSRMLS_CC);
zend_do_end_variable_parse($1, BP_VAR_W, 0 TSRMLS_CC);
zend_do_assign_ref($$, $1, $4 TSRMLS_CC); }
| variable '=' '' T_NEW class_name_reference {
zend_error(E_DEPRECATED, Assigning the return value of new by reference
is deprecated); zend_check_writable_variable($1);
zend_do_extended_fcall_begin(TSRMLS_C); zend_do_begin_new_object($4,
$5 TSRMLS_CC); } ctor_arguments { zend_do_end_new_object($3, $4, $7
TSRMLS_CC); zend_do_extended_fcall_end(TSRMLS_C);
zend_do_end_variable_parse($1, BP_VAR_W, 0 TSRMLS_CC); $3.u.EA.type =
ZEND_PARSED_NEW; zend_do_assign_ref($$, $1, $3 TSRMLS_CC); }
| T_NEW class_name_reference {
Re: [PHP-DEV] __constructor parameter limitations.
On Sep 20, 2011 2:10 AM, de...@lucato.it wrote: Hi! I followed the whole discussion, still it is not clear which one is considered good and which bad practice... In ZF 1 and 2, ZendRegistry::__construct() has the following signature with 2 parameters: function __construct($array = array(), $flags = parent::ARRAY_AS_PROPS) while SPL ArrayObject (its parent) has this one with 3 parameters: ArrayObject::__construct() ([ mixed $input [, int $flags [, string $iterator_class]]] ) from https://github.com/zendframework/zf2/blob/master/library/Zend/Registry.phpand http://www.php.net/manual/en/arrayobject.construct.php That's exactly why I think constructors should be exempted from strict signature checking. When you pass objects as a function parameter, the signature should match even though you pass an instance of a child class. That has been well established in some of the previous messages. However, I don't think this should apply to constructors in the same way. They can be 'simplified' as the child class becomes more specific. There are other similar examples, e.g. ReflectionClass::getParentClass() and ZF Zend_Reflection_Class::getParentClass($reflectionClass = 'Zend_Reflection_Class') I don't know if being ArrayObject an SPL makes any difference, I hope not... Is the example relevant for the discussion ? I always found PHP flexibility one of its strong points, and since we don't have method overloading, limiting the signature extension or contraction doesn't sound very useful to developers. bye! Devis On 19 September 2011 16:53, Ferenc Kovacs tyr...@gmail.com wrote: First of all, Anthony, thanks for joining into the discussion! With respect to the func_get_args argument, I see that as a non-issue. Sure, you can do it. But if you do, you're lying about the interface. You're telling the callers that you expect no arguments, but then all of a sudden you error out. Well, we have no way of declaring that we accept an undefined number of arguments. So there is simply no choice here. maybe we should consider adding support for that, as I agree that it would make the contract more clear. You're pushing all of the interface declaration logic out of the interface and into code. That's only going to create maintainability, readability and quality issues as time goes on. Realistically, the only good use of func_get_args is when you need to take in an unlimited number of arguments. But if you do that, you should include the minimum number in the API itself. So if you have a function add() that can take any number of integers, the minimum that makes sense is 2. So you should declare add($left, $right), and then use func_get_args to get all of them to add together. However, with that said, I'd argue that it's bad design to do that at all. I'd recommend instead taking an array parameter and adding the elements of the array. Not only is it cleaner and easier to understand, it also solves the problem of extending that functionality (so you're not duplicating the func_get_args in each child)... By doing that, you also do exactly what you describe earlier, you push the args checks in the code itself, as you could always pass an incomplete array, and you could error out earlier. Var-args functions have been quite used for many things, there is no reason why we should flag that as bad practice now... is there? not that I know of, except that we have no explicit way to declare signature. to reflect to the original points by Anthony: bringing up the Square - Rectangle example was a bad one, but to quote from the wikipedia entry: Violations of LSP, like this one, may or may not be a problem in practice, depending on the postconditions or invariants that are actually expected by the code that uses classes violating LSP. Mutability is a key issue here. If Square and Rectangle had only getter methods (i.e. they were immutable objects), then no violation of LSP could occur. So while it can cause violation, it isn't a violation by itself. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta tests
On Aug 31, 2011 12:14 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 08/30/2011 08:39 PM, Stas Malyshev wrote: Hi! I've checked the unit tests on my Mac and I see 48 failures so far. I've put them here: https://wiki.php.net/todo/tests54?#tested_2011-08-30_on_mac_os_x Most of them are mysql, but others too. So, is there anybody working or willing to work to fix them all for beta? Should we postpone the beta for a week to wait for that or it doesn't make difference? I say we postpone. We really need to get used to the fact that failing tests matter and that they block releases. Why is your tests/func/005a.phpt failing? That seems to pass consistently for most people. tests/lang/045.phpt is the one that fails for everyone because we don't re-apply the timeout for a registered shutdown function. We should either fix that or mark it as an XFAIL. The timeout gets applied but the SIG_ALARM gets filtered by the signal handler because SIGG(running) is still true. Setting running to false inside zend_timeout before calling the other functions seems a (hack?) solution. The two openbasedir tests were broken by these commits: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/tests/security/open_basedir_linkinfo.phpt?r1=311033r2=311509 http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/tests/security/open_basedir_readlink.phpt?r1=311033r2=311507 which you merged from trunk based on changes by jeraimee: http://svn.php.net/viewvc/php/php-src/trunk/tests/security/open_basedir_linkinfo.phpt?r1=296679r2=311141 so we should figure out why that was changed. I don't think this behaviour is difference between trunk and 5.4 so I don't understand the change. ext/date/tests/bug33532.phpt doesn't fail for me. LOCALE differences? What is your diff on that one? I'm not sure how we should attack it, but I think with a little bit of discussion on each failing test we can plow through these pretty quickly. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improvements to HTTP stream metadata
On Jul 1, 2011 7:31 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 6/30/11 2:34 PM, Michael Maclean wrote: The same data also ends up in the bizarre $http_response_headers var that gets spontaneously created in local scope - I've wondered about how good that is to do. This thing is indeed bizzare. I wonder if anybody uses it and why it was done this way... I use this, mainly because I don't always have the file handle after calling a function that does network requests. Who doesn't love a bit of 'magic' ;) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC caching - preloading files
I generally find it more reliable to use iptables to stop incoming requests while priming the cache using a small script. On Jan 15, 2011 11:43 AM, Bharat Nagwani bnagw...@juniper.net wrote: Hello Experts, Sorry for posting this in this list but I am not finding any documentation on this APC php.ini setting apc.preload_path I have tried the following but it doesn't seem to work apc.preload_path = +/core/* apc.preload_path = /core/* What I am looking for is files in certain directories (single or multiple paths are even better) to be precached when the PHP module is first loaded so the first hit is not a miss. Can this be achieved via APC? I am using php 4.4.2 on BSD. Thanks
Re: [PHP-DEV] [PATCH] adding RFC3984 support to http_build_query
Instead of a boolean, could you add a rfc-xx selection parameter instead,
like, in case one would like rfc 3986 instead?
On Jan 5, 2011 8:10 PM, Rui Hirokawa rui_hirok...@yahoo.co.jp wrote:
Hello,
I made a patch to add the RFC-3984 based url-encoding support
into http_build_query().
The http_build_query() is quite useful, but,
it isn't based on the official url-encoding scheme (RFC-3984)
for ~ (tilde) and ' '(space).
I added an optional (the 4th) parameter 'is_rfc3984'.
If it is true (false by default, now), RFC3984 based
url-encoding scheme (it is same as rawurlencode() ) is used.
A simple example shown as bellow,
$v = array('foo'='m o','boo'='[^~]');
// result: foo=m+pboo=%5B%5E%7E5D
echo http_build_query($v, null, '');
// result: foo=m%20pboo=%5B%5E~5D (RFC-3986 compatible)
echo http_build_query($v, null, '', true);
// result: foo=m%20pboo=%5B%5E~5D (RFC-3986 compatible)
echo rawurlencode($v['foo']).''.rawurlencode($v['boo']);
I'm going to commit the patch if it is accepted.
Rui
Re: [PHP-DEV] RE : Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
Hi, Don't have much knowledge about the internal workings of the engine, but I'm wondering if it's possible to apply lazy loading to the $_POST variable, so that processing only happens if and when it's requested. That way you wouldn't need the ini setting. On Dec 8, 2010 7:54 AM, Patrick ALLAERT patrick.alla...@gmail.com wrote: It is not the goal to block but to prevent the usual processing of $_POST when not required inside a valide POST request which will handle the input differently. Le 7 déc. 2010 23:36, Tig tigger...@gmail.com a écrit : If the objective is to 'block' POST data from getting to PHP, (in apache) you can use: http://httpd.apache.org/docs/2.0/mod/core.html#limit No need to change / add anything to PHP. -Tig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/...
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
-1 The nuisance of updating IDE, search tools etc doesn't outweigh typing 9 characters less imho. On Nov 28, 2010 11:53 PM, Martin Jansen mar...@divbyzero.net wrote:
Re: [PHP-DEV] Re: break/continue $var
Reading those notes I'm wondering what's meant by dynamic break is not working? I understand how it could lead to better compilation, but a mere 'not working' at the very least intrigues me :) I have actually used this construct, though its purpose is mainly in parser routines, so I guess I could always goto instead. On Nov 19, 2010 12:21 AM, Patrick ALLAERT patrick.alla...@gmail.com wrote: 2010/11/18 Derick Rethans der...@php.net: On Thu, 18 Nov 2010, Dmitry Stogov wrote: Previously we decided to remove break/continue $var syntax. I even implemented it in PHP6 brunch, however it wasn't backported into trunk. Could I do it? Is there a really good reason to remove it? Not sure, but at least, it is in *your* release notes :-) http://www.php.net/~derick/meeting-notes.html#break-var -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
