[PHP-DEV] php engine as shared library?
Hi! I didn't find a better place to ask... I would like to know what I'd have to do to link a small server written in C against a _shared_(!) libphp(!)... I had a look at php-cli and mod_php but both seem to link everything static which isn't what I want... I also had a look at the options of the configure script... ..but ended up subscribing here... How do I compile the whole php engine as a shared lib? It must work somehow... Why else would there be something like php-config? Please, somebody, lemme know what todo/read... Thanks, Dirk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change all XFAIL tests to FAIL
Stas Malyshev wrote: > And if we had rule of "no failing tests", we'd have no > releases for years now, because nobody is fixing those tests and bugs > behind them. I was about to suggest that maybe PHP should have a rule: "no release with failing tests". What's the point of a test that fails (or XFAILs)? Either something is broken - then it should be fixed. Or the test makes no sense - then it should be removed. Yes, I realize this is a simplistic view and things are more complicated in practice. But since, as stated, PHP is paying more attention to tests now (which is a good thing!), maybe it's time to take this one step further. bye, Dirk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: krid_
Please send me a new CVS password as I forgot mine for the account krid ([EMAIL PROTECTED]) (Don't create a new account!) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Status of PHP 4.4.3?
Hi, I'm wondering what happened to the planned release of PHP 4.4.3. The original release date (May 30th) has long passed and I haven't seen any response to Pierre's recent questions about the status of the release. From what I can see[1], no new release candidates were released either. Are there any issues preventing this release from happening? If so, I haven't seen them mentioned here. Frankly, I find that kind of worrying. PHP 4.4.3 is supposed to fix a number of security issues that were fixed in PHP 5 eight weeks ago. Many of our users are still running on PHP 4 which means that they are all vulnerable and can't do anything about it (usually because their hosting services don't want to upgrade to PHP 5 for one reason or another). PHP has been criticised a lot for its security issues in the past, but it has gotten a lot better over the recent months, thanks to all of your hard work. Please don't put that at risk by delaying what can only be described as a critical security update. If I may add: Sometimes, discussions on this list give the impression that at least some of you would rather stop developing PHP 5 and move on to PHP 6 ASAP. While I can understand how attractive this must be, please don't forget that a lot of us out there in the "real world" are still dealing with PHP 4, legacy code, and hosting services that don't even want to upgrade to PHP 5 just yet for fear of breaking their customer's applications. So unless the proverbial killer application comes along that makes everybody switch to PHP 5 by the end of the week, please take into account that it's not looking like PHP 4 will go away anytime soon, as much as you may want to leave it behind. Please note that this is not meant as a "PHP sucks" or "PHP's security sucks" comment. This is just a friendly reminder that there are people out there that are still deploying applications that will have to run on PHP 4 and a plea for not neglecting that part of your user base. Thanks for your attention. regards, Dirk Haun (Maintainer, Geeklog 1.x) [1] We're one of the projects on the PhP4zy list; in fact, PHP 4.4.3RC1 is installed on the machine I'm posting this from. -- http://www.geeklog.net/ http://geeklog.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 5.2.12RC2 Testing
Ilia Alshanetsky wrote: The second release candidate of 5.2.12 was just released for testing FWIW, I'm getting a ./configure: 91396: Syntax error: "fi" unexpected when trying to run the configure script (on Ubuntu 8.04) like so: ./configure --enable-mbstring --with-mysql=/usr/local/mysql --with-apxs2=/usr/local/apache/bin/apxs --with-xmlrpc --with-zlib --with-openssl --with-mhash --with-ldap --with-gd bye, Dirk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dangerous handling of security bugs
Am 13.07.2010 um 17:12 Uhr schrieb Ferenc Kovacs: > it would be an interesting to check how many bugs were first marked as > bogus then re-opened and fixed. I've been wondering for a while now if much of the emotional reaction to bugs being closed as "bogus" is due to that very word. I mean, the reporter obviously put some work into the bug report and the issue was apparently important enough for them to even bother opening a bug report in the first place. And then, after all this effort, the verdict is that it's "bogus". Can't really think of a good alternative right now. But if a bug was closed with a more neutral "can't reproduce", "works as designed" or something like that then maybe there wouldn't be such strong reactions? Just an observation from the side lines ... bye, Dirk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.8 Released!
Quoting Johannes Schlüter : I have the impression that very few people actually test these. When creating an RC we inform the "primary testers" as well as qa and internals list members. From there I get one or two responses in general. What happens to the reports that "make test" sends back to php.net? There are always a few tests failing (I don't think I ever installed a PHP version - final or not - that didn't have at least one or two failing tests). Where do those reports end up and is anyone actually looking at them? bye, Dirk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.8 Released!
Quoting Ferenc Kovacs : On Wed, Aug 24, 2011 at 1:59 PM, Ryan McCue wrote: Ferenc Kovacs wrote: the aggregated report summaries are available at http://qa.php.net/reports/ thanks to Oliver Doucet who make this happen. Which, incidentally, doesn't appear to be working at this point in time. it was working when I sent the mailt. it would be a weird coincidence... Works for me. However, it's still not clear (to me) what's happening to these reports once they're up there. Is anyone looking at them? bye, Dirk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CI for 5.4
Quoting Ferenc Kovacs : There is only three failing tests left on the debian slaves: For 5.3 ext/phar/tests/phar_oo_005.phpt.Phar and RecursiveDirectoryIterator 0.01 20 ext/spl/tests/bug60082.phpt.Bug #60082 (100% CPU / when using references with ArrayObject(&$ref)) FWIW, the test for Bug #60082 also seems to let the PHP CLI running, even after "make test" has finished. I've reported this here: https://bugs.php.net/bug.php?id=60225 bye, Dirk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] What's the correct way to report a regression?
I've notice, back in PHP 5.4.0 beta 2, that this test was failing: Bug #48555 (ImageFTBBox() differs from previous versions for texts with new lines) [ext/gd/tests/bug48555.phpt] So I went to https://bugs.php.net/bug.php?id=48555 and left a comment. The same test still fails in 5.4.0RC1 and also for 5.3.9RC1. Now, I have no idea if this is really a critical or important issue, but apparently a test exists for it and it fails now. So how should I go about reporting it so that somebody looks into it and decides if it's worth fixing? Since I'm not the original reporter of bug #48555, I can't edit it to update the affected PHP version. Should I have opened a new bug report instead? Would that have gotten someone's attention? bye, Dirk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RAW_POST_DATA in PHP 5.2.2RC2
I just spent about an hour debugging some XML-RPC communication only to find that the problem was not in my code but in PHP 5.2.2RC2 apparently. I'm using PEAR::XML_RPC (current version) which seems to rely on $HTTP_RAW_POST_DATA. And even though I had always_populate_raw_post_data = Off in my php.ini, that always worked fine with PHP 5.2.1. With 5.2.2RC2, though, it doesn't seem to get the raw POST data any more: ---GOT--- HTTP/1.1 200 OK Date: Sun, 29 Apr 2007 20:33:45 GMT Server: Apache/1.3.37 (Unix) PHP/5.2.2RC2 X-Powered-By: PHP/5.2.2RC2 Content-Length: 486 Connection: close Content-Type: text/xml; charset=UTF-8
[PHP-DEV] Bug? Raw POST data in PHP 5.2.2, take two
I believe this is a bug in PHP 5.2.2. I've tried to report this for PHP
5.2.2RC2 but apparently wasn't making myself clear or wasn't following
the proper procedures ...
Anyway, as I wrote before[1], "raw" POST data isn't making it through in
PHP 5.2.2 which results in XML-RPC communications to fail, at least when
using the PEAR::XML_RPC package.
Consider this little script (send.php):
--- snip ---
http://www.example.com/'; // doesn't matter here
$targetURI = $sourceURI;
$client = new XML_RPC_Client('/receive.php', $_SERVER['HTTP_HOST']);
$client->setDebug(1);
$msg = new XML_RPC_Message('pingback.ping',
array(new XML_RPC_Value($sourceURI, 'string'),
new XML_RPC_Value($targetURI, 'string')));
$response = $client->send($msg, 0, 'http');
?>
--- snip ---
This makes a simple XML-RPC call as used for Pingbacks. For the
receiving end of the communication, let's use this as receive.php:
--- snip ---
--- snip ---
Now when I call up send.php (both located in the web root of a server
running PHP 5.2.2), I get this output:
---GOT---
HTTP/1.1 200 OK
Date: Fri, 04 May 2007 20:07:58 GMT
Server: Apache/1.3.37 (Unix) PHP/5.2.2
X-Powered-By: PHP/5.2.2
Connection: close
Content-Type: text/html
Array
(
[Content-Length] => 282
[Content-Type] => text/xml
[Host] => myhost.example.com
[User-Agent] => PEAR XML_RPC
)
Notice: Undefined index: HTTP_RAW_POST_DATA in /usr/local/
apache/vhost/geeklog/public_html/receive.php on line 5
---END---
So $GLOBALS['HTTP_RAW_POST_DATA'] is not set. The PEAR::XML_RPC package
actually uses $HTTP_RAW_POST_DATA on the receiving end, but that doesn't
appear to be set either. And the always_populate_raw_post_data option in
php.ini doesn't make a difference.
Switching back to PHP 5.2.1 (same machine, same configuration) makes
everything work as expected:
---GOT---
HTTP/1.1 200 OK
Date: Fri, 04 May 2007 20:11:28 GMT
Server: Apache/1.3.37 (Unix) PHP/5.2.1
X-Powered-By: PHP/5.2.1
Connection: close
Content-Type: text/html
Array
(
[Content-Length] => 282
[Content-Type] => text/xml
[Host] => myhost.example.com
[User-Agent] => PEAR XML_RPC
)
pingback.ping
http://www.example.com/
http://www.example.com/
---END---
This is on a Linux box, but I have confirmation (thanks, Mike) of the
same thing happening on Windows.
Can anyone please
1) confirm this or tell me what I'm doing wrong and
2) tell me what else I should have done (other than posting here and
emailing Ilia, as the PHP 5 release manager), in case I ever run into
something similar again.
Thanks.
bye, Dirk
[1] <http://news.php.net/php.internals/29103>
--
http://www.geeklog.net/
http://geeklog.info/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug? Raw POST data in PHP 5.2.2, take two
Ilia Alshanetsky wrote: >Is your always_populate_raw_post_data enabled? Yes: ; Always populate the $HTTP_RAW_POST_DATA variable. always_populate_raw_post_data = On As I already said: On or Off doesn't seem to make a difference. >Also, have you tried >accessing the data from php://input ? I have to admit that I wouldn't know how to do that - never used php:// input before. It also wouldn't help with the PEAR::XML_RPC package (which we normally use on the receiving end). bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug? Raw POST data in PHP 5.2.2, take two
Ilia Alshanetsky wrote: >Also, have you tried accessing the data from php://input ? Okay, that appears to work. Using this script as the receive.php: I now get ---GOT--- HTTP/1.1 200 OK Date: Sat, 05 May 2007 08:01:49 GMT Server: Apache/1.3.37 (Unix) PHP/5.2.2 X-Powered-By: PHP/5.2.2 Connection: close Content-Type: text/html pingback.ping http://www.example.com/ http://www.example.com/ ---END--- So the raw post data is available via php://input but not via $HTTP_RAW_POST_DATA or $GLOBALS['HTTP_RAW_POST_DATA']. Also, this problem only affects PHP 5.2.2. Things are working fine with PHP 4.4.7. bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug? Raw POST data in PHP 5.2.2, take two
David Coallier wrote: > Anyone has an answer/tests to that bug* so we can stop this discussion ? :) The bug has apparently been fixed in CVS. Haven't had a chance to test it, but will do as soon as possible. Now the question is: When can we expect an update? I see people talking about what should go into PHP 5.2.3. How about "this bugfix, possibly a few others, and then release it ASAP"? As in by the end of this week (or thereabouts)? This bug affects a lot of sites that use XML-RPC communication of some form or another. Quite a lot of those nifty Web 2.0 sites, I would assume. And since people will be updating quickly due to the security issues fixed with 5.2.2, they may be in for a surprise. So can we have an update soon, please? bye, Dirk P.S. And if anyone would be willing to answer some of the questions from my original post, I'd be grateful. -- http://www.geeklog.net/ http://geeklog.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug? Raw POST data in PHP 5.2.2, take two
Ilia Alshanetsky wrote: >> The bug has apparently been fixed in CVS. Haven't had a chance to test >> it, but will do as soon as possible. > >Please let me know how it works out. I've tested php5.2-200705071830.tar.gz from snaps.php.net and the bug seems to be fixed. Thanks. >One interesting feature of the >old code is that HTTP_RAW_POST_DATA could be present even when the >INI option controlling its creation was off, this was a bug and will >not be re-instated. I had a suspicion that something wasn't right there. No problem with that change - that's what the INI option is for. >> Now the question is: When can we expect an update? > >I suspect in a week or two. Definitely sooner then later. Sounds good. >I sure hope those nifty Web 2.0 sites don't use SOAP and XML-RPC but >rather JSON or REST. Okay, but XML-RPC is used for Pingbacks, Trackbacks, and for pinging weblog directories like Technorati. That's something like the backbone of the entire "blogosphere". bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] question regarding type hinting parameters of php functions (array_slice)
Hi, i have tried a current snapshot of PHP 5.3 and have a question regarding type hinting. For example when using the function "array_slice(array $array, int $offset, int $length)" with a non-integer length parameter, what is the desired behavior? When calling "array_slice($array, 0, (float)2);" the resulting array is EMPTY. When using the right type "array_slice($array, 0, (int)2);" it works as expected. Shouldn't there be a notice/warning than just a wrong return value? In my case there is neither a warning nor does it work as expected. (perhaps i do something wrong?) Of course i can use int's, but in my opinion either a warning should be given or the function should gracefully handle the wrong typed parameter. Is this problem specific to "array_splice" or the same with other functions? It works with 5.2.x without a problem. Thank you for any feedback, Dirk PS: i posted this to php-general before and someone supposed to better post it to the iternals list -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
