Re: [PHP-DEV] Re: [VOTE] array_column() function
On 14 Jan 2013, at 12:57, Ben Ramsey wrote: > On 1/14/13 11:54 AM, Scott MacVicar wrote: >> On 14 Jan 2013, at 11:37, Ben Ramsey 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] Re: [VOTE] array_column() function
On 14 Jan 2013, at 11:37, Ben Ramsey 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] [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 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 wrote: > >> 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 wrote: >> >>> 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 wo
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:46, Alexey Shein wrote: > 2011/9/15 Pierre Joye : >> hi, >> >> On Wed, Sep 14, 2011 at 9:58 PM, Alexey Shein 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] 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 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] 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 wrote: > Hi! > > Looks like 5.3.7 shipped with broken crypt() (see bug# 55439 and > http://svn.php.net/viewvc/?view=revision&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, Александ Москалёв 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 Александр Москалёв : >> 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] 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 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 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 wrote: >>>> scottmac Tue, 19 Jul 2011 22:29:55 + >>>> >>>> Revision: http://svn.php.net/viewvc?view=revision&revision=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
[PHP-DEV] Subverting OpenSSL library function with Windows alternatives
Just noticed a commit from Pierre last week http://svn.php.net/viewvc?view=revision&revision=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
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
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
[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 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 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 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: > > $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 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ý 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 wrote: > > 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" 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 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 wrote: > >> Hi! >> >> >> I want to request a C/C++ feature that i think is good. >>> >>> MACRO >>> >> >> You know that you could write: >> > #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
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] 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] 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 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" 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': > > if(true){ > /* echo ''; */ >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 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. > if(true){ >//echo ''; >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" 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: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] 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] [PATCH] Raise warning first on "Maximum execution time exceeded"
On Mar 22, 2010, at 11:37 AM, troels knak-nielsen wrote: > On Mon, Mar 22, 2010 at 7:10 PM, Scott MacVicar wrote: >> >> Statics are bad, if its in multithreaded mode and two timeouts happen at >> once you'll get some funny behaviour. You need to store this in the thread >> local storage so the flag is per thread. >> > > Thanks. My C is severely rusty; Would it simply be a matter of > dropping the "static" modifier, or do I need to get hold of some kind > of handle and attach the flag to that? In which case, what would be > appropriate? You'll see places that have EG(...) that's Executor globals and they're per thread or static if its single threaded. So if you define your new variable wherever timeout_seconds is defined you can add it there. I don't have a checkout to hand so can't point you in the exact place. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Raise warning first on "Maximum execution time exceeded"
On Mar 22, 2010, at 10:55 AM, troels knak-nielsen wrote: > On Mon, Mar 22, 2010 at 4:55 PM, troels knak-nielsen > wrote: >> On Mon, Mar 22, 2010 at 4:41 PM, Herman Radtke >> wrote: What do you mean by "no option"? Otherwise yes, that's what it does. >>> Using sleep there is not a good practice. Since the custom error >>> handler is triggered, there is no need for the sleep call anyways. >> >> So control isn't returned to the C-code before the php error handler >> finishes. Is that it? > > Just checked, and you're right about this. I've made a new patch, > which addresses this. Again, I have no idea about whether I'm > violating code style (Should zend_timeout_softswitch be declared or > named differently?), so comments on that please? > > New patch attached - disregard the previous one. > Statics are bad, if its in multithreaded mode and two timeouts happen at once you'll get some funny behaviour. You need to store this in the thread local storage so the flag is per thread. 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" > 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 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 > 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
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: > >> > > > -- > 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] 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: > -- 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 ""? why insert "" 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:41, Mark Skilbeck wrote: Scott MacVicar wrote: On 1 Nov 2009, at 21:09, Mark Skilbeck 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] Seg fault when using active_symbol_table called from userspace function.
On 1 Nov 2009, at 21:09, Mark Skilbeck 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] shebang skipping in 5.3.0
On 4 Sep 2009, at 09:16, Joey Smith wrote: I can understand not having the 'shebang skipping' code in both the SAPI *and* the scanner, but we probably need to have it in at least ONE of them. :) Per his email[1] almost a year ago, Dmitry removed the shebang line check from sapi/cgi/cgi_main.c in changeset 264153, saying: Removed shebang line check from CGI sapi (it is checked by scanner) In http://tinyurl.com/me8528 (changeset 262275), nlopess removed the code from the scanner. Oops? What's the problem your having? The skip code is still there just in a different bit. 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 Biggar wrote: Hi Thomas, On Mon, Jul 13, 2009 at 9:15 PM, Thomas Koch 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 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 05:36, dan...@zoltak.com wrote: Quoting dan...@zoltak.com: Quoting Scott MacVicar : [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=revision&revision=268964 It could be related to the following patch to do with evaluation order of per directory configuration http://svn.php.net/viewvc?view=revision&sortby=date&revision=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] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
On 4 Aug 2009, at 04:49, dan...@zoltak.com wrote: Quoting Scott MacVicar : 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 03:14, dan...@zoltak.com wrote: Quoting Jani Taskinen : 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 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 00:08, dan...@zoltak.com wrote: Quoting Jani Taskinen : 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 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] $_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] 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] 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] 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: -- 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 MacVicar wrote: On 26 Jun 2009, at 19:59, Lukas Kahwe Smith wrote: On 26.06.2009, at 20:26, Pierre Joye wrote: On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicar 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
On 26 Jun 2009, at 19:59, Lukas Kahwe Smith wrote: On 26.06.2009, at 20:26, Pierre Joye wrote: On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicar 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
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] 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-- +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 >> 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 (
[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: > 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] 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] Like 2 Invole in Google Open source program
On 20 Apr 2009, at 19:34, Jaya Prakash 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 : >> 2009/4/2 Kalle Sommer Nielsen : >>> 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 : >> 2009/3/27 Felipe Pena : >>> 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: > 2009/3/2 Scott MacVicar : >> 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] 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] 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=Open&phpver=5.3&cmd=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] substr passing null...
Nathanael D. Noblet wrote: > Peter Walther wrote: > > it's only a bug if you always expect optional NULL parameters to be >> ignored. > > Well that's the question I'm asking. I assumed optional parameters > passed null should be ignored. If this isn't the behaviour php uses, > then I'm good, but I've used passing null to optional params all over > the place, and just recently had this one not work. If my logic / > assumptions are flawed, that's fine otherwise I can file a bug. > You're assumption is wrong then, NULL isn't treated as not passing a value. The reason it worked with substr was by pure chance. 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 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
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
[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] 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
Re: [PHP-DEV] dns_get_record for OSX
Hi Kalle, Kalle Sommer Nielsen wrote: > Hi Scott > > 2009/1/7 Scott MacVicar : >> 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
[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 (n<0) { 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 : >> 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 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 : >> On Mon, Dec 15, 2008 at 9:50 AM, Rasmus Lerdorf 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 = ; 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