Re: [PHP-DEV] Re: [VOTE] array_column() function
On 14 Jan 2013, at 11:37, Ben Ramsey ram...@php.net wrote: On 1/11/13 6:17 PM, Ben Ramsey wrote: I've opened voting for the array_column() function RFC. You can vote at https://wiki.php.net/rfc/array_column#voting I have updated the pull request by removing the array_pluck() alias. I favor the array_column() alias, as it is more in keeping with other function names like array_keys() and array_values(), which do not have verbs in them. If the RFC is accepted, I will submit a new pull request against the 5.5 branch and close the current pull request against the 5.3 branch. If I should do that now, please let me know, and I'll go ahead and take care of it. I've talked about the Facebook version of this when the key bit got added, but we have 2 other methods to go with it. mpull() which does methods https://github.com/facebook/libphutil/blob/master/src/utils/utils.php#L110 ppull() which does properties https://github.com/facebook/libphutil/blob/master/src/utils/utils.php#L184 Not sure if these should be added separately? The property version is good for PDO when using FETCH_CLASS. - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] array_column() function
On 14 Jan 2013, at 12:57, Ben Ramsey ram...@php.net wrote: On 1/14/13 11:54 AM, Scott MacVicar wrote: On 14 Jan 2013, at 11:37, Ben Ramsey ram...@php.net wrote: On 1/11/13 6:17 PM, Ben Ramsey wrote: I've opened voting for the array_column() function RFC. You can vote at https://wiki.php.net/rfc/array_column#voting I have updated the pull request by removing the array_pluck() alias. I favor the array_column() alias, as it is more in keeping with other function names like array_keys() and array_values(), which do not have verbs in them. If the RFC is accepted, I will submit a new pull request against the 5.5 branch and close the current pull request against the 5.3 branch. If I should do that now, please let me know, and I'll go ahead and take care of it. I've talked about the Facebook version of this when the key bit got added, but we have 2 other methods to go with it. mpull() which does methods https://github.com/facebook/libphutil/blob/master/src/utils/utils.php#L110 ppull() which does properties https://github.com/facebook/libphutil/blob/master/src/utils/utils.php#L184 Not sure if these should be added separately? The property version is good for PDO when using FETCH_CLASS. - S I did review these, and I like them, but I think they should be added separately, especially since they deal more with objects than arrays. As long as the work with objects that implement ArrayAccess then it should be fine? - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Add simplified password hashing API
Concerns about the RFC after talking with someone (Alok) on our security team at work. There is no requirement for them to be cryptographically secure. What stops the salt from being cryptographically secure? I think it should be a goal or we should state what parts aren't cryptographically secure, is it the random data source? The salt parameter, if provided, will be used in place of an auto-generated salt. This is setting someone up for failure by letting them put in something weak, you should be forced to get an auto-generated salt. If this is for unit testing then it should be explicitly stated. The documentation also needs improved around password_needs_rehash. Tell the developer that at login time (or any other password validation time), if the options have changed, the password can be rehashed. E_WARNING in a crypto function is also bad. Throw an exception or fatal. There's no reason to just raise a warning and continue execution, if something went wrong in crypto then its a bad time for everyone. - S On 12 Sep 2012, at 09:02, Anthony Ferrara ircmax...@gmail.com wrote: All, I have added the tests and ensured that everything seems pretty clean. I have opened a Pull Request for this item as I would like to get more eyes on it (especially since it touches crypt()). Please review the PR and comment away. https://github.com/php/php-src/pull/191/files Once it looks good, I'll merge it in. I just wanted to get more eyes on the diff first... Thanks Anthony On Wed, Sep 12, 2012 at 10:02 AM, Anthony Ferrara ircmax...@gmail.comwrote: Hello all, I've closed the vote and it's been accepted with a vote total of 19:0, unanimous. I've moved the RFC into Accepted. I'm going to add the remaining tests, and then move it into master later. As for the PECL extension route, I'll work on splitting it into a PECl extension for 5.3/5.4 at the same time. Thanks all, Anthony On Tue, Sep 11, 2012 at 7:58 AM, Anthony Ferrara ircmax...@gmail.comwrote: Hannes, First off, this has been discussed on the list for literally months. Why wait until the day before voting can end before bringing this up? So commenting is strictly forbidden during votes? Not in the least. Just pointing out that this discussion could have been better if it was started much earlier (prior to the time and effort being put into it). Just pointing it out. There's nothing wrong (procedurally) about bringing it up now, just that it would have been nice to hear this point earlier in the discussion... Secondly, the main reason for not developing this as an extension is that there's really no benefit to it. There are little to no performance gains to be had by the C implementation. It can live quite as easily as a PHP library. The benefit is that it can be tested properly and bugs discovered and ironed out first. I'm not so sure about that. If it was widely adopted as an extension, sure. But I would predict a very limited adoption. Almost purely academic. The reason is that there's no advantage to doing it in C other than to provide a working API for those who don't understand how to build it (or realize the benefits thereto). Those are the same people who wouldn't be able to install a PECL extension (know-how or access). And projects who realize this is needed are likely already using one of the many libraries available. So I'm not sure the install rate would be anywhere high enough to work any significant issues out. Additionally, there are testing phases for the release that would hopefully catch any major issues prior to 5.5 going gold... This is not the sort of thing you want to get security bug reports the day after its released in core. Sure. Which is why I've been going around looking for security reviews (posted to the crypt-dev list on openwall, and to security.stackexchange.com). If your ego is big enough you can guarantee you have tested this thoroughly and want it to become the recommended way.. You have to be damn sure you don't fuck it up. I want to say that this is really unfair. By saying it this way you've pushed me into a corner. I disagree that your suggestion would have a result of any significant gain in security. Yet I cannot disagree with you without coming across as an egotist now that you said it that way. Please try to keep things civil without setting up traps to try to prove your point. I don't appreciate this remark at all... This is exactly the sort of thing that doesn't need to be developed in the core tree, but can later be merged in once proven successful. As indicated before, if that's the case, then it would never be merged. Because this would never be successful as a stand alone PECL module. The primary reason for adding it is so that people who don't know any better would be able to use a secure API. That is the antithesis of a PECL extension. Especially
Re: [PHP-DEV] [DRAFT] RFC - array_column() function
Hey Ben, On 22 Jun 2012, at 08:52, Ben Ramsey wrote: On 6/22/12 5:32 AM, Léo Peltier wrote: Hi, Shouldn't this be called 'array_pluck'? This is the name people usually use when implementing it in PHP (see array_pluck( vs array_column( in Google) or in other languages/libs (see underscorejs, prototypejs and RoR). I'm open to changing or aliasing the name to array_pluck(), if others are in agreement. We have a version of this at Facebook and its called array_pull() it has a third parameter and supports pulling a new key value too. You can find a copy of it in Phabricator. There is also mpull() which is for methods. I'd recommend combining the two methods to be honest and doing a single function that supports index names or a method. https://github.com/facebook/libphutil/blob/master/src/utils/utils.php#L143 - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Enforcing final in traits
This caused a few bugs for us / confusion. The final keyword is accepted inside a trait but it the class also defines a method without the final keyword this takes precedence. Two solutions: Enforce final when a trait defines - https://whisky.macvicar.net/patches/0001-If-a-trait-declares-a-method-as-final-enforce-that.patch Prohibit final form being used in a trait - https://whisky.macvicar.net/patches/002-traits-Disable-use-of-final-keyword.patch I'm for the first solution here - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Running mhash tests
On 14 Sep 2011, at 13:26, Pierre Joye wrote: hi, On Wed, Sep 14, 2011 at 9:58 PM, Alexey Shein con...@gmail.com wrote: Should we delete these tests (and, maybe deprecate/move to pecl the extension itself)? I don't think we should, they are here to make sure that the emulation layer works fine. If not, I'd like to know how to run these tests. Maybe the skipif is wrong, as far as I remember there was an issue with seeing the mhash layer as being the mhash extension. Maybe we should change the skipif and uses function_exists instead? Have you tried it? It definitely should have a 'mhash' entry, it creates a mhash_module_entry and registers that. If you enable mash only, it silently enables hash. - Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Running mhash tests
On 14 Sep 2011, at 13:46, Alexey Shein wrote: 2011/9/15 Pierre Joye pierre@gmail.com: hi, On Wed, Sep 14, 2011 at 9:58 PM, Alexey Shein con...@gmail.com wrote: Should we delete these tests (and, maybe deprecate/move to pecl the extension itself)? I don't think we should, they are here to make sure that the emulation layer works fine. If not, I'd like to know how to run these tests. Maybe the skipif is wrong, as far as I remember there was an issue with seeing the mhash layer as being the mhash extension. Maybe we should change the skipif and uses function_exists instead? Have you tried it? They both return false for me: conf@laptop ~/php-src/trunk $ sapi/cli/php -r 'var_dump(extension_loaded(mhash), function_exists(mhash));' bool(false) bool(false) conf@laptop ~/php-src/trunk $ Definitely works for me on latest trunk. Does a shorter configure fix this? I wonder if something elsewhere is breaking this. macvicar-mba:trunk macvicar$ cat config.nice #! /bin/sh # # Created by configure './configure' \ '--disable-all' \ '--with-mhash' \ $@ macvicar-mba:trunk macvicar$ sapi/cli/php -m [PHP Modules] Core date ereg hash mhash pcre Reflection SPL standard [Zend Modules] macvicar-mba:trunk macvicar$ sapi/cli/php -r 'var_dump(extension_loaded(mhash));' bool(true) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3.7 is breaking SSL
On Aug 17, 2011, at 5:50 PM, Reindl Harald wrote: well i guess it is the change below this results in connections in hanging around and after a hughe timeout filling my mailbox with cron-mails: mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ without ssl_set() all works fine but unencyrpted :-( ___ MySQL server has gone away $this-ssl_key = '/etc/mysql-ssl/client.pem'; $this-ssl_crt = '/etc/mysql-ssl/client.pem'; $this-ssl_ca = '/etc/mysql-ssl/ca.crt'; $conn-ssl_set($this-ssl_key, $this-ssl_crt, $this-ssl_ca, NULL, NULL); ___ https://bugs.php.net/bug.php?id=55283 - MySQLi extension: . Fixed bug #55283 (SSL options set by mysqli_ssl_set ignored for MySQLi persistent connections). (Andrey) Do you have a full script I can use to look at? Do you set a mysql timeout? - Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3.7pl1
On 19 Aug 2011, at 16:16, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Looks like 5.3.7 shipped with broken crypt() (see bug# 55439 and http://svn.php.net/viewvc/?view=revisionamp;revision=315218) - and I think it's a serious problem since this means everybody's md5 passwords will stop working - so should we make 5.3.7pl1? And maybe not do these changes on 5.3, especially this close to the release? 5.3.8 and lets not apply the coverity fixes during the final RC. S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Coverity Scan
On 6 Aug 2011, at 20:07, Rasmus Lerdorf wrote: Coverity has run a new scan of trunk and there are a lot of valid issues. You have probably noticed that I have started to fix some of them, but there are 500+ to go, so I could use some help. The following people already have Coverity accounts: andi, antony, colder, derick, dmitry, helly, iliaa, jcogg, joey, kmori, mike, nickpj, nlopess, phoddie, rui, sas, scottmac, sean, sesser, slif, steph, tgoldstein, thiago, wez and zeev If you would like to help out and you don't have an account, please send me an email or catch me on irc and I will get you set up. Once you have an account, go to: http://scan.coverity.com/rung2.html And click on the Sign in link next to PHP If you start working on fixing one of these, please assign it to yourself first within the Coverity UI so others will know. All these changes to PHP 5.3 scare me, I was hoping we'd see 5.3.7 released sooner but after all these changes I think we'll need some more RCs out. Thoughts ilia? - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: json_encode option for not escaping unnecessary character
Never got the email, will look today at it. Doesn't quite match our coding standards from the first glance. S On 4 Aug 2011, at 09:17, Александ Москалёвir...@irker.net wrote: I write to omar (ext author) and scottmac (bug owner) and not received a reply from they. Can someone else check this patch, please? With regards, Alexander Moskaliov ir...@irker.net 2011/7/25 Александр Москалёв ir...@irker.net: Hello. Can someone check my patch in this request https://bugs.php.net/bug.php?id=53946 ? It would be nice to see it in PHP 5.4 . If a question arises why this is necessary, then see my comments on this bug. Thanks in advance. With respect, Alexander Moskaliov ir...@irker.net -- 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] Subverting OpenSSL library function with Windows alternatives
Just noticed a commit from Pierre last week http://svn.php.net/viewvc?view=revisionrevision=313112 which changed OpenSSL to use a special Windows API call for gathering random data. I've reverted this change so we can discuss this further. I disagree with advertising a library function and changing it to use something else. Especially when this is around random data / encryption. The OpenSSL library has been audited externally, if there is a better alternative then this patch should go upstream rather than being hacked into PHP. If we want to offer this as win32_random_data() then I'm also fine with that. - Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/openssl/openssl.c trunk/ext/openssl/openssl.c
Why did you even commit such a change without discussing it? I understand your
logic for doing this but there was no RFC or discussion around the impact of
this.
OpenSSL has been FIPS certified, your change has changed this contract and it's
calling back into a Windows API. Has it been reviewed for correctness?
Whats the speed difference between OpenSSL and your version. I know you removed
the screen code which was causing a long delay.
On Jul 19, 2011, at 4:13 PM, Pierre Joye wrote:
Why did you not ask in the 1st place before reverting it?
Please don't waste our time with such things. Users expect this
(tested) fix in the next releases.
Now, openssl has lower minimum windows version support that we do, and
does all possible things to improve the entropy, which is not required
nor necessary for the windows we support.
The idea in the 1st place was to have a standard set of random
functions instead of this, as you well know. Now it is too late and we
have to live with this function. While the set of random will surely
come at some point too.
On Wed, Jul 20, 2011 at 1:04 AM, Scott MacVicar sc...@macvicar.net wrote:
Why isn't this fixed upstream? This is a horrible idea to make core changes
like this without a discussion.
I'll revert this again so we can at least have the opportunity to discuss
this.
S
On 19 Jul 2011, at 15:55, Pierre Joye pierre@gmail.com wrote:
Please restore that, now. That's not your cup of tea and it is the way
it should have been in the 1st place.
On Wed, Jul 20, 2011 at 12:29 AM, Scott MacVicar scott...@php.net wrote:
scottmac Tue, 19 Jul 2011 22:29:55 +
Revision: http://svn.php.net/viewvc?view=revisionrevision=313455
Log:
Revert change to use a special Windows version of
openssl_random_pseudo_bytes().
Lets discuss this on internals first. We're advertising something from the
OpenSSL library
and then subverting it with another Windows OS call.
What are the implications of this? Should we make this available in
ext/standard/ instead?
Changed paths:
U php/php-src/branches/PHP_5_4/ext/openssl/openssl.c
U php/php-src/trunk/ext/openssl/openssl.c
Modified: php/php-src/branches/PHP_5_4/ext/openssl/openssl.c
===
--- php/php-src/branches/PHP_5_4/ext/openssl/openssl.c 2011-07-19
22:18:08 UTC (rev 313454)
+++ php/php-src/branches/PHP_5_4/ext/openssl/openssl.c 2011-07-19
22:29:55 UTC (rev 313455)
@@ -4930,19 +4930,10 @@
buffer = emalloc(buffer_length + 1);
-#ifdef PHP_WIN32
- strong_result = 1;
- /* random/urandom equivalent on Windows */
- if (php_win32_get_random_bytes(buffer, (size_t) buffer_length) ==
FAILURE){
- efree(buffer);
- RETURN_FALSE;
- }
-#else
if ((strong_result = RAND_pseudo_bytes(buffer, buffer_length)) 0)
{
efree(buffer);
RETURN_FALSE;
}
-#endif
buffer[buffer_length] = 0;
RETVAL_STRINGL((char *)buffer, buffer_length, 0);
Modified: php/php-src/trunk/ext/openssl/openssl.c
===
--- php/php-src/trunk/ext/openssl/openssl.c 2011-07-19 22:18:08 UTC
(rev 313454)
+++ php/php-src/trunk/ext/openssl/openssl.c 2011-07-19 22:29:55 UTC
(rev 313455)
@@ -4926,19 +4926,10 @@
buffer = emalloc(buffer_length + 1);
-#ifdef PHP_WIN32
- strong_result = 1;
- /* random/urandom equivalent on Windows */
- if (php_win32_get_random_bytes(buffer, (size_t) buffer_length) ==
FAILURE){
- efree(buffer);
- RETURN_FALSE;
- }
-#else
if ((strong_result = RAND_pseudo_bytes(buffer, buffer_length)) 0)
{
efree(buffer);
RETURN_FALSE;
}
-#endif
buffer[buffer_length] = 0;
RETVAL_STRINGL((char *)buffer, buffer_length, 0);
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets broken in 5.4 on Mac OS X
On Jul 10, 2011, at 4:21 PM, Stas Malyshev wrote: Hi! I was now building 5.4 on Mac with sockets enabled and got this: /Users/smalyshev/php-5.4/ext/sockets/multicast.c: In function ‘php_if_index_to_addr4’: /Users/smalyshev/php-5.4/ext/sockets/multicast.c:426: error: ‘struct ifreq’ has no member named ‘ifr_ifindex’ /Users/smalyshev/php-5.4/ext/sockets/multicast.c: In function ‘php_add4_to_if_index’: /Users/smalyshev/php-5.4/ext/sockets/multicast.c:506: error: ‘SIOCGIFINDEX’ undeclared (first use in this function) /Users/smalyshev/php-5.4/ext/sockets/multicast.c:506: error: (Each undeclared identifier is reported only once /Users/smalyshev/php-5.4/ext/sockets/multicast.c:506: error: for each function it appears in.) /Users/smalyshev/php-5.4/ext/sockets/multicast.c:513: error: ‘struct ifreq’ has no member named ‘ifr_ifindex’ Redoing buildconf/configure didn't help. Any ideas? The code for this looks really convoluted, I'm thinking we should back out this multicast option for now. It's basically not going to work on OSX the way its implemented from what I can tell. - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets broken in 5.4 on Mac OS X
On Jul 10, 2011, at 4:46 PM, Stas Malyshev wrote: Hi! On 7/10/11 4:23 PM, Scott MacVicar wrote: The code for this looks really convoluted, I'm thinking we should back out this multicast option for now. It's basically not going to work on OSX the way its implemented from what I can tell. I don't know much about this code (or multicast in general) but I guess we would want a fix for that ASAP or ifdef it out on Mac or remove it until solution is found. Need to ifdef the entire thing, OS X lacks the index for the interface which is passed around for enabling it in options. Maybe there is another solution but in the hour I spent looking at it there wasn't an easy fix. Also the code for it seems all over the place, I'd be for removing it and adding it back in when it's more stable. - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Migration of SVN commit access to SSL
A few minutes ago I forced all commit access for svn.php.net to be over SSL, if you try to commit over regular HTTP you'll get a 403 error. Migrating from http to https is a single command. See: https://wiki.php.net/vcs/https-svn - Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
Can't bundle geoip with the database due to the license on it. Would make it a pretty useless extension to have in that case. S On 5 Jun 2011, at 11:39, Olivier Hill olivier.h...@gmail.com wrote: Could you open a bug for GeoIP? Being aware of bugs helps more than bitching around. Thanks Olivier (iPhone) Le 2011-06-05 à 04:37, Reindl Harald h.rei...@thelounge.net a écrit : Am 05.06.2011 12:57, schrieb Pierre Joye: The last point is that pecl allows a much more flexible release management than the core will even do. in theory So instead of doing some marketing/communication actions by bundling some known extensions, we should better promote pecl better. not promote - MAINTAIN it better! in fact most of PECL-extensions are a lucky game since linux distributors has to find workarounds for rarely maintained extensions and you can not be sure that a extension can be compiled after a update of php or some system-library and only if you have luck a maintainer answers on a bug-report _ http://pecl.php.net/package/GDChart dead, no longer maintained and it needed a message to this list to get this confirmed by Ilia Alshanetsky, WTF - why is there no big red hint DO NOT USE IT until now? http://pecl.php.net/package/geoip - stable 2009-03-11 what about try if this works after new releases of the library behind - with recent GeoIP-Versions php crashs if geoip_db_get_all_info is called, and sorry but after more than 2 years it is not the users hob reporting everything necause lazy maintainers writing code once and orphaning it http://pecl.php.net/package/pecl_http/2.0.0dev1 coll, in th emiddle of 5.3 lifecycle a total incompatible reqrite is started and hopefully no one has projects relying on the pecl-extension http://pecl.php.net/package/ssh2 was three years not maintained and could not compiled with recent versions of libssh2 without some magic patches from distributors http://pecl.php.net/package/gnupg did not work for threee years on fedora-systems no anwser on bu-reports - so what do you do in such a case? and you will tell us PECL is a relieable source for components anybody is using in his projetcs? not really! -- 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] Bundling modern extensions
On Jun 4, 2011, at 4:57 PM, Stas Malyshev wrote: Hi! In parallel I'd also see if there are any key extensions which we think are mainstream, stable and well maintained enough to be included. For example, http comes to mind. Maybe also oauth? It's getting popular and widely used. OAuth is basically outdated now, OAuth2 is going through the final IETF certification steps. No real technical changes in the last few drafts. - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DOMNode::getAttribute()
On Jun 3, 2011, at 1:38 PM, Matt Pelmear wrote:
Hello,
I discovered today that the DOMNode::getAttribute() function (which is
undocumented on the php site) returns an empty string if the requested
attribute doesn't exist in the node.
From the source:
if (value == NULL) {
RETURN_EMPTY_STRING();
} else {
RETVAL_STRING((char *)value, 1);
xmlFree(value);
}
Seems to me that it should return NULL. (That's what libxml does, apparently.)
Does anyone know of a particular reason it returns an empty string instead?
Does anyone know of a particular reason it is not documented?
(I'd be happy to document and provide the ridiculously simple patch of
returning NULL...)
We match the behaviour the w3c defines for the DOM.
DOMString
The Attr value as a string, or the empty string if that attribute does not have
a specified or default value.
Consider using hasAttribute() if you care about the existence.
- Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] INF behavior
On 26 May 2011, at 20:03, Philip Olson phi...@roshambo.org wrote: Hello geeks, A geek is needed to clarify PHP bug #45712. This is an edge case but the test (bug45712.phpt) contains code similar to the following: ?php $inf = pow(0, -2); var_dump($inf); // float(INF) var_dump($inf == $inf); // bool(false) var_dump($inf === $inf); // bool(true) ? That's how it's behaved since ~forever (AFAICT) and remains in 5.3.7-dev, but PHP 5.4.0-dev changes behavior so both now return true. Is this is how we want it? And how should this be documented/explained? I think I changes this :-) It didn't make sense that == and === produce different results. Though if someone has a better understanding of maths then we can fix it. S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] embedded libmagic (from file)
I have a diff sitting that I did yesterday that upgrades us to the latest libmagic, it supports the new magic file format and updates that bundle. But that's all. I'm also against allowing the non-php version. Yes it's a fork but unfortunately it's for the best. - Scott On 21 March 2011 10:12, Pierre Joye pierre@gmail.com wrote: hi, Many incompatibilities and features are not available upstream. The more we work on it the more differences we have. I have to strongly (really strongly) discourage any kind of hacks to allow external libmagic usage. That will only limit the features available to the PHP users, like stream support for example. Cheers, On Mon, Mar 21, 2011 at 6:00 PM, Ondřej Surý ond...@sury.org wrote: Hi, [I have searched the list and no relevant answer came up, only one unanswered question (*)] I would like to ask whether there is a strong reason to have customized libmagic in the source tree as the only option. I saw the discussion that you want to have embedded magic database, but still I would like to have an option to use system libmagic if available. This is similar to libgd, etc. No, it is definitively not the same than libgd. Libgd is now being synced and the core features were the same. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.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] Allowing PHP to recognize a variant of Apache (bug #54084)
Go for it :) On 17 March 2011 18:34, Christopher Jones christopher.jo...@oracle.comwrote: Does anyone have issues with a small version check change to the build system so that PHP installs cleanly on a variant of Apache? This would improve PHP install usability by allowing it to just work. See http://bugs.php.net/bug.php?id=54084 If I don't hear any replies by next week, I'll apply the patch. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP development environment
This is the wrong mailing list, this is about development of the PHP runtime and not towards development using PHP. - Scott On Jan 14, 2011, at 5:56 PM, Dallas Gutauckis wrote: Depending on the duration of development, I either use nano for short edits, or zend studio for a large project. Both cases, I use Ubuntu. On Jan 14, 2011 8:45 PM, J. Adams zardozro...@gmail.com wrote: I'm curious about this too. I've been developing on a Mac using nano from the command line and it can be pretty tough. Any and all details welcome. I'm about to set up a 64-bit box with Ubuntu which would be my primary dev box. I also have a windows desktop. On 1/14/2011 5:40 PM, Martin Scotta wrote: Hi all, I'm just starting with the internal PHP development. Do you have some sort of common development environment? Eclipse project or the like? I'm using Ubuntu but also have a WXP, just for the sake of. how do you develop PHP ? Martin Scotta -- 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 - MACRO
I really dislike this, what about resolving orders, then people will want
undef, then ifdef with conditions.
The language doesn't need to introduce anything that makes it more complex to
use.
- Scott
On 22 Dec 2010, at 11:55, Mathias Grimm mathiasgr...@gmail.com wrote:
I Just want a simple replace-on-the-air to avoid spend time writing more.
On Wed, Dec 22, 2010 at 5:43 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
I want to request a C/C++ feature that i think is good.
MACRO
You know that you could write:
?php
#define PF private function
#define SCOPE_CLASS(x) class MyProject_ ## x
class UseMacro
{
PF preSave($object)
{
//...
}
}
SCOPE_CLASS(Internal)
{
}
And then run it through CPP (gcc -Mcpp -E - - in.php out.php) and get
all the macros processed?
--
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] Re: PHP Performance in Apache: Multi-Process vs Multi-Threaded
On Dec 16, 2010, at 12:28 AM, jvlad wrote: No. Php if we talk about php with all its extensions is not threadsafe at all. Many of the extensions allocate static data and inherently non-thread-safe. PHP is, if compiled with ZTS/TSRM, thread-safe. Some libraries used by some extensions might not be thread safe, but basically all usually used ones are thread-safe. While it is a bit complicated as some libraries could either be compiled thread-safe or not or some might be not thread-safe on specific systems ... but that's not PHP itself ;-) johannes Dear Johannes, I'm not sure why you repeated what I stated in my post. So I'm repeating it after you too :) Yes, php core is developed with threadsafe techniques in mind, some extensions are safe too, and some extensions which are using 3rd party libraries are definitely not safe. The only thing I'd kindly ask you to pay more attention to is using usually word together with safe in one sentence. In my opinion they should never be used both if we talk about production servers, or at least servers where crashes are not welcome. Just to illustrate the issue with usually, do you consider openssl, a widely used php extension, as a usually threadsafe extension? If you do, please take a look at this page http://www.openssl.org/docs/crypto/threads.html and these words in particular: OpenSSL can safely be used in multi-threaded applications provided that at least two callback functions are set, locking_function and threadid_func. locking_function(int mode, int n, const char *file, int line) is needed to perform locking on shared data structures. (Note that OpenSSL uses a number of global data structures that will be implicitly shared whenever multiple threads use OpenSSL.) Multi-threaded applications will crash at random if it is not set Do you think any locking function is implemented in openssl php extension? In PHP a SSL_CTX is per thread and is not shared across other threads so it isn't an issue. We don't need to implement any openssl locking functions. An example of non-thread safe is gettext it relies on the locale which is per process and not per-thread. PHP itself at the core is thread safe. As Johannes said most common modules are too. - Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GPU Acceleration
Do you have a patch for this? The only thing stopping it is no one had written it. - Scott On Nov 12, 2010, at 3:23 PM, Kenan Sulayman wrote: Hello out there! I just asked myself, just like that: Why shouldn't it be possible to create a php-work flow which allows the immediate parallelization over GPU to make, for instance, the execution a hundredth times higher? I mean, well - yes it sounds like a stupid idea, we've got 6 GPU-Horses ( servers with Radeon 5970 x2 ) and they could deliver blazing performance. We could be a gazillion times be better in serving or processing content. Right? *even thought it's meant to be parallelization, we could rewrite the code..* So, I'd thank you for *constructive* answers. Cheers, -- (c) *Kenan Sulayman* *Freelance Designer and Programmer* *Life's Live Poetry* -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GPU Acceleration
On Nov 12, 2010, at 4:09 PM, Stefan Marr wrote: Hi: On 12 Nov 2010, at 16:35, Scott MacVicar wrote: Do you have a patch for this? The only thing stopping it is no one had written it. So, I'd thank you for *constructive* answers. *sigh* He was asking for constructive answers. What's not constructive about it? Seems pretty constructive to me. The original poster has done research into the issue already. The reason most things don't exist is that no one has a patch for it. If it doesn't core in core then it heads into a PECL module or lives as a patch on some site. - Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On Oct 29, 2010, at 6:17 PM, admin wrote: On 10/29/2010 08:11 PM, William A. Rowe Jr. wrote: On 10/29/2010 7:47 PM, admin wrote: WTF is T_PAAMAYIM_NEKUDOTAYIM? This has to be THE most asked question by new php developers when they come across it. Can we please change the token name to T_DOUBLE_COLON so I don't have to hear about it constantly? Those that disagree don't do enough PHP support to know how often it is asked. it's worth it. Is it that hard to at least review the mailing list archives before ranting? At least posters would sound like they have educated themselves on why what came to be, and argue sensibly for changes. obviously the old arguments didn't work, time to start anew. using a name like admin in your email headers isn't going to be very receptive. For what its worth its Hebrew for double colon. I'm all for the change, will see what I can do next week. - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1
On Aug 10, 2010, at 3:11 PM, Johannes Schlüter wrote: On Wed, 2010-08-11 at 00:03 +0200, Kalle Sommer Nielsen wrote: type hinting For the record: I consider the current implementation as (one of) the biggest mistakes in the last ten years. johannes I'm happy to see a more strict implementation, but I think our numeric handling needs changed. We silently fall between them all in PHP. Sure we can guarantee array, null, bool, resource, string etc but not the numeric types. I think we should hold off on the Alpha until we're agreed with thats happening with that. - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PKCS#11 support
On Jul 20, 2010, at 12:51 AM, Paul van Brouwershaven wrote: Hi Scott, Op 20-7-2010 0:28, Scott MacVicar schreef: It can be released on the PECL site but I doubt it would go in the default distribution. Why not including this in the default distribution? It would be great to have PKCS#11 support in the default PHP distribution! Well it has to be developed and tested first. so into PECL it goes for that. Then there is the more important fact that is requires LGPL code, so we wouldn't bundle the library. Leaving it only being enabled for those who have OpenSC installed. - Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PKCS#11 support
It can be released on the PECL site but I doubt it would go in the default distribution. - Scott On 19 Jul 2010, at 14:49, Tomasz Wyderka wyderk...@googlemail.com wrote: Hi, I'm planning to write PKCS#11 extension for PHP using OpenSC library. PKCS#11 is a software API for accessing cryptographic hardware like smart cards or HSMs. OpenSC library is implementation of PKCS#11 for Firefox and Thunderbird. Could someone tell me if ours finished work can be included in official PHP release?? Regards, Tom -- 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] SVN Account Request: stealth35
You don't need an SVN account to start helping improve PHP. Patch can be mailed to the list or the other appropriate list for review first. - Scott On Jul 9, 2010, at 8:34 AM, stealth35 wrote: Improve php -- 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] Single-line comment problem
Yeah because /* */ has a clear end where // and # doesn't.
- S
On 8 Jul 2010, at 12:50, jvlad d...@yandex.ru wrote:
Parsing ends with ? regardless if its a comment or not but its not
context sensitive. It can't understand that its within a string.
- S
Not exactly, it's only // comment style does not comment the tag while /* */
does.
The following script outputs its 'afafa':
?php
if(true){
/* echo '?php date('Y-m-d H:i:s'); ?'; */
echo 'afafa';
}
?
-j
--
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] Single-line comment problem
The scanner is looking for \r \n % if ASP tags are enabled or ? before it
marks the end of the comment.
Take the following
?php
echo 'PHP';
// echo $moo; ? I am HTML, hear me roar!
Parsing ends with ? regardless if its a comment or not but its not context
sensitive. It can't understand that its within a string.
- S
On Jul 7, 2010, at 7:26 PM, Shijiang wrote:
Hi
I'm not sure whether it's really a bug.
The following sample code will emit a parse error.
?php
if(true){
//echo '?php date('Y-m-d H:i:s'); ?';
echo 'afafa';
}
?
The parser treate the PHP tag within the commented line as a normal tag .
--
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] SVN Account Request: kevinrr3
This is for access to the PHP language repository. You don't need an account to use PHP. Scott On 4 Jul 2010, at 14:00, Kevin Raap kev...@live.nl wrote: Programming with partner without destroying each others code -- 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] SVN Account Request: johnyp
What code? You only need a SVN account if you have something to contribute to the PHP runtime. - Scott On Jun 28, 2010, at 8:03 AM, johny pukhramba, wrote: Maintaining my code for group of people working together on the same latest code. -- 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] APC in trunk
On Jun 20, 2010, at 10:06 PM, Rasmus Lerdorf wrote: On 6/20/10 7:55 PM, Scott MacVicar wrote: On Jun 20, 2010, at 11:21 AM, Ilia Alshanetsky wrote: I for one think it is a really good idea, there is no compelling reason not to include APC, I would even go as far as say we should enable it by default. +1 We'd need to get http://wiki.php.net/rfc/zendsignals committed before we even get it in the core. At the moment if the script gets killed while the cache was being cleaned it up it never unlocks it and your server is essentially dead. Depends on the locking mechanism. As long as you have owner-death protection in your lock, you are fine for this particular problem. shire's patch was fine, I think the only thing missing from it was Windows support though tbh its no worse than what is there before. - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC in trunk
On Jun 20, 2010, at 11:21 AM, Ilia Alshanetsky wrote: I for one think it is a really good idea, there is no compelling reason not to include APC, I would even go as far as say we should enable it by default. +1 We'd need to get http://wiki.php.net/rfc/zendsignals committed before we even get it in the core. At the moment if the script gets killed while the cache was being cleaned it up it never unlocks it and your server is essentially dead. - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
On Jun 18, 2010, at 10:50 AM, Jonathan Bond-Caron wrote: On Wed Jun 16 07:04 AM, Ilia Alshanetsky wrote: drop the Sqlite2 extensions from Trunk as they are superseded by the Sqlite3 extensions. The sqlite2 library is no longer maintainer and the migration path from version 2 to 3 is very simple. Unless there any objections, I'd like to make this happen in the next week or two. I'm all for starting to use sqlite3 but I found two issues with the migration to the new api: a) sqlite_busy_timeout is not available in sqlite3.c This is important for an application to return a failure right away instead of wait for locks to be release. The patch looks simple since it's a wrapper for There is a patch going around, someone should commit it or I will. SQLITE_API int sqlite3_busy_timeout(sqlite3*, int ms); b) No persistent connections Any reason why it wasn't migrated from sqlite.c? Persistent connections make sense if there is an actual overhead in creating a socket etc, it doesn't really apply and is actually more dangerous if something is left unfinished and locks the DB. - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What gruntwork needs to be done
On Apr 6, 2010, at 10:34 AM, Rasmus Lerdorf wrote: On 04/06/2010 10:08 AM, Justin Dearing wrote: So pending review an acceptance by Dmitry, I've written my first patch for PHP. While there is a good chance I will need to make further revisions to the test or code, I don't know what that is. However, I've got some free time at the moment, and I'd like to make use of some of the sunk costs of figuring out how to hack PHP. So I know that in general there is a lot of work to be done. I also know that there are plenty of open bugs, tests to be written, etc etc. What I am looking for is someone to say is here are the next 10 bugs I will work on can you write me test or I wrote this patch on linux, I need someone to make it work on windows too or, Party X complains of this but refuses to fill out a proper bug report. Here is a straightforward (but not easy) one: http://bugs.php.net/bug.php?id=47435 The php_filter_validate_ip() function in ext/filter/logical_filters.c needs those reserved IPV6 ranges added to the FORMAT_IPV6 case in the switch statement there when FILTER_FLAG_NO_RES_RANGE is set. I say it isn't super easy because we don't have much in the way of ipv6 parsing in PHP yet, so it will probably involve finding some decent code that can expand an ipv6 notation into something we can logically separate. That might also mean a rewrite of the _php_filter_validate_ipv6() function in the same file. Another one, if you are interested in encoding issues: http://bugs.php.net/bug.php?id=49687 I don't necessarily agree with Scott that it is wrong to expect addslashes() to validate the input string. It could call get_next_char() the same way php_escape_html_entities_ex() in ext/standard/html.c does. And we need that utf8_decode() fix mentioned in the report reviewed/committed if it hasn't been already. I fixed utf8_decode and I had a patch for adding utf8_validate which is probably suitable for 5.4. http://whisky.macvicar.net/patches/utf8-string.diff.txt It's not quite done, I had intentions of adding support for using truncate, simple true / false for valid or the unicode replacement character. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What gruntwork needs to be done
On Apr 6, 2010, at 10:54 AM, Rasmus Lerdorf wrote: On 04/06/2010 10:47 AM, Scott MacVicar wrote: On Apr 6, 2010, at 10:34 AM, Rasmus Lerdorf wrote: On 04/06/2010 10:08 AM, Justin Dearing wrote: So pending review an acceptance by Dmitry, I've written my first patch for PHP. While there is a good chance I will need to make further revisions to the test or code, I don't know what that is. However, I've got some free time at the moment, and I'd like to make use of some of the sunk costs of figuring out how to hack PHP. So I know that in general there is a lot of work to be done. I also know that there are plenty of open bugs, tests to be written, etc etc. What I am looking for is someone to say is here are the next 10 bugs I will work on can you write me test or I wrote this patch on linux, I need someone to make it work on windows too or, Party X complains of this but refuses to fill out a proper bug report. Here is a straightforward (but not easy) one: http://bugs.php.net/bug.php?id=47435 The php_filter_validate_ip() function in ext/filter/logical_filters.c needs those reserved IPV6 ranges added to the FORMAT_IPV6 case in the switch statement there when FILTER_FLAG_NO_RES_RANGE is set. I say it isn't super easy because we don't have much in the way of ipv6 parsing in PHP yet, so it will probably involve finding some decent code that can expand an ipv6 notation into something we can logically separate. That might also mean a rewrite of the _php_filter_validate_ipv6() function in the same file. Another one, if you are interested in encoding issues: http://bugs.php.net/bug.php?id=49687 I don't necessarily agree with Scott that it is wrong to expect addslashes() to validate the input string. It could call get_next_char() the same way php_escape_html_entities_ex() in ext/standard/html.c does. And we need that utf8_decode() fix mentioned in the report reviewed/committed if it hasn't been already. I fixed utf8_decode and I had a patch for adding utf8_validate which is probably suitable for 5.4. http://whisky.macvicar.net/patches/utf8-string.diff.txt It's not quite done, I had intentions of adding support for using truncate, simple true / false for valid or the unicode replacement character. My only issue with this is that it essentially duplicates the utf8 part of get_next_char() from html.c. I'd like to see cs parsing in one place instead of spread out all over the code tree. The get_next_char() function also supports other charsets, so we could have a more generic cs_validate() function along with utf8_validate(). I missed this function last year, abstracting that and making it PHPAPI would be awesome. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: ariva
You contribute some patches first to internals and after that's been done a few times we give out an SVN account. Scott On 12 Mar 2010, at 19:01, Arunas Ivanauskas arunas.ivanaus...@gmail.com wrote: Fixing bugs, developing the PHP runtime, can contribute ~10h/w -- 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: svn: /php/php-src/branches/PHP_5_3/ README.NEW-OUTPUT-API Zend/zend_highlight.c Zend/zend_indent.c ext/iconv/iconv.c ext/session/session.c ext/soap/soap.c ext/standard/basic_functi
On Mar 11, 2010, at 10:22 AM, Jani Taskinen wrote: On 03/11/2010 04:41 PM, Lukas Kahwe Smith wrote: @jani: committing to a stable branch because you are getting a new laptop is not really a convincing argument. :) Losing the one with the changes in it is. Doing patches will only cause endless headaches. Please move on, nothing to see here, it's all for GOOD anyway, fixing bugs USED to be okay in any branch. Besides, this is not end-of-world. If it is for someone, I suggest changing profession. I'd like to have branch for PHP_5_4, I'll also volunteer for RM on it. Perhaps it makes people wanting to get movement in HEAD to actually do something about it. +1 I'm all for 5.4, I have a bunch of patches against PHP_5_3 that I want to commit such a large integer support, I couldn't develop against HEAD since it's just not usable. I think we can officially call PHP6 stalled and should move forward with 5.4 and revisit unicode support in the future. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unserialize is broken
Java has a transient keyword to skip serialising a property and I have
a patch against 5.3 on http://whisky.macvicar.net/patches/
It might make it in to 5.4/6/next once I get some more free time.
Scott
On 1 Mar 2010, at 02:10, Jordi Boggiano j.boggi...@seld.be wrote:
On 01.03.2010 10:31, Tjerk Meesters wrote:
If visibility is an issue why not just use json_enode/decode for this
case then?it doesn't seem like a typical enough problem to be solved
low-level and json seems fast enough for the job ;-)
Honestly I personally don't care, it won't happen to me again, I
know it
now, but I want it to be fixed for the benefit of others. Sure it's a
rare case, but if you're gonna pretend it's ok that objects have ghost
properties set to them that are unreadable, I guess there is no
point in
discussing this further.
Should I btw remind you that the following results in a Fatal error:
Cannot redeclare Test::$foo ?
class Test {
protected $foo;
public $foo;
}
So it's illegal, but let's do it anyway because in php core it's funny
to do weird stuff that doesn't make any sense?
And in any case json_encode doesn't work the same at all since it
doesn't encode protected properties, and doesn't store the object
type,
so it'd be much more work.
Cheers,
Jordi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [DOC-BUGS] #50634 [Opn-Asn]: 'Core' introduced in 5.3.1
On Mon, Jan 4, 2010 at 12:49 PM, Richard Quadling rquadl...@googlemail.com wrote: I can see that the key went from internal to mhash at V5.3.0 and from mhash to Core at V5.3.1 on Windows. Is this also true for non-windows please? http://bugs.php.net/bug.php?id=50634 says Windows or linux, but on http://bugs.php.net/bug.php?id=49223 Jani says this Seems to be windows only issue.. Does it apply only to mhash or does it happen for other exts as well? It may be due to the hack to make mhash visible as extension while not existing anymore (BC layer provided by hash). It only happened when mhash was a shared extension afaik, and since most of the time on Linux its static it never showed up there. The mhash thing was a bug and it should have been internal in 5.2 and Core in 5.3. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A patch for bug 44331
The JSON API is exported and can't change it as it breaks the ABI. I know the memcached extension uses this. I'll look into adding something similar this week, thanks for the patch. S On 9 Dec 2009, at 21:54, Florian Anderiasch wrote: bug_44331.patch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A patch for bug 44331
Ignore me, it's fine and I'll apply it soon. S On 9 Dec 2009, at 21:58, Scott MacVicar wrote: The JSON API is exported and can't change it as it breaks the ABI. I know the memcached extension uses this. I'll look into adding something similar this week, thanks for the patch. S On 9 Dec 2009, at 21:54, Florian Anderiasch wrote: bug_44331.patch -- 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] No core file being created
On 10 Nov 2009, at 13:55, Mark Skilbeck wrote: I'm trying to debug a segfault that's occuring in an extension I'm developing (phpgksu - PHP wrapper for libgksu2). On the PHP site it says that if I have PHP configured with --enable-debug (which I do) then whenever PHP crashes a core file should be created in the same directory the file is executing. However, I do not see one. I've even run the command as sudo ($ sudo php /file.php) to make sure PHP has the permissions to write the file. Any ideas? ulimit -c unlimited So you can enable core files, the debug mode in PHP just stops optimizations and stripping of symbols producing a more useful core file. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] typo found in ext/standard/string.c, inside function nl2br, php 5.3.0 svn trunk
On 6 Nov 2009, at 03:18, daqing wrote:
hi, all:
I just found a typo today when I read the source code of function
nl2br,
here is what 'svn diff' produce against the php 5.3.0 svn trunk:
Index: ext/standard/string.c
===
--- ext/standard/string.c (revision 290364)
+++ ext/standard/string.c (working copy)
@@ -3918,7 +3918,7 @@
tmp = str;
end = str + str_len;
- /* it is really faster to scan twice and allocate mem once
insted
scanning once
+ /* it is really faster to scan twice and allocate mem once
instead
scanning once
and constantly reallocing */
while (tmp end) {
if (*tmp == '\r') {
This typo and the grammatical error are fixed now.
besides, I have a question: why not function nl2br just replace the
\r\n,
\n, \r things with br/? why insert br/ before those \r
\n,
\n, \r?
Because its much easier to read the output when the newlines are
preserved.
Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Seg fault when using active_symbol_table called from userspace function.
On 1 Nov 2009, at 21:09, Mark Skilbeck markskilb...@gmail.com wrote:
Can you explain to me why the following causes a segfault:
[code]
PHP_FUNCTION(sample_var_a_exists)
{
if (!zend_hash_exists(EG(active_symbol_table), a, sizeof(a))) {
RETURN_BOOL(0);
}
RETURN_BOOL(1);
}
[/code]
Note: the segfault only occurs when the sample_var_a_exists function
is called from within a userspace function:
[code]
$a = '';
var_dump(sample_var_a_exists()); // bool(true)
function x() {
var_dump(sample_var_a_exists()); // segmentation fault
}
x()
There is no symbol table as there are no variables. You should check
if it's NULL before using zend_hash_exists.
Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Seg fault when using active_symbol_table called from userspace function.
On 1 Nov 2009, at 21:41, Mark Skilbeck wrote:
Scott MacVicar wrote:
On 1 Nov 2009, at 21:09, Mark Skilbeck markskilb...@gmail.com
wrote:
[snip]
There is no symbol table as there are no variables. You should
check if it's NULL before using zend_hash_exists.
Scott
Hi, Scott. I'm having trouble - I added the check to see if the
symbol table i available, yet it returns false even if I have added
variables within the function:
[code]
PHP_FUNCTION(sample_var_a_exists)
{
if (!EG(active_symbol_table) ||
!zend_hash_exists(EG(active_symbol_table), a,
sizeof(a))) {
RETURN_BOOL(0);
}
RETURN_BOOL(1);
}
[/code]
[code]
$a = '';
var_dump(sample_var_a_exists());
function x() {
$a = ''; // Add a symbol to the hash table.
var_dump(sample_var_a_exists()); // Shows bool(false)
}
x();
[/code]
--
You probably want the following to build the symbol table.
if (!EG(active_symbol_table)) {
zend_rebuild_symbol_table(TSRMLS_C);
}
Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Secure SVN access
On 3 Sep 2009, at 13:48, techtonik wrote: Greeetings to php-core developers, Am I right that there is no https:// and svn+ssh:// access to svn.php.net repositories? If that's the case - how do you feel about sniffing developer's passwords? We use Digest authentication so while they are sniffable its not replayable and they are hashed with a nonce. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't use embeded sapi
On 9 Aug 2009, at 22:52, Farley Knight wrote:
On Mon, Jul 13, 2009 at 7:17 PM, Paul Biggarpaul.big...@gmail.com
wrote:
Hi Thomas,
On Mon, Jul 13, 2009 at 9:15 PM, Thomas Kochtho...@koch.ro wrote:
gcc -c -I/usr/local/include/php/ -I/usr/local/include/php/main -
I/usr/local/include/php/Zend -I/usr/local/include/php/TSRM -Wall -
g -o
worker.o worker.c
gcc -L/usr/local/lib -lphp5 -o worker worker.o
worker.o: In function `main':
/var/checkouts/gearman-php-worker/worker.c:5: undefined reference to
`php_embed_init'
/var/checkouts/gearman-php-worker/worker.c:6: undefined reference to
`php_embed_shutdown'
collect2: ld returned 1 exit status
make: *** [all] Error 1
This worked for me, with your commands and program. Since its a
linker
error, it seems likely that you haven't installed libphp5.so
properly.
You didn't indicate that you ran make install, did you? If so, you
may
want to verify that there is a libphp5.so in /usr/local/lib, and that
it is a shared library.
I don't think Thomas is completely off here.. For most of the morning
I've been trying to compile 5.3.0:
make clean; ./configure --enable-embed=shared; make sudo make
install
But when I went to build
#include sapi/embed/php_embed.h
int main(int argc, char *argv[]) {
PHP_EMBED_START_BLOCK(argc, argv);
PHP_EMBED_END_BLOCK();
return 0;
}
using
gcc -o embed_test embed_test.c -I/usr/local/include/php/
-I/usr/local/include/php/main -I/usr/local/include/php/Zend
-I/usr/local/include/php/TSRM -L/usr/local/lib -lphp5
I kept getting
/tmp/cc9OgNuw.o: In function `main':
embed_test.c:(.text+0x21): undefined reference to `php_embed_init'
embed_test.c:(.text+0x65): undefined reference to `php_embed_shutdown'
However, when I run config and make for 5.2.10, the test file compiles
just fine. Something must have changed between the two versions... Not
sure what, though.. Probably will dig deeper into this..
This fixed in SVN already, the visibility for the two functions
stopped them being exposed in the library.
Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
On 4 Aug 2009, at 00:08, dan...@zoltak.com wrote: Quoting Jani Taskinen jani.taski...@sci.fi: Yes. You shouldn't really do it like that. Unpack it in separate directory. And build outside the sources: # tar zxfv php5.2-x.tar.gz # mkdir php_5_2 # cd php_5_2 # ../php5.2-x/configure --disable-all --enable-debug and the rest of relevant options here # make # make install I've tried to compile from SVN and recieved the following error: configure: error: Found invalid flex version: 2.5.33. Supported flex versions are: 2.5.4. Is there a simple fix for this? The fix is very very simple, you just Install flex 2.5.4. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
On 4 Aug 2009, at 03:14, dan...@zoltak.com wrote: Quoting Jani Taskinen jani.taski...@sci.fi: Yes. You shouldn't really do it like that. Unpack it in separate directory. And build outside the sources: # tar zxfv php5.2-x.tar.gz # mkdir php_5_2 # cd php_5_2 # ../php5.2-x/configure --disable-all --enable-debug and the rest of relevant options here # make # make install I couldn't get the direct SVN checkout to compile so I compiled the latest SNAP as above with the same result with the previous gdb. Again the segmentation fault occurs when an .htaccess is defined with an error_log and the custom_open_base_check is introduced that does a DOCUMENT_ROOT lookup. In PHP 5.2.6 this worked without issue. I have noticed the problem is intermittent i.e. it fails about 9/10 times. My questions are: 1. Is it safe to lookup the DOCUMENT_ROOT in fopen_wrappers. If not is there an alternative? Not at the point the function is being executed on a fresh child start PHP hasn't always been fully started by the time it's doing the config merging. None of the SAPI variables have been imported. You might be able to use sapi_getenv(DOCUMENT_ROOT, sizeof(DOCUMENT_ROOT)) Another solution is to skip doing you check before the SAPI is loaded :-) 2. Why was this working in PHP 5.2.6 but now broken in 5.2.1x? Are you sure you were using 5.2.6? We never checked the error_log value until 5.2.4, it's the first version to have it. 3. Is the problem related to Zend doing something it shouldn't? Doubtful, the reason its erroring is because the hash table you've given it isn't a hash table at that point. It's random memory. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
On 4 Aug 2009, at 04:49, dan...@zoltak.com wrote: Quoting Scott MacVicar sc...@macvicar.net: 1. Is it safe to lookup the DOCUMENT_ROOT in fopen_wrappers. If not is there an alternative? Not at the point the function is being executed on a fresh child start PHP hasn't always been fully started by the time it's doing the config merging. None of the SAPI variables have been imported. You might be able to use sapi_getenv(DOCUMENT_ROOT, sizeof(DOCUMENT_ROOT)) This method dosen't appear to work. Any chance of a clarification on doesn't appear to work? Does it fail to compile or is it killing unicorns :-) Another solution is to skip doing you check before the SAPI is loaded :-) If we do this then we cannot determine if the error_log is in the DOCUMENT_ROOT. This was the vulnerability that we were fixing in the first place and no doubt the source of the error. 2. Why was this working in PHP 5.2.6 but now broken in 5.2.1x? Are you sure you were using 5.2.6? We never checked the error_log value until 5.2.4, it's the first version to have it. Yes I am positive it was PHP 5.2.6 - It worked with 5.2.4 and 5.2.5 as well. It would be intresting to understand why it worked in these versions. Do you know the first version it stopped working? 5.2.7 - 5.2.10 is about 15 months worth of bug fixes. Narrowing it down to a particular version would help. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
On 4 Aug 2009, at 05:36, dan...@zoltak.com wrote: Quoting dan...@zoltak.com: Quoting Scott MacVicar sc...@macvicar.net: [snip] Do you know the first version it stopped working? 5.2.7 - 5.2.10 is about 15 months worth of bug fixes. Narrowing it down to a particular version would help. I will determine the first version it stopped working with and get back to you. The issue starts from 5.2.8 only had a single fix over 5.2.7 in the change log. Looking over the 5.2.7 change log I found: Added logging option for error_log to send directly to SAPI. (Stas) That adds an option to the PHP function error_log() no changes to the actual SAPI code. http://svn.php.net/viewvc?view=revisionrevision=268964 It could be related to the following patch to do with evaluation order of per directory configuration http://svn.php.net/viewvc?view=revisionsortby=daterevision=269640 Again it's another security issue that was resolved. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_SERVER keys in PHP 6
On 26 Jul 2009, at 01:25, Greg Beaver wrote: Hi, In PHP 6, is there a reason all of the keys in $_SERVER are binary except for PHP_SELF, which is unicode? The ones that come from the SAPI the end up binary, the ones added internally by PHP end up with unicode keys because we can guarantee they're valid. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote: Aloha, So the last fix is just being prepared for a commit and so we will be tagging 5.3.0 soon. We would like to up hold the commit freeze until 5.3.0 is announced next Tuesday. This freeze that you guys have implemented is frustrating, just branch 5_3 into a release branch and Johannes can take selective fixes from 5_3 as needed. We all know your reasons for the freeze and agree with it but holding up regular development is a PITA. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
On 26 Jun 2009, at 19:59, Lukas Kahwe Smith wrote: On 26.06.2009, at 20:26, Pierre Joye pierre@gmail.com wrote: On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicarsc...@macvicar.net wrote: On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote: Aloha, So the last fix is just being prepared for a commit and so we will be tagging 5.3.0 soon. We would like to up hold the commit freeze until 5.3.0 is announced next Tuesday. This freeze that you guys have implemented is frustrating, just branch 5_3 into a release branch and Johannes can take selective fixes from 5_3 as needed. We all know your reasons for the freeze and agree with it but holding up regular development is a PITA. It is not holding up development. It is about getting a viable release cycle and to give us the minimum safety to release 5.3.1 in a reasonable time frame. Please explain me what's wrong to allow only bug fixes for this phase? Also please note that we have HEAD for all the developments and new features. Exactly. I will do my best to track things that need to be merged. Best is to note if something needs to be merged. But if you all feel it's such a huge burden then you can of course insist on putting the burden on the RMs. The fact of the matter is that our current infrastructure is not fit for providing both sides with an efficient solution. If we're freezing some more after this release for the SVN conversion then we could have a pretty cold branch for another week or so. As I've already said, I agree with only allow verified bug fixes by Johannes into 5.3.0. it's this extra bureaucracy that is getting added on top that's sucking hard. I don't want to leave it up to someone else to merge it into 5.3, I should be doing it myself. It's possible that things could get accidentally missed wen someone else is applying it. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
I *completely* agree with making sure 5.3.0 is stable and stopping extra things sneaking their way in. I just don't like the way that it is being done. If the release is tagged and built, then why continue with the freeze? Why not open it up for bug fixes towards 5.3.1? If the reason that you're about to be given is, we might find something critical and need to re-roll 5.3.0 then branch from the tag you've created, fix what's needed and re-tag. Even though CVS sucks it does allow this. This is the way the Mozilla project has done it for years, following their example we'd just create a PHP_5_3_RELBRANCH and work from that. The RMs are the only ones that get to decide what goes in after the freeze. https://wiki.mozilla.org/SeaMonkey:Release_Process Scott On 26 Jun 2009, at 21:12, Pierre Joye wrote: you totally misunderstood the mail. The freeze is about the days between now and the release itself on Tuesday (monday evening actually). That's perfectly valid. The idea then is to allow only bug fixes in 5.3.1, and only bug fixes. What's wrong with that? -- Pierre On Fri, Jun 26, 2009 at 9:26 PM, Scott MacVicarsc...@macvicar.net wrote: On 26 Jun 2009, at 19:59, Lukas Kahwe Smith wrote: On 26.06.2009, at 20:26, Pierre Joye pierre@gmail.com wrote: On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicarsc...@macvicar.net wrote: On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote: Aloha, So the last fix is just being prepared for a commit and so we will be tagging 5.3.0 soon. We would like to up hold the commit freeze until 5.3.0 is announced next Tuesday. This freeze that you guys have implemented is frustrating, just branch 5_3 into a release branch and Johannes can take selective fixes from 5_3 as needed. We all know your reasons for the freeze and agree with it but holding up regular development is a PITA. It is not holding up development. It is about getting a viable release cycle and to give us the minimum safety to release 5.3.1 in a reasonable time frame. Please explain me what's wrong to allow only bug fixes for this phase? Also please note that we have HEAD for all the developments and new features. Exactly. I will do my best to track things that need to be merged. Best is to note if something needs to be merged. But if you all feel it's such a huge burden then you can of course insist on putting the burden on the RMs. The fact of the matter is that our current infrastructure is not fit for providing both sides with an efficient solution. If we're freezing some more after this release for the SVN conversion then we could have a pretty cold branch for another week or so. As I've already said, I agree with only allow verified bug fixes by Johannes into 5.3.0. it's this extra bureaucracy that is getting added on top that's sucking hard. I don't want to leave it up to someone else to merge it into 5.3, I should be doing it myself. It's possible that things could get accidentally missed wen someone else is applying it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
You have an assignment instead of a comparison there. Scott On 27 Jun 2009, at 00:52, Ilia Alshanetsky wrote: curl.txt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Do you need different OS/platform to test on? Let me know
On 26 Jun 2009, at 23:29, Hannes Magnusson wrote: Hi all Is there *anyone* who needs anything to be able to debug bug reports, run sanitychecks, developing.. or whatever? We really need to improve our architecture/platform/os testing, even if its just make all compile checks. On php-webmaster@ we get a lot of companies who can provide us with whatever os/platform/architecture we could possibly need mailing in and asking how they can help. I get a lot of these kind of inquiries, and have a good chunk which I haven't replied to at all, so please let me know if you need *anything at all*. I think we should look at getting buildbot setup and deployed to as many machines as humanly possible. It would at least give us a heads up when we've written something that doesn't work. You can see the ones for Google Chromium at http://build.chromium.org/buildbot/waterfall/waterfall It just needs someone to spend the time writing the initial slave deployment script, any volunteers? :) Scott -- Sorry for the 2nd email Hannes, forgot reply all. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Do you need different OS/platform to test on? Let me know
On 27 Jun 2009, at 03:30, Mark Karpeles wrote: Hi, Le samedi 27 juin 2009 à 02:24 +0100, Scott MacVicar a écrit : I think we should look at getting buildbot setup and deployed to as many machines as humanly possible. It would at least give us a heads up when we've written something that doesn't work. You can see the ones for Google Chromium at http://build.chromium.org/buildbot/waterfall/waterfall It just needs someone to spend the time writing the initial slave deployment script, any volunteers? :) This looks like something that matches my subset of things I can do. I already had some ideas about this, and already done an interface that can display various test information on a same page. http://php.magicaltux.net/browse/ (lots of memleaks reported on 5.3 HEAD, seems to be glibc-related and not real memleaks, and this is not up-to-date as I didn't run the tests for a while and didn't automate it because it takes a lot of cpu) Of course we can also make something that looks like Google's waterfall, but I don't find it to be really easy to read. The good thing with the interface I made is the fact you can see the status for all modules directly, eg: http://php.magicaltux.net/browse/ext/ I could, instead of providing branch columns provide instead arch columns, and let the user select what he want to see before accessing the interface (ie. compare all arch on branch PHP_5_3). Anyway that is just an idea, the good part is that most of the code has been written, missing parts would be ability to remotely provide compile results (ie. run tests from a different arch) and make code looks better (I wrote this under influence of beer, the code is missing comments). Would also need a deployment script as suggested by Scott that will initialize a slave directly, saving the time required to install this on xxx comptuers. I don't think I explained Buildbot properly, its more than just a test runner, its kind of glue to join together an applications various building and testing results and capture it all and report back to the build master. We'd just need to write a few dozen lines of configuration script that tells the slaves what to do. They aren't that hard, it just requires someone to sit and write the first version. You write a bootstrapping master.cfg in python and it can then spawn whatever other language it wants, in our case probably the freshly built PHP ;-) From there it can run tests and do whatever we wish with the results, like grab all test failures and upload it to your test result viewer. If a build fails we can have it use twitter / irc to inform people that a slave failed to build PHP for whatever reason. It's also got various scheduling parts built in, so we can do continuous regular builds to make sure its still compiling and daily memory builds to check for new memory leaks. Other cool features are notifying people when it broke via IRC, twitter or mailing list. And optionally packaging the freshly built tests and uploading them. We could hypothetically get our snapshots built this way so we never release a broken snapshot? The project URL is http://buildbot.net/trac and the vast documentation is at http://djmitche.github.com/buildbot/docs/0.7.10/ I might be able to sit down and give this a go on the plane next week. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for bug #48575
Gwynne Raskind wrote: On Jun 18, 2009, at 10:46 AM, Gwynne Raskind wrote: Here is a nice simple patch for #48575 which rips out the mach-o/dyld.h functionality in Zend (as suggested by the original reporter and the Apple comment). According to my testing this not only doesn't break anything, but actually doesn't change anything either except removing some dead code and removing one configure check. Per Pierre's request, I'm sending it here for review :) Looks good for me, apply to HEAD and document somewhere that we need 10.2 as the minimum version. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP Bug 48215
Hey,
Bug 48215 was a BC break from the previous 5.2 behaviour, it stemmed
from a change for bug #39127.
class a { function a($arg='') { echo $arg; } }
class b extends a {}
$b = new b;
$b-b('foo');
$b-__construct('foo');
This prints out an error in 5.3 which is fine, the unexpected change
was that if a __construct() method was actually defined as well as a
method that matched the class name it would alias the parent method to
the constructor. The test is attached in the patch.
Just sending off to internals first since we're so late in the RC stage.
Scott
Index: tests/bug48215.phpt
===
RCS file: tests/bug48215.phpt
diff -N tests/bug48215.phpt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ tests/bug48215.phpt 17 Jun 2009 15:37:26 -
@@ -0,0 +1,38 @@
+--TEST--
+Bug #48215 - parent::method() calls __construct
+--FILE--
+?php
+class A
+{
+ public function __construct() {
+ echo __METHOD__ . \n;
+ }
+ protected function A()
+ {
+ echo __METHOD__ . \n;
+ }
+}
+class B extends A
+{
+ public function __construct() {
+ echo __METHOD__ . \n;
+ parent::__construct();
+ }
+ public function A()
+ {
+ echo __METHOD__ . \n;
+ parent::A();
+ }
+}
+$b = new B();
+$b-A();
+?
+===DONE===
+--EXPECTF--
+
+Strict Standards: Redefining already defined constructor for class A in %s on
line %d
+B::__construct
+A::__construct
+B::A
+A::A
+===DONE===
Index: zend_object_handlers.c
===
RCS file: /repository/ZendEngine2/zend_object_handlers.c,v
retrieving revision 1.135.2.6.2.22.2.29
diff -u -r1.135.2.6.2.22.2.29 zend_object_handlers.c
--- zend_object_handlers.c 12 Jun 2009 21:36:53 -
1.135.2.6.2.22.2.29
+++ zend_object_handlers.c 17 Jun 2009 15:37:26 -
@@ -28,6 +28,7 @@
#include zend_object_handlers.h
#include zend_interfaces.h
#include zend_closures.h
+#include zend_compile.h
#define DEBUG_OBJECT_HANDLERS 0
@@ -941,7 +942,8 @@
if (function_name_strlen == ce-name_length ce-constructor) {
lc_class_name = zend_str_tolower_dup(ce-name, ce-name_length);
- if (!memcmp(lc_class_name, function_name_strval,
function_name_strlen)) {
+ /* Only change the method to the constructor if a __construct()
method doesn't exist */
+ if (!memcmp(lc_class_name, function_name_strval,
function_name_strlen) memcmp(ce-constructor-common.function_name,
ZEND_CONSTRUCTOR_FUNC_NAME, sizeof(ZEND_CONSTRUCTOR_FUNC_NAME))) {
fbc = ce-constructor;
}
efree(lc_class_name);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] seems 5.3RC3 is too unstable
On 17 Jun 2009, at 00:03, jvlad wrote: Hi All, Did anybody experiece troubles compiling php 5.3RC under FreeBSD 6.2/ amd64, NetBSD 3.1/x86, and OpenBSD 4.1/x86? Under these platforms gcc hangs in php-5.3.0RC3/ext/fileinfo/libmagic/apprentice.c. Disabling fileinfo produces further errors in spl and date. Under Solaris 2.8/Sparc/Sparc64 php coredumps installing/generating phar.phar and if it is disabled coredumps installing PEAR Under windows php crashes in fastcgi... I've got no problems only under FreeBSD 6.2/x86, Solaris 2.10/amd64, and Linux 2.4, 2.6/x86/amd64. Plan to share any of these errors with us? We don't have all platforms available for testing. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
Giovanni Giacobbi wrote: On Thu, May 14, 2009 at 10:04:36PM +0200, Pierre Joye wrote: hi Ilia, On Thu, May 14, 2009 at 8:54 PM, Andrei Zmievski and...@gravitonic.com wrote: Jani Taskinen wrote: It's still new stuff. And we need more things in 5.3/6 to make them more interesting to general populus too. ;) Great, so I'll just end up copying almost all of ext/json code into pecl/memcached then. Hooray for loose coupling. It is actually not about adding features. If I understand correctly what Andrei likes to have, it is only about exposing the JSON API. That means no code change (no new feature or whatever else) but only adding the right PHP_API related declaration to the right place and install the json header. That could actually be very useful with no impact on the code (userland or extensions). I think we should allow this change. Sorry if I'm not getting this right, but doesn't he have to explicitly require version = 5.2.10 in his pecl/memcached extension? It's not like that with this change his extension is going to work for 5.2.x. Requiring = 5.2.10 is such a strict requirement that should be replaced with = 5.3.0. You can use call_user_func_ex() internally to call it, it's nicer to use the C API though. Though this is the wrong place to ask. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Scanner diet with fixes, etc.
[^] is a special case to write a portable match any character in re2c. Scott Dmitry Stogov wrote: Hi Matt, Does this patch fix EOF handling issues related to mmap()? (e.g. parsing of files with size 4096, 8192, ...). Now we have two dirty fixes to handle them correctly. The patch is quite big to understand it quickly. I'll probably take a look on weekend. -ANY_CHAR [^\x00] +ANY_CHAR [^] Is [^] a correct regular expression? Thanks. Dmitry. Matt Wilmas wrote: Hi Dmitry, Brian, all, Here's a scanner patch that I mentioned awhile ago, with a possible way to work around the re2c EOF handling issues. The primary change is to do a manual scan like I talked about in areas that match large amounts and can contain NULL bytes (strings/comments, which are now scanned faster too), as is done for inline HTML. I called it a diet :-) because it removes my complicated string regex patterns from a couple years ago, which doesn't make the .l file much smaller after adding the manual scan code (easier to understand...?), but it does result in a ~34k reduction of 5.3's generated .c file... This fixes Bug #46817, as well as a better, more proper fix for the older Bug #42767, both related to ending comments. Now inline HTML chunks aren't broken up when a tag starting with s is encountered (script for JS, span, etc.), since it's unlikely to be a long PHP script tag. If an opening PHP SCRIPT tag was used with a capital S, it was missed if it wasn't the first thing scanned: var_dump(token_get_all(HTML... SCRIPT language=php)); Single-line comments with a Windows newline didn't include the full \r\n: var_dump(token_get_all(?php // Comment\r\n?)); Finally, part of the optimized scanning is that, for double quoted strings, when the first variable is encountered (making it non-constant), the amount that's been scanned up to that point is remembered, which can then be skipped over (up to the variable) after returning the quote token. Previously that initial part of the string was rescanned -- the cost dependent on how far into the string the first var is. I think that's about all -- I'll send another message if I forgot to mention anything... Just wanted to send this along quick for to you guys to look at or whatever. It was basically done last week, I just had to do a couple finishing touches and verify that everything was OK. http://realplain.com/php/scanner_diet.diff (Merged changes, but didn't test yet.) http://realplain.com/php/scanner_diet_5_3.diff Thanks, Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) / NEWS
On 27 Apr 2009, at 19:35, Jani Taskinen wrote: Scott MacVicar kirjoitti: scottmacMon Apr 27 18:20:19 2009 UTC Modified files: (Branch: PHP_5_3) /php-src NEWS Log: BFN [snip] crashes). (Dmitry) - Fixed bug #47699 (autoload and late static binding). (Dmitry) +- Fixed bug #47695 (build error when xmlrpc and iconv are compiled + against different iconv versions). (Scott) Why aren't you fixing this in the bugfix branch? It's getting quite boring to ask this same question from EVERYONE all the fucking time. Did some somewhere say that the only active branch is PHP_5_3 suddenly?! For me it was an accident, fixed in 5.2 now. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GCC 4.4.0
Sebastian Bergmann wrote: I experimented a bit with GCC 4.4.0 recently and found out that when compiled with it and -O2, PHP_5_3 segfaults. -O0 and -O1 are fine. PHP_5_2 and GCC 4.4.0 is fine at -O2. 64-bit machine? There is a known issue with 4.3.0 on 64-bit amd. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GCC 4.4.0
Sebastian Bergmann wrote: Scott MacVicar schrieb: 64-bit machine? Nope: s...@ubuntu ~ % uname -a Linux ubuntu 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux s...@ubuntu ~ % /usr/local/gcc/bin/gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr/local/gcc --enable-languages=c,c++ Thread model: posix gcc version 4.4.0 (GCC) Can you set your cflags to -fno-strict-aliasing and try again. This resolved the issue with the previous report. It was bug #47730 Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Like 2 Invole in Google Open source program
On 20 Apr 2009, at 19:34, Jaya Prakash jpawa...@gmail.com wrote: Hello, I saw that google open source program in php.net. I like to invole in it. *Name*: Jayaprakash.G *Proposal*:Working as a Web Developer *Short Description*: Work on web applications. *Full Description*: I worked on 3 projects. Main role like core developing and database schema is done for 2 projects. I'm a dedicated person and like to involve in new things *Timeline*: 1 week *Category (PHP, PECL, other)*: PHP, Javascript, Ajax Your experience: 0.8 Years Your location: Bangalore -- Regards, Prakash Sorry, the application process closed a few weeks ago. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
David Coallier wrote: 2009/4/2 Kalle Sommer Nielsen ka...@php.net: 2009/4/2 Kalle Sommer Nielsen ka...@php.net: Hi Justin Attached a patch instead, hopefully this will work ;) I really do like this idea :) Let's just commit it. Hold your horses, lets not commit things hastily. I'm not a huge fan of adding 6 new INI settings and I think have another idea so we can avoid this and still offer more flexibility. I would however like ot see the naming stucture Justin used in the first example by prefixing the CSS classnames by php. This will greatly help the inclusion into other considering that comment and default are widely used (not sure about the other ones) for general purposes usage (see google codesearch for example). Cool work, do we go by adding 6 new ini settings and making sure they are prefixed by default? Also I guess we'll have to attach a css file with that? Inline css at the top of the generated highlighted block maybe? No, the user would be responsible for producing the CSS sheet that they want. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Focus on HEAD
David Coallier wrote: 2009/3/27 Hannes Magnusson hannes.magnus...@gmail.com: 2009/3/27 Felipe Pena felipe...@gmail.com: Hello, just to inform, I've commited (yesterday) the patch removing the UG(unicode) checks, etc across all source (except mysql exts). As the patch has 492K, looks as no mail will be sent. [...] Would you mind letting the list know when the commit has gone through? That way we can catch any possible bugs quicker? (I know we could simply do cvs up -dP repeatedly until we see changes but y'know ;-)) It went through last night, its the first line of his email... Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] GSoC 2009
Hi All, Just a quick note to say that PHP was accepted as an organisation for GSoC 2009. We have until the 23rd of March to try and liaise with any potential students we have available and work on our ideas list that we might suggest. Our ideas list at http://wiki.php.net/gsoc/2009 has a few good ones that have been expanded, there are also some random ideas that need to be filled out. Student applications open on the 23rd of March at 1900 UTC and run until the 3rd of April. Cheers, Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch and test cases too for
On 11 Mar 2009, at 19:25, Christopher Östlund wrote:
I think this behavior is a bit odd too:
php -r echo json_encode(array(0='test')); // [test]
php -r echo json_encode(array(1='test')); // {1:test}
The reason for this is encoding looks to see if the array is
sequentially numbered from 0 to x, and if so its a compatible
javascript array. If it starts at any other value or skips a number
then it creates an object for its output.
Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 items
Hey Brian, On 9 Mar 2009, at 20:42, shire wrote: Hey Lukas, Just a heads up that I should have a fix for this soonish, just running some more tests to make sure everything works as expected (I assume nobody else has started work on this): 9. tokenizer misses last single-line comment (http://bugs.php.net/bug.php?id=46817 ) What's the details on this one? 20. memory leak in the scanner when a new state stack is created When a file is included and a new state structure is created for the scanner its pushed on to a stack for freeing later on, most of the time this happens as soon as the scanner has parsed the included file but not quite for the tokenizer extension though. At the moment the destructor for the stack is comparing pointers, which are unfortunately different because when you push something with zend_stack it does a copy. I have a fix which just adds an id to the state structure, but this requires a little bit more memory. I think the cleaner fix is to sort the tokenizer extension, just need some more time. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch and test cases too for
Richard Quadling wrote: Hi. Regarding http://bugs.php.net/bug.php?id=47493, I've supplied a patch to the unit tests too. Any chance this could get committed to 5.2+ I'm too convinced of the parameter name and I don't think its something that should be added to 5.2.9 since its a feature. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch and test cases too for
Richard Quadling wrote:
2009/3/2 Scott MacVicar sc...@macvicar.net:
Richard Quadling wrote:
Hi.
Regarding http://bugs.php.net/bug.php?id=47493, I've supplied a patch
to the unit tests too.
Any chance this could get committed to 5.2+
I'm too convinced of the parameter name and I don't think its something
that should be added to 5.2.9 since its a feature.
Scott
5.3+ would be OK then.
As to the param name, I'm not actually changing the name, just adding
another flag.
In javascript's terminology,the output is an array ...
[]
or a hash
{}
So forcing a hash for arrays is pretty much what would be wanted and I
as I comment in the request, we have a force option when coming FROM
json data ... json_decode ( string $json [, bool $assoc= false [, int
$depth= 512 ]] )
And the name of the param here is appropriate to PHP's use (assoc is
not part of JSON's or JS's terminology).
If you can think of a better name for the flag, then I'd be glad to use it.
The JSON spec refers to them as arrays or objects though, as does our
documentation I believe.
PHP_JSON_FORCE_OBJECT
I however have another patch for more strict encoding so I'll try to
roll this in a single update.
Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phar update
Igor Feghali wrote: While trying to perform phar testing on the system previously mentioned by me, I couldn't manage to get php5.3-200902261130 to compile with IBM CC. First 3 lines of error: /tmp/php5.3-200902261130/ext/pcre/pcrelib/pcre_internal.h, line 976.3: 1506-046 (S) Syntax error. /tmp/php5.3-200902261130/ext/pcre/pcrelib/pcre_internal.h, line 1027.3: 1506-046 (S) Syntax error. /tmp/php5.3-200902261130/ext/pcre/pcrelib/pcre_internal.h, line 1137.8: 1506-166 (S) Definition of function BOOL requires parentheses. It seems that BOOL isn't getting defined. Can someone please help me ? It's a bug in PCRE that has been reported, can't find the bug report just now though, you can fix it with a compiler define for using ANSI C. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: towards the next 5.3 release
Greg Beaver wrote: Lukas Kahwe Smith wrote: Aloha, So Johannes and I have chatted about what needs to happen before we can go to RC1. If there are no bigger issues the next version will indeed be RC1. Release sometime in the second half of February. No specific date has been set as of yet. One of the key questions before a date can be set is what kind of issues we still have left to fix: 1) http://bugs.php.net/search.php?status=Openphpver=5.3cmd=display 2) we have the phar issues for big endian systems I don't have access to any big endian systems, so I am appealing to those who do to help me fix these (Scott had mentioned them, but I don't have much information to be able to fix them, or even exactly what they are). https://www.opensolaris.org/register.jspa And then speak to dsp for getting your account added to the test machine. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC 2009
Jani Taskinen wrote: See: http://cvs.php.net/viewvc.cgi/pear/Bugtracker/ That's the pear bug tracker modified for all pear/pecl/php bugs I worked on about 1.5years ago. :) It has that roadmap thing.. The one Barry worked on for GSoC 2008 is at http://cvs.php.net/viewvc.cgi/bugtracker I've only just realised that this isn't a fork of the current tracker, I assumed it was and had been extending the current one. Scott Ilia Alshanetsky wrote: Sean, You make some very good points and I'll be the first to agree there is definitely a room to improve the existing bug-tracker, in particular its integration with the repository commits, but I do not think it needs a fundamental rewrite. From what I can see most (I think its all, but being careful with generalization here) developers already put Fixed bug #... in their bug fixing commits. I would be fairly trivial to add a regex to grab those and automatically close the bug report and even add a link to the diff. As far as branch fix tracking, it could be as simple as adding another SQL table to the bug tracker along the lines of: CREATE TABLE bug_fix_revisions ( bug_id integer not null, branch varchar(25), date timestamp ); We could then add another search page to bug tracker that will give a you a matrix of all the fixes performed between date X and Y looking something like this BUG # | Branch X | Branch Y | Branch Z | ... 1223| (date) | (date) | | .. It would solve your problem, I think and would make RM life easier in terms of tracking fix syncronization On 25-Jan-09, at 9:05 AM, sean finney wrote: hi everyone, On Sat, Jan 24, 2009 at 11:40:08AM -0500, Ilia Alshanetsky wrote: I think our bug current tracker is pretty good and most importantly makes it easy to report and update bugs which is conducive to more issues being reported. Often extra features of bug trackers make them overly complex to use and people just get frustrated with them and don't report bugs as the result. aplogies if what comes is just a little verbose... for those who don't have the luxury of building from the latest CVS snapshot, the current tracker is sorely missing some kind of better integration with your version control system. by a couple orders of magnitude the largest amount of time i spend on maintaining the debian php packages is the result of going on treasure hunts through your cvs logs and commit lists trying to find just which commits map to a particular (usually security vulnerability) bug, and then making sure that there were no regressions in the fix addressed by later commits. take the last issue with the Zip::extractTo()... while you might not consider my request important enough to address (i.e. we don't support 3rd-party distros so we won't go out of our way on this), this has implications for intra-project issues as well. for example, when a bug affects multiple branches, those doing RM work would probably be interested in knowing that the fix was applied to each of the relevant branches. while i'm sure there are more technical ways of integrating support for this, one very easy way is to just map CVS/svn/etc commits to bug reports transparently. if a commit contains something like '#' in the commit message, you could have it post the commit info to the tracker. then a quick read of the bug report should be the only thing necessary to know if each of the branches have recieved a fix. and as a side effect it would also solve the problem for those of us who package/distribute php externally... anyway, sorry if this is hijacking the thread just a bit, but having just spent a large part of my free time doing some of this stuff, i felt compelled to throw this in. sean Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC 2009
On 25 Jan 2009, at 16:12, David Zülke wrote: Am 25.01.2009 um 14:29 schrieb Lukas Kahwe Smith: On 24.01.2009, at 17:40, Ilia Alshanetsky wrote: I think our bug current tracker is pretty good and most importantly makes it easy to report and update bugs which is conducive to more issues being reported. Often extra features of bug trackers make them overly complex to use and people just get frustrated with them and don't report bugs as the result. Personally I think it would be nice to have some sort of milestone support. I think we already had that for a brief moment. I think it would make the bug tracker a very useful tool to see when something will be fixed and more importantly also for historical reasons. Then again we often shuffle around fixes from one branch to another .. so the trick is to make it possible prevent things to get out of whack. Maybe the bug tracker should be our interface to the NEWS file .. then again in order to be that, the solution would need to be super duper rock solid. But it could make the life of the RM's a lot easier. Absolutely. Also, a fix version would be really good, so people can know when a bug was fixed. Also, CVS/SVN post-commit hooks would be nice, so the tickets are annotated with links to the changesets. Right now, if I see someone's comment Fixed in CVS HEAD and PHP_5_3, I need to look at the date, then go to the cvs mailing list or logs and find the respective commit. Cumbersome. If the bug number is in the commit message and we're using subversion then there is no reason we can't add a reference to the revision in the bug. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC 2009
On 25 Jan 2009, at 15:22, Lukas Kahwe Smith wrote: On 25.01.2009, at 16:17, Graham Kelly wrote: Lastly, I really think all the PHP GSoC projects should be hosted in PHP's CVS under a central location (maybe something like /repository/gsoc/2009/projectname/). It was very hard at times to find the work done for other projects. Actually if we havent made the migration to SVN at that point, we should at least use SVN for the GSoC projects. Already the intention, I want all of the projects either in a dedicated GSoC SVN repository or the project wide one if we've got it sorted by then. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] GSoC 2009
Hi Everybody, It's almost that time again where we rush at the last minute to organise something for the Google Summer of Code, so in the interest of being prepared I'm thinking it's time to start collecting ideas for potential students. I've updated a few of the Wiki pages with some things relevant from the Mentor Summit I attended last year about the idea and applying process. One of them is collecting ideas sooner rather than later and trying to make sure there as detailed as possible, including what the deliverables are of the project and any ideas of how it should be implemented. If you don't have a Wiki account feel free to email me with your ideas and I'll add it to the page on your behalf. If we're accepted to the program this year, we can discuss the student selection process a bit more. But first lets get the ideas going. Scott ps. How many people went Hi Dr Nick? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/date/tests date_default_timezone_get_error.phpt date_default_timezone_set_error.phpt date_default_timezone_set_variation1.phpt date_sun_info_error.phpt date_su
Hi Andy, All these tests are broken in an environment that defines a TZ variable, you need to use date_default_timezone_set() Can you fix these please. Scott andy wharmby wrote: wharmby Tue Jan 13 13:38:20 2009 UTC Added files: (Branch: PHP_5_3) /php-src/ext/date/tests date_sun_info_variation1.phpt date_sun_info_variation3.phpt date_default_timezone_set_error.phpt date_sunrise_and_sunset_basic.phpt date_default_timezone_get_error.phpt date_sun_info_variation2.phpt date_sun_info_error.phpt date_default_timezone_set_variation1.phpt Log: New date extension tests. Tested on Windows, Linux and Linux 64 bit -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] status update for beta1
Lukas Kahwe Smith wrote: Hello all, Just wanted to get a status update on the work going on: - Eric and Nathan are working on new php.ini files and I guess they will soon post their proposals to the list - @Steph: have you begun work on the Upgrading Guide? I would really like to have something for beta1. The scratchpad should make it possible to get something going quickly - @Scott: you are working on getting the dns* functions to work on other platforms? It's working on OSX now by using the older bind 8 functions, changes to enable bind 9 require a few more autotools changes. This would hopefully sort out FreeBSD too. For now it works and I'll wait on Pierre to do his dns splitting stuff. - @Marcus: where do you see your closures RFC going? - @Derick: whats the state of the call_user_func segfault? - so are we disabling dl() for 5.3.0? the PHP 6.0.0 plan reads that dl() should be enabled and SAPI's that support it can enable it explicitly. - @Pierre: what about bundling ext/enchant as an ext/pspell replacement? - @Pierre: anything on the windows side we need to worry about? - Ettienne/Lars/Guilherme: whats the status of spl_object_id()/spl_object_hash()? - Whats the status of the __invoke() thread (i did not follow it and havent had time to catch up)? - I guess we are not going to deal with foo.php?a.b.c = 10 in 5.3.0 (should we put something on the 6.0 todo list for this?) - not sure where this item on the todo list came from: Fix static build of extension when static is the default and –enable-snapshot-build is used - not sure where this item on the todo list came from: Improve the build script to ease the parsing of the output and QA - @Felix/Derick: is fileinfo going to get more tests before beta1? - First line of included files not output if they begin with # - Defining namespaced constant using define() defines CASE SENSITIVE namespace - make all extensions use php implementation of getenv (Pierre) - any bugs we should be aware of that need special attention from the RM's? Again the plan is to release beta1 _next_ week, which means we want to freeze function changes either this Friday or next Monday. Not a lot of time .. Can we make it next Monday, I'm away from Wednesday until Sunday afternoon and I have a few more tricky patches to go in. Namely some crashes in fileinfo that require my syncing with further up stream. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dns_get_record for OSX
Hi Kalle, Kalle Sommer Nielsen wrote: Hi Scott 2009/1/7 Scott MacVicar sc...@macvicar.net: I went to look at the bug Pierre mention earlier and noticed that dns_get_record isn't implemented on OS X, this looks to be down to the fact that it has a bind 8 BC layer that we use by default for some reason. I tried to make it use the bind 9 interface but it wasn't a simple task as some other things were missing. End result here is a patch that allows bind 8 to work and therefore OS X, the main difference is that there is a shared _res structure rather than a per request one. Does this mean it will also work on BSD? As far I remember then dns_get_record wasn't implemented on BSD aswell. If not then it would be ideal to support it if OSX is patched :) Yeah it would work on all of the BSDs, though we have some wierd bastardisation of bind8 and bind9 code in dns.c, I think some gentle refactoring is in order to get this in a bit better shape. OS X actually has res_nmkquery but AC_CHECK_FUNC can't correctly detect this because of the way its defined in resolv.h, it's something like this. #define res_nmkquery bind_9_nmkquery AC_CHECK_FUNC does an #undef res_nmkquery as part of its test resulting in the failure. FreeBSD has __res_nmkquery but unfortunately PHP_CHECK_FUNC when checking for res_nmkquery OR __res_nmkquery it doesn't tell you which one it found. I'll fix this in stages I guess, starting with the autoconf fun. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] christmas decorations..
This isn't something for internals, use php-webmaster Scott Nathan Rixham wrote: I just threw the christmas tree out, came online and noticed that the decorations are still up on the php.net site; any idea when they're coming down? ho-ho-ho etc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] dns_get_record for OSX
I went to look at the bug Pierre mention earlier and noticed that
dns_get_record isn't implemented on OS X, this looks to be down to the
fact that it has a bind 8 BC layer that we use by default for some
reason. I tried to make it use the bind 9 interface but it wasn't a
simple task as some other things were missing.
End result here is a patch that allows bind 8 to work and therefore OS
X, the main difference is that there is a shared _res structure rather
than a per request one.
I'll apply this tomorrow if no one has any objections.
Scott
? tests/general_functions/escapeshellcmd-win32.phpt
Index: config.m4
===
RCS file: /repository/php-src/ext/standard/config.m4,v
retrieving revision 1.80.2.3.2.3.2.7
diff -u -r1.80.2.3.2.3.2.7 config.m4
--- config.m4 2 Dec 2008 16:27:15 - 1.80.2.3.2.3.2.7
+++ config.m4 7 Jan 2009 03:25:48 -
@@ -254,6 +254,14 @@
PHP_CHECK_FUNC(dn_expand, resolv, bind, socket)
dnl
+dnl These are old deprecated functions, a single define of
HAVE_DEPRECATED_DNS_FUNCS
+dnl will be set in ext/standard/dns.h
+dnl
+
+PHP_CHECK_FUNC(res_mkquery, resolv, bind, socket)
+PHP_CHECK_FUNC(res_send, resolv, bind, socket)
+
+dnl
dnl Check if atof() accepts NAN
dnl
AC_CACHE_CHECK(whether atof() accepts NAN, ac_cv_atof_accept_nan,[
Index: dns.c
===
RCS file: /repository/php-src/ext/standard/dns.c,v
retrieving revision 1.70.2.7.2.5.2.14
diff -u -r1.70.2.7.2.5.2.14 dns.c
--- dns.c 6 Jan 2009 23:37:28 - 1.70.2.7.2.5.2.14
+++ dns.c 7 Jan 2009 03:25:49 -
@@ -357,7 +357,7 @@
* __libc_res_nsend() in resolv/res_send.c
* */
-#ifdef __GLIBC__
+#if defined(__GLIBC__) !defined(HAVE_DEPRECATED_DNS_FUNCS)
#define php_dns_free_res(__res__) _php_dns_free_res(__res__)
static void _php_dns_free_res(struct __res_state res) { /* {{{ */
int ns;
@@ -663,7 +663,9 @@
zval *authns = NULL, *addtl = NULL;
int addtl_recs = 0;
int type_to_fetch;
+#if !defined(HAVE_DEPRECATED_DNS_FUNCS)
struct __res_state res;
+#endif
HEADER *hp;
querybuf buf, answer;
u_char *cp = NULL, *end = NULL;
@@ -748,11 +750,14 @@
break;
}
if (type_to_fetch) {
+#if defined(HAVE_DEPRECATED_DNS_FUNCS)
+ res_init();
+#else
memset(res, 0, sizeof(res));
res_ninit(res);
res.retrans = 5;
res.options = ~RES_DEFNAMES;
-
+#endif
n = res_nmkquery(res, QUERY, hostname, C_IN,
type_to_fetch, NULL, 0, NULL, buf.qb2, sizeof buf);
if (n0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING,
res_nmkquery() failed);
Index: dns.h
===
RCS file: /repository/php-src/ext/standard/dns.h,v
retrieving revision 1.19.2.1.2.1.2.4
diff -u -r1.19.2.1.2.1.2.4 dns.h
--- dns.h 6 Jan 2009 20:48:20 - 1.19.2.1.2.1.2.4
+++ dns.h 7 Jan 2009 03:25:49 -
@@ -23,7 +23,18 @@
#ifndef DNS_H
#define DNS_H
-#if HAVE_RES_NMKQUERY HAVE_RES_NSEND HAVE_DN_EXPAND HAVE_DN_SKIPNAME
+#if HAVE_RES_MKQUERY !defined(HAVE_RES_NMKQUERY) HAVE_RES_SEND
!defined(HAVE_RES_NSEND)
+#define HAVE_DEPRECATED_DNS_FUNCS 1
+#endif
+
+#if HAVE_DEPRECATED_DNS_FUNCS
+#define res_nmkquery(res, op, dname, class, type, data, datalen, newrr, buf,
buflen) \
+ res_mkquery(op, dname, class, type, data, datalen, newrr, buf, buflen)
+#define res_nsend(res, msg, msglen, answer, anslen) res_send(msg, msglen,
answer, anslen);
+#define res_nclose(res) /* noop*/
+#endif
+
+#if ((HAVE_RES_NMKQUERY HAVE_RES_NSEND) || HAVE_DEPRECATED_DNS_FUNCS)
HAVE_DN_EXPAND HAVE_DN_SKIPNAME
#define HAVE_DNS_FUNCS 1
#endif
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tip for 5.3: exceptions in __toString and __autoload
On 26 Dec 2008, at 01:46, David Grudl wrote:
This code throws *Fatal error*: Method test::__toString() must not
throw an exception
class Test1
{
public function __toString()
{
throw new Exception;
}
}
The same problem causes throwing exceptions in function __autoload.
I think this behavior is against the logic of exceptions. Excellent
feature of PHP 5.3 would be to resolve this errors.
This is down to the design of the engine, we perform casting to
strings in a lot of different places and it couldn't be guaranteed
that the engine would handle any exceptions correctly.
I'm pretty sure there is something in the internals archives about
this change.
Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 2008 is 1s longer than normal.
Richard Quadling wrote: Hi. With 2008 having a leap-second, does PHP handle this? In looking at http://en.wikipedia.org/wiki/Leap_second, there have been quite a few leap seconds - 34 since Jan 1st 1972. So, if PHP isn't making any changes does this mean PHP time is 34 seconds behind UTC? Regards, PHP does what most operating systems and ignores the leap seconds. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode()
Richard Quadling wrote: 2008/12/16 Robin Burchell virot...@viroteck.net: Settings which change behaviour like that aren't really all that fun for third party/portable applications developers, e.g. forum software and the likes. magic_quotes_gpc and others are good examples of this. Going back to Rasmus' mail based on his discussion with Douglas, I think that option #1 (documenting the way it works, and documenting how to do things properly) sounds perfectly fine. Ok, I see. Add the optional param to the function and have a one-off hit to the userland codebase to fix the problem. So is this going to be 5.3 or 6.0? Would you expect json_decode() to have the param as well. Considering json_encode() COULD encode non JSON compliant data, should json_decode() also decode non JSON compliant data? I assume you always check the return value of json_decode() before you do anything with it in case of error etc. So there is no need to add a flag in my opinion to this. I have one patch that updates the parser to be more readable and add an optional depth limit to json_decode() and another patch to add flags for this. Time permitting I'll do it today. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode()
troels knak-nielsen wrote: On Tue, Dec 16, 2008 at 12:57 PM, Scott MacVicar sc...@macvicar.net wrote: For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE parameter to the options flag. So you can use json_encode($var, JSON_STRICT_ENCODE); I'm really not a fan of named constants to change the semantics of a function like that. Not to mention that it's a pita to type out, so nobody would bother. It also doesn't address the crux of the matter - That the name json_encode is slightly misleading, in that it may or may not emit json. Would it be a problem to introduce a second function (js_encode?) instead? It could work as json_encode does today, and json_encode could then be changed to raise a warning on illegal input. I realise that this means breaking existing scripts, but it's a trivial change, and if it's announced in advance, people should have time to make that sed -r '/json_encode/js_encode/g' to their code base. We already have PHP_JSON_HEX_QUOT, PHP_JSON_HEX_TAG, PHP_JSON_HEX_AMP and PHP_JSON_HEX_APOS as options for json_encode, this would just be adding another bitmask. In the future if need be we can make it the default value so it raises a warning. I have no interest in doing a js_encode functions as it opens us up to implementing a lot more functionality. The appealing this about json is that its a subset of JavaScript. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode()
Richard Quadling wrote: 2008/12/15 mike mike...@gmail.com: On Mon, Dec 15, 2008 at 9:50 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: 1. Document the fact that if you want to strictly conform to the JSON spec and be sure your json_encode output will work in various JSON parsers, you have to pass it a PHP array or object. Instead of json_encode(34) the suggestion would be json_encode(array(34)) ? Seems kind of like a lame thing to require. IMHO the language should do the right thing as far as the consumer (javascript/JSON parser) is concerned. However, Douglas is infinitely more educated than I am here. This is just my $0.02 as a PHP user. I was one of those that read the PHP dox and not the RFC/standard (http://bugs.php.net/bug.php?id=38680). I would say that having PHP correct my mistake is wrong. If I say... json_encode(34); I am saying that I expect the result to be ... var i_SomeInt = 34; And from there I would expect to be able to say ... var i_SomeOtherInt = i_SomeInt + 10; This is not going to work if PHP corrects my mistake. I'd be perfectly happy for the standard to be enforced and an E_STRICT warning to be raised. If I want to shoot myself then I have to at least take the safety off first - turning off E_STRICT that is. Essentially, I don't like computers guessing my intent. If I don't state it clearly enough then it may be that I don't know what I'm doing. GIMGO (Garbage In, Maybe Garbage Out) isn't a good way to go. json_encode is NOT javascript encode, you're already shooting yourself by miusing the function. The problem I'm talking about here is when native browser functions are used to decode the JSON. var json_resonse = ?php echo json_encode(42); ?; var myfoo = JSON.parse(json_resonse); The result here is an exception thrown by the browser, if you try and use JSON to speak to perl, python or ruby you get a similar error. The same applies for the various frameworks out there too. For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE parameter to the options flag. So you can use json_encode($var, JSON_STRICT_ENCODE); Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Removing basic types from our JSON parser
The JSON grammar explicitly says that it's not supported. 2. JSON Grammar A JSON text is a sequence of tokens. The set of tokens includes six structural characters, strings, numbers, and three literal names. A JSON text is a serialized object or array. JSON-text = object / array --- As you can see the base type should be object / array. To further test this I checked the python, ruby and perl implementations and none of them support primitive types that aren't in an array or object. I then went and looked at the various JavaScript libraries and the browser implementations and they all rejected the primitive types and threw an error when trying to decode it. Scott On 13 Dec 2008, at 18:17, Ilia Alshanetsky wrote: Lukas, Reading the spec it clearly says in the pre-amble that JSON can represent both primitive and complex data types From RFC: JSON can represent four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays). The RFC also says that when it comes to parsers anything that matches the JSON grammar is valid, it even goes further that accepting extensions on top of the grammar is fine as well RFC: A JSON parser MUST accept all texts that conform to the JSON grammar. A JSON parser MAY accept non-JSON forms or extensions. On 13-Dec-08, at 1:05 PM, Lukas Kahwe Smith wrote: On 13.12.2008, at 18:59, Ilia Alshanetsky wrote: On 12-Dec-08, at 10:50 PM, Scott MacVicar wrote: Hi All, Basic types were added to our JSON decoder to PHP 5.2.1, this allows one to use json_encode / json_decode on any of our scalar types. Omar correctly identified #38680 as not a bug but it appears that Ilia added support for this anyway violating the RFC [1]. Maybe there was a reason for this but I'm not sure why? PHP is typeless language, IMO its conductive to this design to allow encoding of basic types via json_encode, it reduces the code when communicating to/form JavaScript to avoid type detection. While it does violate the RFC IMO the convenience of the feature is definitely worth it. well seems to me like its safer to stick with RFC as the default. if at all this should be optional. JSON is a standard and this requires everybody to follow it. so using something else should be a conscious decision that is also visible during code review. regards, Lukas Kahwe Smith m...@pooteeweet.org Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Removing basic types from our JSON parser
Hi All, Basic types were added to our JSON decoder to PHP 5.2.1, this allows one to use json_encode / json_decode on any of our scalar types. Omar correctly identified #38680 as not a bug but it appears that Ilia added support for this anyway violating the RFC [1]. Maybe there was a reason for this but I'm not sure why? The problem here is that none of the other JSON parsers in any other language support this and more importantly the browsers [2] which are now adding native JSON support. Users are frequently expecting the result from a json_encode in PHP to just work with JSON.parse() on the client side. [3] I have a patch for this that implements the RFC exactly and makes secure json_encode only works with objects and arrays. This would be a change for 5.3+ and we should just document in 5.2 that what we did was a bad idea. Scott [1] - http://www.ietf.org/rfc/rfc4627.txt?number=4627 [2] - http://wiki.ecmascript.org/doku.php?id=es3.1:json_support [3] - https://developer.mozilla.org/en/Using_JSON_in_Firefox -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About dropping magic_quotes in 5.3 (was: Re: [PHP-DEV] Re: PHP 5.2.7 + magic_quotes_gpc broken)
On 8 Dec 2008, at 16:35, Philip Olson [EMAIL PROTECTED] wrote: On 8 Dec 2008, at 08:18, Hannes Magnusson wrote: On Mon, Dec 8, 2008 at 16:57, Pierre Joye [EMAIL PROTECTED] wrote: On Mon, Dec 8, 2008 at 4:47 PM, Johannes Schlüter [EMAIL PROTECTED] net wrote: When dropping magic_quotes the hosting company can do one of two things: a) not update to 5.3 so we either have to maintain 5.2 for some time or let them have problems +1 We cannot simply nuke a feature that was once upon a time sold as a security feature, and is still enabled by default, just out of the blue. Agreed, going from on by default to removed just feels odd. I'd disable it by default in 5.3 and lets start throwing a strict error if the configuration enables it. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About dropping magic_quotes in 5.3 (was: Re: [PHP-DEV] Re: PHP 5.2.7 + magic_quotes_gpc broken)
Steph Fox wrote: Hi Scott, Agreed, going from on by default to removed just feels odd. I'd disable it by default in 5.3 and lets start throwing a strict error if the configuration enables it. Why do we have E_DEPRECATED if we're not going to use it? That's the one I meant, no idea why I thought strict. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
