Bug #52373 [Opn]: XPath returns inconsistent results
Edit report at http://bugs.php.net/bug.php?id=52373&edit=1
ID: 52373
User updated by: david at sickmiller dot com
Reported by: david at sickmiller dot com
Summary: XPath returns inconsistent results
Status: Open
Type: Bug
Package: DOM XML related
Operating System: Cent OS 5
PHP Version: 5.2.13
New Comment:
I wonder if this may be related to the libxml2 library. I am using
v2.6.26-2.1.2.8 from the CentOS distribution.
Previous Comments:
[2010-07-19 07:59:35] m dot philipp at coreto dot de
Cannot repeat with php 5.3.2.
All test runs resulted in:
"In 1 instances, found 1 match(es) for
/root[1]/fie...@attr1='val1']"
[2010-07-19 01:37:51] david at sickmiller dot com
Description:
Sometimes the DOMXpath->evaluate() function returns unreliable results.
This seems to happen when the document has at least a depth of 3 and
selectors are used at multiple levels. There may be other conditions
that trigger it; I'm not sure. The test script below is consistently
showing errors for me.
Test script:
---
';
$rawxpath = "/root[1]/fie...@attr1='val1']";
$results = array();
for ($i = 0; $i < 1; $i++) {
$xmlDocument = new DOMDocument();
$xmlDocument->loadXML($rawxml);
$xp = new DOMXPath($xmlDocument);
$xpr = $xp->evaluate($rawxpath, $xmlDocument->documentElement);
if (isset($results[(string) $xpr->length]))
$results[(string) $xpr->length]++;
else
$results[(string) $xpr->length] = 1;
}
foreach ($results as $matches => $count)
printf("In %5d instances, found $matches match(es) for
$rawxpath\n", $count);
Expected result:
In 1 instances, found 1 match(es) for /root[1]/fie...@attr1='val1']
Actual result:
--
The exact numbers seem to vary, but I get roughly this response:
In 9924 instances, found 1 match(es) for /root[1]/fie...@attr1='val1']
In76 instances, found 2 match(es) for /root[1]/fie...@attr1='val1']
--
Edit this bug report at http://bugs.php.net/bug.php?id=52373&edit=1
Req #52362 [Opn->Wfx]: give str_ireplace an option to refer the original string
Edit report at http://bugs.php.net/bug.php?id=52362&edit=1
ID: 52362
Updated by: ahar...@php.net
Reported by: emiobe at guehring dot de
Summary: give str_ireplace an option to refer the original string
-Status: Open
+Status: Wont fix
Type:Feature/Change Request
Package: *General Issues
PHP Version: 5.3.2
New Comment:
The point of having the separate str_replace and str_ireplace functions
is that they're intended to be fast replacers for times when you don't
need any special features such as regular expression matching or back
references. This would introduce special case code that would only slow
them down and duplicate functionality the preg functions provide.
Previous Comments:
[2010-07-16 14:31:32] emiobe at guehring dot de
erm, just replace expected and actual result... I have mixed it up,
sorry
[2010-07-16 14:21:28] giorgio dot liscio at email dot it
use preg_replace with /i PCRE_CASELESS identifier
bogus
[2010-07-16 14:13:21] emiobe at guehring dot de
Description:
Currently I can search case-insensitive with str_ireplace. But when I
need the original string in the replacement I have to use
preg_replace//i.
It would be nice to have the original text in a "magic variable" like $1
to avoid using the "expensive" preg-engine.
Test script:
---
currently:
print str_ireplace ("original", "original", "the ORIGINAL
text");
idea:
print str_ireplace ("original", "$1", "the ORIGINAL text");
Expected result:
the original text
Actual result:
--
the ORIGINAL text
--
Edit this bug report at http://bugs.php.net/bug.php?id=52362&edit=1
Bug #52359 [Opn->Bgs]: http_build_query seem to encode array incorrectly
Edit report at http://bugs.php.net/bug.php?id=52359&edit=1 ID: 52359 Updated by: ahar...@php.net Reported by: jj at danskscanning dot dk Summary: http_build_query seem to encode array incorrectly -Status: Open +Status: Bogus Type: Bug Package: URL related Operating System: Windows XP SP3 PHP Version: Irrelevant New Comment: http_build_query() encodes the numeric keys in the output. This is expected (and documented) behaviour. Previous Comments: [2010-07-17 23:26:03] k.schroe...@php.net Automatic comment from SVN on behalf of k.schroeder Revision: http://svn.php.net/viewvc/?view=revision&revision=301354 Log: Test for #52359 [2010-07-16 11:25:04] jj at danskscanning dot dk Description: I was working in VS.php with a CodeIgniter Project (5.2) and have not made any changes to the standard setup. Test script: --- http://bugs.php.net/bug.php?id=52359&edit=1
[PHP-BUG] Bug #52376 [NEW]: opendir() cannot open UNC paths in IIS7 using passthrough auth.
From: Operating system: win64 - W2008R2 PHP version: 5.3.2 Package: *Directory/Filesystem functions Bug Type: Bug Bug description:opendir() cannot open UNC paths in IIS7 using passthrough auth. Description: This seems to be identical to #50542 but that one was closed and I couldn't do anything to it. Basically it was marked closed because with passthrough-authentication essentially disabled by putting a username in "physical path credentials" and selecting ClearText in the "Physical Path Credentials Logon Type" both in advanced settings, this can be made to work so long as that configuration is acceptable. I too am having trouble with this and unfortunately the solution of editing physical path credentials breaks the pass through authentication to the database, ldap, and other things. This all worked on 5.3.1 with IIS6 on W2K3 but on IIS7 with W2K8R2 no joy. So I upgraded to 5.3.2, still no joy. My application is so reliant on the pass-through authentication that when I do arrange things such that opendir works (clear-text + specific physical path credentials) the system becomes a single user system! So I can confirm the workaround mentioned for #50542 works if the environment allows for it, but mine does not. Any other ideas? If I connect to IIS using the environment requirement of network type auth and pass-through authentication it does NOT work, though it really should. If I use that exact same user in the "physical path credentials" field and set "clear text" opendir suddenly works. Please don't close this as it really is a bug and apparently specific to IIS7 Test script: --- Expected result: I expect to get no errors. Actual result: -- Warning: opendir(//someserver/someshare/somefolder,//someserver/someshare/somefolder) [function.opendir]: Access is denied. (code: 5) in C:\inetpub\wwwroot\testdir.php on line 2 Warning: opendir(//someserver/someshare/somefolder) [function.opendir]: failed to open dir: No such file or directory in C:\inetpub\wwwroot\testdir.php on line 2 -- Edit bug report at http://bugs.php.net/bug.php?id=52376&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52376&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52376&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52376&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52376&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52376&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52376&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52376&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52376&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52376&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52376&r=support Expected behavior: http://bugs.php.net/fix.php?id=52376&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52376&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52376&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52376&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52376&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52376&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52376&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52376&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52376&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52376&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52376&r=mysqlcfg
Bug #52317 [Asn->Sus]: Segmentation fault when using mail() on a rhel 4.x (only 64 bit)
Edit report at http://bugs.php.net/bug.php?id=52317&edit=1 ID: 52317 Updated by: ahar...@php.net Reported by: om at wysiwyg dot de Summary: Segmentation fault when using mail() on a rhel 4.x (only 64 bit) -Status: Assigned +Status: Suspended Type: Bug Package: Reproducible crash Operating System: rhel4.8_x86_64 PHP Version: 5.2SVN-2010-07-12 (snap) Assigned To: aharvey New Comment: Gah, missing header inclusion + older version of gcc = failure, hence why this wasn't manifesting on RHEL 5 or recent Ubuntu versions. I do find the fact it's 64-bit only interesting, Fix checked into trunk. Given we're deep into the RC cycle, I'll talk to the RMs before committing to the 5.2 and 5.3 branches, although I think this is a pretty good candidate for both. Previous Comments: [2010-07-19 12:46:46] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=301392 Log: Fix for bug #52317 (Segmentation fault when using mail() on a rhel 4.x (only 64 bit)). [2010-07-15 10:32:42] om at wysiwyg dot de (gdb) bt #0 0x003fc0571360 in strlen () from /lib64/tls/libc.so.6 #1 0x003fc0542e79 in vfprintf () from /lib64/tls/libc.so.6 #2 0x003fc0548626 in fprintf () from /lib64/tls/libc.so.6 #3 0x0060b902 in php_mail (to=0x2a9557f208 "o...@wysiwyg.de", subject=0x2a9557efc0 "the subject", message=0x2a95580b28 "hello", headers=0x9557f388 , extra_cmd=0x0) at /usr/local/src/php5.2-201007131430/ext/standard/mail.c:281 #4 0x0060b6dc in zif_mail (ht=4, return_value=0x2a9557f318, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /usr/local/src/php5.2-201007131430/ext/standard/mail.c:180 #5 0x006ee2cb in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbfffd1c0) at /usr/local/src/php5.2-201007131430/Zend/zend_vm_execute.h:200 #6 0x006f3bdb in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x7fbfffd1c0) at /usr/local/src/php5.2-201007131430/Zend/zend_vm_execute.h:1740 #7 0x006eddc1 in execute (op_array=0x2a9557e130) at /usr/local/src/php5.2-201007131430/Zend/zend_vm_execute.h:92 #8 0x006c747f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/php5.2-201007131430/Zend/zend.c:1134 #9 0x00671979 in php_execute_script (primary_file=0x7fb890) at /usr/local/src/php5.2-201007131430/main/main.c:2036 #10 0x00741dfb in main (argc=2, argv=0x7fb9e8) at /usr/local/src/php5.2-201007131430/sapi/cli/php_cli.c:1165 (gdb) [2010-07-15 10:15:59] om at wysiwyg dot de sorry I forgot the testscript: seg. fault mail($to, $subject, $message, $headers); ?> [2010-07-13 18:26:07] ahar...@php.net Since I committed the offending patch, I'll look into it. If you could provide both the test script (which doesn't seem to have made it) and, if possible, a backtrace per the instructions [1], that would be most helpful. [1] http://bugs.php.net/bugs-generating-backtrace.php [2010-07-12 16:52:53] om at wysiwyg dot de Description: Since the patch for "headers_trimmed" was added in the mail.c I always get a segmentation fault when using mail(). This only affects rhel4.x 64 bit os. rhel 5.x 64 bit or rhel4.x 32 bit works fine. Using mail.c from a snapshot before 2010-04-22 in the actual snapshot source everything works fine. --- php/php-src/branches/PHP_5_2/ext/standard/mail.c2010-04-22 01:07:48 UTC (rev 298290) -> works fine +++ php/php-src/branches/PHP_5_2/ext/standard/mail.c2010-04-22 02:22:49 UTC (rev 298291) -> segmentation fault when using mail() in a php script on a rhel4.x 64 bit host Test script: --- running "make test" after building php from source. the provided test script also reports the problem. -- Edit this bug report at http://bugs.php.net/bug.php?id=52317&edit=1
Bug #52317 [Sus]: Segmentation fault when using mail() on a rhel 4.x (only 64 bit)
Edit report at http://bugs.php.net/bug.php?id=52317&edit=1 ID: 52317 Updated by: ahar...@php.net Reported by: om at wysiwyg dot de Summary: Segmentation fault when using mail() on a rhel 4.x (only 64 bit) Status: Suspended Type: Bug Package: Reproducible crash Operating System: rhel4.8_x86_64 PHP Version: 5.2SVN-2010-07-12 (snap) Assigned To: aharvey New Comment: Editing fail: ignore "I do find the fact it's 64-bit only interesting,". It's not that interesting when you think about it for two seconds. :) Previous Comments: [2010-07-19 12:46:51] ahar...@php.net Gah, missing header inclusion + older version of gcc = failure, hence why this wasn't manifesting on RHEL 5 or recent Ubuntu versions. I do find the fact it's 64-bit only interesting, Fix checked into trunk. Given we're deep into the RC cycle, I'll talk to the RMs before committing to the 5.2 and 5.3 branches, although I think this is a pretty good candidate for both. [2010-07-19 12:46:46] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=301392 Log: Fix for bug #52317 (Segmentation fault when using mail() on a rhel 4.x (only 64 bit)). [2010-07-15 10:32:42] om at wysiwyg dot de (gdb) bt #0 0x003fc0571360 in strlen () from /lib64/tls/libc.so.6 #1 0x003fc0542e79 in vfprintf () from /lib64/tls/libc.so.6 #2 0x003fc0548626 in fprintf () from /lib64/tls/libc.so.6 #3 0x0060b902 in php_mail (to=0x2a9557f208 "o...@wysiwyg.de", subject=0x2a9557efc0 "the subject", message=0x2a95580b28 "hello", headers=0x9557f388 , extra_cmd=0x0) at /usr/local/src/php5.2-201007131430/ext/standard/mail.c:281 #4 0x0060b6dc in zif_mail (ht=4, return_value=0x2a9557f318, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /usr/local/src/php5.2-201007131430/ext/standard/mail.c:180 #5 0x006ee2cb in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbfffd1c0) at /usr/local/src/php5.2-201007131430/Zend/zend_vm_execute.h:200 #6 0x006f3bdb in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x7fbfffd1c0) at /usr/local/src/php5.2-201007131430/Zend/zend_vm_execute.h:1740 #7 0x006eddc1 in execute (op_array=0x2a9557e130) at /usr/local/src/php5.2-201007131430/Zend/zend_vm_execute.h:92 #8 0x006c747f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/php5.2-201007131430/Zend/zend.c:1134 #9 0x00671979 in php_execute_script (primary_file=0x7fb890) at /usr/local/src/php5.2-201007131430/main/main.c:2036 #10 0x00741dfb in main (argc=2, argv=0x7fb9e8) at /usr/local/src/php5.2-201007131430/sapi/cli/php_cli.c:1165 (gdb) [2010-07-15 10:15:59] om at wysiwyg dot de sorry I forgot the testscript: seg. fault mail($to, $subject, $message, $headers); ?> [2010-07-13 18:26:07] ahar...@php.net Since I committed the offending patch, I'll look into it. If you could provide both the test script (which doesn't seem to have made it) and, if possible, a backtrace per the instructions [1], that would be most helpful. [1] http://bugs.php.net/bugs-generating-backtrace.php The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52317 -- Edit this bug report at http://bugs.php.net/bug.php?id=52317&edit=1
Bug #11058 [Com]: php_network_getaddresses: getaddrinfo failed
Edit report at http://bugs.php.net/bug.php?id=11058&edit=1
ID: 11058
Comment by: office at hermannseib dot com
Reported by: pat at mail dot rit dot edu
Summary: php_network_getaddresses: getaddrinfo failed
Status: Bogus
Type: Bug
Package: Network related
Operating System: OpenBSD 2.6
PHP Version: 4.0.6
New Comment:
My solution:
Check whether PHP may read /etc/resolv.conf.
First, do a
ls -la /etc/resolv.conf
and if it says something like this
-rw-r- 1 root root /etc/resolv.conf
(i.e, NOT readable to anyone but root and the members of group root,
which normally means a highly elitist bunch :-),
then issue the following command as root:
chmod a+r /etc/resolv.conf
This cured the pesky "getaddrinfo failed" for me.
Previous Comments:
[2010-06-02 15:53:43] elynets at gmail dot com
Hello,
I`ve got the same problem on my server while tried to execute some of my
scripts.
The only solution that works fine for me is to disable firewall.
When firewall is disabled I get no errors.
In the firewall settings all traffic allowed on ports 80 and 53.
[2010-05-26 23:27:26] pipra133 at yahoo dot com
I am having the same problem .. I am using XAMPP 2.5 version ... it did
work for me on the last version
I am using the youtube API to receive youtube videos ...
there is a major change in my case
Message: Unable to Connect to tcp://gdata.youtube.com:80. Error #0:
php_network_getaddresses: getaddrinfo failed: No such host is known.
the return says it tries with TCP rather then http , but my actual stack
trace says it is HTTP .
#0 C:\xampp\php\PEAR\Zend\Gdata.php(221):
Zend_Gdata_App->performHttpRequest('GET', 'http://gdata.yo...', Array,
NULL, NULL, NULL)
Does anyone have a clue what is wrong ???
[2010-03-25 06:28:07] cha0s at therealcha0s dot net
Still present in 5.3.
[2009-04-08 05:37:11] aven...@php.net
I have this problem on RHEL5 too.
My sloved is "chmod 644 /etc/hosts"
Simple,but useful for me.
[2004-09-27 19:06:52] rowaldru at gpi dot com
I am currently on 4.3.8. Has this issue been addressed and fixed in
5.0.1?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=11058
--
Edit this bug report at http://bugs.php.net/bug.php?id=11058&edit=1
[PHP-BUG] Req #52377 [NEW]: Add .user.ini support to FPM
From: Operating system: PHP version: 5.3.2 Package: FPM related Bug Type: Feature/Change Request Bug description:Add .user.ini support to FPM Description: If would be nice if the FastCGI Process Manager SAPI supported .user.ini files like the ordinary FastCGI SAPI does. Although you can specify per-pool php.ini for FPM, it really doesn't give you the same flexibility as .htaccess and .user.ini does. -- Edit bug report at http://bugs.php.net/bug.php?id=52377&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52377&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52377&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52377&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52377&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52377&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52377&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52377&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52377&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52377&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52377&r=support Expected behavior: http://bugs.php.net/fix.php?id=52377&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52377&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52377&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52377&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52377&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52377&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52377&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52377&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52377&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52377&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52377&r=mysqlcfg
Bug #52317 [Sus->Asn]: Segmentation fault when using mail() on a rhel 4.x (only 64 bit)
Edit report at http://bugs.php.net/bug.php?id=52317&edit=1 ID: 52317 Updated by: johan...@php.net Reported by: om at wysiwyg dot de Summary: Segmentation fault when using mail() on a rhel 4.x (only 64 bit) -Status: Suspended +Status: Assigned Type: Bug Package: Reproducible crash Operating System: rhel4.8_x86_64 PHP Version: 5.2SVN-2010-07-12 (snap) Assigned To: aharvey New Comment: Approved for 5.2 and 5.3. Previous Comments: [2010-07-19 12:47:40] ahar...@php.net Editing fail: ignore "I do find the fact it's 64-bit only interesting,". It's not that interesting when you think about it for two seconds. :) [2010-07-19 12:46:51] ahar...@php.net Gah, missing header inclusion + older version of gcc = failure, hence why this wasn't manifesting on RHEL 5 or recent Ubuntu versions. I do find the fact it's 64-bit only interesting, Fix checked into trunk. Given we're deep into the RC cycle, I'll talk to the RMs before committing to the 5.2 and 5.3 branches, although I think this is a pretty good candidate for both. [2010-07-19 12:46:46] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=301392 Log: Fix for bug #52317 (Segmentation fault when using mail() on a rhel 4.x (only 64 bit)). [2010-07-15 10:32:42] om at wysiwyg dot de (gdb) bt #0 0x003fc0571360 in strlen () from /lib64/tls/libc.so.6 #1 0x003fc0542e79 in vfprintf () from /lib64/tls/libc.so.6 #2 0x003fc0548626 in fprintf () from /lib64/tls/libc.so.6 #3 0x0060b902 in php_mail (to=0x2a9557f208 "o...@wysiwyg.de", subject=0x2a9557efc0 "the subject", message=0x2a95580b28 "hello", headers=0x9557f388 , extra_cmd=0x0) at /usr/local/src/php5.2-201007131430/ext/standard/mail.c:281 #4 0x0060b6dc in zif_mail (ht=4, return_value=0x2a9557f318, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /usr/local/src/php5.2-201007131430/ext/standard/mail.c:180 #5 0x006ee2cb in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbfffd1c0) at /usr/local/src/php5.2-201007131430/Zend/zend_vm_execute.h:200 #6 0x006f3bdb in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x7fbfffd1c0) at /usr/local/src/php5.2-201007131430/Zend/zend_vm_execute.h:1740 #7 0x006eddc1 in execute (op_array=0x2a9557e130) at /usr/local/src/php5.2-201007131430/Zend/zend_vm_execute.h:92 #8 0x006c747f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/php5.2-201007131430/Zend/zend.c:1134 #9 0x00671979 in php_execute_script (primary_file=0x7fb890) at /usr/local/src/php5.2-201007131430/main/main.c:2036 #10 0x00741dfb in main (argc=2, argv=0x7fb9e8) at /usr/local/src/php5.2-201007131430/sapi/cli/php_cli.c:1165 (gdb) [2010-07-15 10:15:59] om at wysiwyg dot de sorry I forgot the testscript: seg. fault mail($to, $subject, $message, $headers); ?> The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52317 -- Edit this bug report at http://bugs.php.net/bug.php?id=52317&edit=1
Bug #52317 [Asn->Csd]: Segmentation fault when using mail() on a rhel 4.x (only 64 bit)
Edit report at http://bugs.php.net/bug.php?id=52317&edit=1 ID: 52317 Updated by: ahar...@php.net Reported by: om at wysiwyg dot de Summary: Segmentation fault when using mail() on a rhel 4.x (only 64 bit) -Status: Assigned +Status: Closed Type: Bug Package: Reproducible crash Operating System: rhel4.8_x86_64 PHP Version: 5.2SVN-2010-07-12 (snap) Assigned To: aharvey Previous Comments: [2010-07-19 15:38:55] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=301396 Log: MFH: fix for bug #52317 (Segmentation fault when using mail() on a rhel 4.x (only 64 bit)). [2010-07-19 15:08:15] johan...@php.net Approved for 5.2 and 5.3. [2010-07-19 12:47:40] ahar...@php.net Editing fail: ignore "I do find the fact it's 64-bit only interesting,". It's not that interesting when you think about it for two seconds. :) [2010-07-19 12:46:51] ahar...@php.net Gah, missing header inclusion + older version of gcc = failure, hence why this wasn't manifesting on RHEL 5 or recent Ubuntu versions. I do find the fact it's 64-bit only interesting, Fix checked into trunk. Given we're deep into the RC cycle, I'll talk to the RMs before committing to the 5.2 and 5.3 branches, although I think this is a pretty good candidate for both. [2010-07-19 12:46:46] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=301392 Log: Fix for bug #52317 (Segmentation fault when using mail() on a rhel 4.x (only 64 bit)). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52317 -- Edit this bug report at http://bugs.php.net/bug.php?id=52317&edit=1
Bug #52317 [Csd]: Segmentation fault when using mail() on a rhel 4.x (only 64 bit)
Edit report at http://bugs.php.net/bug.php?id=52317&edit=1 ID: 52317 Updated by: ahar...@php.net Reported by: om at wysiwyg dot de Summary: Segmentation fault when using mail() on a rhel 4.x (only 64 bit) Status: Closed Type: Bug Package: Reproducible crash Operating System: rhel4.8_x86_64 PHP Version: 5.2SVN-2010-07-12 (snap) Assigned To: aharvey New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2010-07-19 15:38:55] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=301396 Log: MFH: fix for bug #52317 (Segmentation fault when using mail() on a rhel 4.x (only 64 bit)). [2010-07-19 15:08:15] johan...@php.net Approved for 5.2 and 5.3. [2010-07-19 12:47:40] ahar...@php.net Editing fail: ignore "I do find the fact it's 64-bit only interesting,". It's not that interesting when you think about it for two seconds. :) [2010-07-19 12:46:51] ahar...@php.net Gah, missing header inclusion + older version of gcc = failure, hence why this wasn't manifesting on RHEL 5 or recent Ubuntu versions. I do find the fact it's 64-bit only interesting, Fix checked into trunk. Given we're deep into the RC cycle, I'll talk to the RMs before committing to the 5.2 and 5.3 branches, although I think this is a pretty good candidate for both. [2010-07-19 12:46:46] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=301392 Log: Fix for bug #52317 (Segmentation fault when using mail() on a rhel 4.x (only 64 bit)). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52317 -- Edit this bug report at http://bugs.php.net/bug.php?id=52317&edit=1
[PHP-BUG] Bug #52378 [NEW]: new DateTime(time()) failed and should not
From: Operating system: PHP version: 5.3.2 Package: Date/time related Bug Type: Bug Bug description:new DateTime(time()) failed and should not Description: Creating a new DateTime object with a unix timestamp failed with error Uncaught exception 'Exception' with message 'DateTime::__construct(): Failed to parse time string (1279547855) at position 8 (5): Unexpected character' If this is expected behaviour, this should be written in documentation and DateTime::setTimestamp() should be fixed: http://www.php.net/manual/en/datetime.settimestamp.php#Notes "Passing a Unix timestamp to DateTime::__construct() is an alternative when using PHP 5.2." Test script: --- http://bugs.php.net/bug.php?id=52378&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52378&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52378&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52378&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52378&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52378&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52378&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52378&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52378&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52378&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52378&r=support Expected behavior: http://bugs.php.net/fix.php?id=52378&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52378&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52378&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52378&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52378&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52378&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52378&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52378&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52378&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52378&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52378&r=mysqlcfg
[PHP-BUG] Bug #52379 [NEW]: php.ini not loaded
From: Operating system: WinXP PHP version: 5.3.3RC3 Package: CGI related Bug Type: Bug Bug description:php.ini not loaded Description: Load the Windows php-533r3-VC9-ts.zip. Unzip the package. Rename the php.ini-development to php.ini. Run the cli command: php --ini in the unzipped directory. It will not detect the php.ini unless it is stored in C:\Windows. My path contains spaces which may cause the problems, but with PHP 5.2.x it works like expected. Expected result: It should detect the php.ini in the unzipped php directory. Works like expected with php 5.2.14r3. -- Edit bug report at http://bugs.php.net/bug.php?id=52379&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52379&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52379&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52379&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52379&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52379&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52379&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52379&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52379&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52379&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52379&r=support Expected behavior: http://bugs.php.net/fix.php?id=52379&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52379&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52379&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52379&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52379&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52379&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52379&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52379&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52379&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52379&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52379&r=mysqlcfg
Bug #52376 [Opn->Fbk]: opendir() cannot open UNC paths in IIS7 using passthrough auth.
Edit report at http://bugs.php.net/bug.php?id=52376&edit=1 ID: 52376 Updated by: paj...@php.net Reported by: ryan at kisc dot edu dot np Summary: opendir() cannot open UNC paths in IIS7 using passthrough auth. -Status: Open +Status: Feedback Type: Bug Package: *Directory/Filesystem functions Operating System: win64 - W2008R2 PHP Version: 5.3.2 -Assigned To: +Assigned To: pajoye New Comment: Can you try to follow the advice here please: http://support.microsoft.com/kb/214806 Previous Comments: [2010-07-19 12:38:30] ryan at kisc dot edu dot np Description: This seems to be identical to #50542 but that one was closed and I couldn't do anything to it. Basically it was marked closed because with passthrough-authentication essentially disabled by putting a username in "physical path credentials" and selecting ClearText in the "Physical Path Credentials Logon Type" both in advanced settings, this can be made to work so long as that configuration is acceptable. I too am having trouble with this and unfortunately the solution of editing physical path credentials breaks the pass through authentication to the database, ldap, and other things. This all worked on 5.3.1 with IIS6 on W2K3 but on IIS7 with W2K8R2 no joy. So I upgraded to 5.3.2, still no joy. My application is so reliant on the pass-through authentication that when I do arrange things such that opendir works (clear-text + specific physical path credentials) the system becomes a single user system! So I can confirm the workaround mentioned for #50542 works if the environment allows for it, but mine does not. Any other ideas? If I connect to IIS using the environment requirement of network type auth and pass-through authentication it does NOT work, though it really should. If I use that exact same user in the "physical path credentials" field and set "clear text" opendir suddenly works. Please don't close this as it really is a bug and apparently specific to IIS7 Test script: --- Expected result: I expect to get no errors. Actual result: -- Warning: opendir(//someserver/someshare/somefolder,//someserver/someshare/somefolder) [function.opendir]: Access is denied. (code: 5) in C:\inetpub\wwwroot\testdir.php on line 2 Warning: opendir(//someserver/someshare/somefolder) [function.opendir]: failed to open dir: No such file or directory in C:\inetpub\wwwroot\testdir.php on line 2 -- Edit this bug report at http://bugs.php.net/bug.php?id=52376&edit=1
Bug #52369 [Com]: trying to delete nodes while looping domnodelist do not delete them
Edit report at http://bugs.php.net/bug.php?id=52369&edit=1
ID: 52369
Comment by: giorgio dot liscio at email dot it
Reported by: giorgio dot liscio at email dot it
Summary: trying to delete nodes while looping domnodelist do
not delete them
Status: Open
Type: Bug
Package: DOM XML related
Operating System: all
PHP Version: 5.3.2
New Comment:
not a bug?
Previous Comments:
[2010-07-18 13:14:54] giorgio dot liscio at email dot it
Description:
hi, as summary says
here is the test code
';
$a = new DOMDocument(); $a->loadXML($s);
$els = $a->getElementsByTagName("abc");
// uncomment those three lines to fix
//foreach($els as $b)
// $els2[]=$b;
//$els=$els2;
foreach($els as $el)
$el->parentNode->removeChild($el);
echo "";
echo "document element () should be empty:\n";
echo $a->saveXML();
?>
uncomment lines to see the expected behavior
--
Edit this bug report at http://bugs.php.net/bug.php?id=52369&edit=1
[PHP-BUG] Req #52381 [NEW]: You're doing the wrong thing with string accessors
From:
Operating system: Linux
PHP version: 5.3.2
Package: Unknown/Other Function
Bug Type: Feature/Change Request
Bug description:You're doing the wrong thing with string accessors
Description:
I should have made more fuss about this earlier, but here it is now.
I think you are taking exactly the wrong approach to addressing single
characters in strings. I am of the very strong opinion that the direct
addressing of characters in strings have an obvious syntactic difference
from
the addressing of array elements. This means you should keep {} and
deprecate
[] for addressing characters in strings.
PHP is not C!! In C, strings are arrays, so [] is the preferred C operator
to
address single bytes (or character codes) in a string. In PHP, strings are
a
primitive type; they are not arrays. The notation $foo{0} makes it plain
that
$foo is a string, not an array and that you are accessing a byte, not an
array
element. Making this obvious through the syntax is more important than
you
might think.
Imagine $bar to be a 3x3 array of strings. In this case, what are you to
assume when you see in the middle of a script, far away from the assignment
to
$bar, when you read
$baz = $bar[$a][$b][$c];
If you have instead
$baz = $bar[$a][$b]{$c};
you know you're not doing ordinary array addressing.
These issues become important for the people who have to maintain the code.
Consider two more ways confusion can arise because strings are not arrays.
If $abc is a string,
$d = $abc[2];
works but
$abc[2] = array('boo');
fails. The elements of a string "array" do not work like true array
elements.
Indices to strings must be integers; unlike arrays, strings do not allow
associative indices. This fails:
$abc['key'] = 'def';
I believe that indicating single-byte access via [] is such a bad idea that
if
you're dead set on removing {}, I would prefer to deprecate that kind of
access
altogether in favor of substr() and friends.
--
Edit bug report at http://bugs.php.net/bug.php?id=52381&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52381&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52381&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52381&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52381&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52381&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52381&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52381&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52381&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52381&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52381&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52381&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52381&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52381&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52381&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52381&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52381&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52381&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52381&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52381&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52381&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52381&r=mysqlcfg
Bug #52376 [Fbk->Asn]: opendir() cannot open UNC paths in IIS7 using passthrough auth.
Edit report at http://bugs.php.net/bug.php?id=52376&edit=1 ID: 52376 User updated by: ryan at kisc dot edu dot np Reported by: ryan at kisc dot edu dot np Summary: opendir() cannot open UNC paths in IIS7 using passthrough auth. -Status: Feedback +Status: Assigned Type: Bug Package: *Directory/Filesystem functions Operating System: win64 - W2008R2 PHP Version: 5.3.2 Assigned To: pajoye New Comment: Well, that allows me to browse to the folder via chrome and essentially does the same thing as the workaround from #50542 but only on the one folder which could work. What it does not appear to do is give me programmatic access to the folder. The instructions in that KB are outdated as it uses adsutil.vbs and the setting is the same as the "Physical Path Credentials" from the IIS manager. This could work, in a much less than ideal way, if there is some way to run "opendir" on the virtual directory without specifying the unc path (since the UNC path itself still does not work). I could just be unaware of how, since it seems to use the system paths and not honor or even acknowledge virtual directories. I tried lots of different formats against my better judgement but none worked. I even tried using the http path reference. Still no joy. I've used PHP since 1998 but realize something could have changed at any one of the releases, however I'm not sure I see how a virtual directory could solve the ability to use opendir. Fair enough if this was just a try. I'm happy to keep trying if it can help the community. This worked fabulously in IIS6. I also confess that it appears to be Microsoft's fault. Very frustrating. I wonder if I can create a symbolic link equivalent. I've done this before in older versions of windows, but I don't think I've ever done it to a network share. In my case I may be able to just move the share to the IIS server and be done with it, but I'm willing to stick this out if it will help find a solution to this issue. Previous Comments: [2010-07-19 23:50:21] paj...@php.net Can you try to follow the advice here please: http://support.microsoft.com/kb/214806 [2010-07-19 12:38:30] ryan at kisc dot edu dot np Description: This seems to be identical to #50542 but that one was closed and I couldn't do anything to it. Basically it was marked closed because with passthrough-authentication essentially disabled by putting a username in "physical path credentials" and selecting ClearText in the "Physical Path Credentials Logon Type" both in advanced settings, this can be made to work so long as that configuration is acceptable. I too am having trouble with this and unfortunately the solution of editing physical path credentials breaks the pass through authentication to the database, ldap, and other things. This all worked on 5.3.1 with IIS6 on W2K3 but on IIS7 with W2K8R2 no joy. So I upgraded to 5.3.2, still no joy. My application is so reliant on the pass-through authentication that when I do arrange things such that opendir works (clear-text + specific physical path credentials) the system becomes a single user system! So I can confirm the workaround mentioned for #50542 works if the environment allows for it, but mine does not. Any other ideas? If I connect to IIS using the environment requirement of network type auth and pass-through authentication it does NOT work, though it really should. If I use that exact same user in the "physical path credentials" field and set "clear text" opendir suddenly works. Please don't close this as it really is a bug and apparently specific to IIS7 Test script: --- Expected result: I expect to get no errors. Actual result: -- Warning: opendir(//someserver/someshare/somefolder,//someserver/someshare/somefolder) [function.opendir]: Access is denied. (code: 5) in C:\inetpub\wwwroot\testdir.php on line 2 Warning: opendir(//someserver/someshare/somefolder) [function.opendir]: failed to open dir: No such file or directory in C:\inetpub\wwwroot\testdir.php on line 2 -- Edit this bug report at http://bugs.php.net/bug.php?id=52376&edit=1
Bug #52376 [Asn->Opn]: opendir() cannot open UNC paths in IIS7 using passthrough auth.
Edit report at http://bugs.php.net/bug.php?id=52376&edit=1 ID: 52376 User updated by: ryan at kisc dot edu dot np Reported by: ryan at kisc dot edu dot np Summary: opendir() cannot open UNC paths in IIS7 using passthrough auth. -Status: Assigned +Status: Open Type: Bug Package: *Directory/Filesystem functions Operating System: win64 - W2008R2 PHP Version: 5.3.2 Assigned To: pajoye New Comment: sorry about the line breaks, apparently this site doesn't like what Chrome does when I resize the text box. I'll be more careful in the future. Actually this site seems to hate Chrome altogether. I keep getting "incorrect username" constantly. The bug site is buggy, at least in Chrome. Previous Comments: [2010-07-20 04:04:31] ryan at kisc dot edu dot np Well, that allows me to browse to the folder via chrome and essentially does the same thing as the workaround from #50542 but only on the one folder which could work. What it does not appear to do is give me programmatic access to the folder. The instructions in that KB are outdated as it uses adsutil.vbs and the setting is the same as the "Physical Path Credentials" from the IIS manager. This could work, in a much less than ideal way, if there is some way to run "opendir" on the virtual directory without specifying the unc path (since the UNC path itself still does not work). I could just be unaware of how, since it seems to use the system paths and not honor or even acknowledge virtual directories. I tried lots of different formats against my better judgement but none worked. I even tried using the http path reference. Still no joy. I've used PHP since 1998 but realize something could have changed at any one of the releases, however I'm not sure I see how a virtual directory could solve the ability to use opendir. Fair enough if this was just a try. I'm happy to keep trying if it can help the community. This worked fabulously in IIS6. I also confess that it appears to be Microsoft's fault. Very frustrating. I wonder if I can create a symbolic link equivalent. I've done this before in older versions of windows, but I don't think I've ever done it to a network share. In my case I may be able to just move the share to the IIS server and be done with it, but I'm willing to stick this out if it will help find a solution to this issue. [2010-07-19 23:50:21] paj...@php.net Can you try to follow the advice here please: http://support.microsoft.com/kb/214806 [2010-07-19 12:38:30] ryan at kisc dot edu dot np Description: This seems to be identical to #50542 but that one was closed and I couldn't do anything to it. Basically it was marked closed because with passthrough-authentication essentially disabled by putting a username in "physical path credentials" and selecting ClearText in the "Physical Path Credentials Logon Type" both in advanced settings, this can be made to work so long as that configuration is acceptable. I too am having trouble with this and unfortunately the solution of editing physical path credentials breaks the pass through authentication to the database, ldap, and other things. This all worked on 5.3.1 with IIS6 on W2K3 but on IIS7 with W2K8R2 no joy. So I upgraded to 5.3.2, still no joy. My application is so reliant on the pass-through authentication that when I do arrange things such that opendir works (clear-text + specific physical path credentials) the system becomes a single user system! So I can confirm the workaround mentioned for #50542 works if the environment allows for it, but mine does not. Any other ideas? If I connect to IIS using the environment requirement of network type auth and pass-through authentication it does NOT work, though it really should. If I use that exact same user in the "physical path credentials" field and set "clear text" opendir suddenly works. Please don't close this as it really is a bug and apparently specific to IIS7 Test script: --- Expected result: I expect to get no errors. Actual result: -- Warning: opendir(//someserver/someshare/somefolder,//someserver/someshare/somefolder) [function.opendir]: Access is denied. (code: 5) in C:\inetpub\wwwroot\testdir.php on line 2 Warning: opendir(//someserver/someshare/somefolder) [function.opendir]: failed to open dir: No such file or directory in C:\inetpub\wwwroot\testdir.php on line 2 -- Edit this bug report at http://bugs.php.net/bug.php?id=52376&edit=1
Bug #52376 [Opn->Asn]: opendir() cannot open UNC paths in IIS7 using passthrough auth.
Edit report at http://bugs.php.net/bug.php?id=52376&edit=1 ID: 52376 Updated by: ahar...@php.net Reported by: ryan at kisc dot edu dot np Summary: opendir() cannot open UNC paths in IIS7 using passthrough auth. -Status: Open +Status: Assigned Type: Bug Package: *Directory/Filesystem functions Operating System: win64 - W2008R2 PHP Version: 5.3.2 Assigned To: pajoye New Comment: (Restoring status.) As a fellow Chrome user, I feel your pain. :) Previous Comments: [2010-07-20 04:08:58] ryan at kisc dot edu dot np sorry about the line breaks, apparently this site doesn't like what Chrome does when I resize the text box. I'll be more careful in the future. Actually this site seems to hate Chrome altogether. I keep getting "incorrect username" constantly. The bug site is buggy, at least in Chrome. [2010-07-20 04:04:31] ryan at kisc dot edu dot np Well, that allows me to browse to the folder via chrome and essentially does the same thing as the workaround from #50542 but only on the one folder which could work. What it does not appear to do is give me programmatic access to the folder. The instructions in that KB are outdated as it uses adsutil.vbs and the setting is the same as the "Physical Path Credentials" from the IIS manager. This could work, in a much less than ideal way, if there is some way to run "opendir" on the virtual directory without specifying the unc path (since the UNC path itself still does not work). I could just be unaware of how, since it seems to use the system paths and not honor or even acknowledge virtual directories. I tried lots of different formats against my better judgement but none worked. I even tried using the http path reference. Still no joy. I've used PHP since 1998 but realize something could have changed at any one of the releases, however I'm not sure I see how a virtual directory could solve the ability to use opendir. Fair enough if this was just a try. I'm happy to keep trying if it can help the community. This worked fabulously in IIS6. I also confess that it appears to be Microsoft's fault. Very frustrating. I wonder if I can create a symbolic link equivalent. I've done this before in older versions of windows, but I don't think I've ever done it to a network share. In my case I may be able to just move the share to the IIS server and be done with it, but I'm willing to stick this out if it will help find a solution to this issue. [2010-07-19 23:50:21] paj...@php.net Can you try to follow the advice here please: http://support.microsoft.com/kb/214806 [2010-07-19 12:38:30] ryan at kisc dot edu dot np Description: This seems to be identical to #50542 but that one was closed and I couldn't do anything to it. Basically it was marked closed because with passthrough-authentication essentially disabled by putting a username in "physical path credentials" and selecting ClearText in the "Physical Path Credentials Logon Type" both in advanced settings, this can be made to work so long as that configuration is acceptable. I too am having trouble with this and unfortunately the solution of editing physical path credentials breaks the pass through authentication to the database, ldap, and other things. This all worked on 5.3.1 with IIS6 on W2K3 but on IIS7 with W2K8R2 no joy. So I upgraded to 5.3.2, still no joy. My application is so reliant on the pass-through authentication that when I do arrange things such that opendir works (clear-text + specific physical path credentials) the system becomes a single user system! So I can confirm the workaround mentioned for #50542 works if the environment allows for it, but mine does not. Any other ideas? If I connect to IIS using the environment requirement of network type auth and pass-through authentication it does NOT work, though it really should. If I use that exact same user in the "physical path credentials" field and set "clear text" opendir suddenly works. Please don't close this as it really is a bug and apparently specific to IIS7 Test script: --- Expected result: I expect to get no errors. Actual result: -- Warning: opendir(//someserver/someshare/somefolder,//someserver/someshare/somefolder) [function.opendir]: Access is denied. (code: 5) in C:\inetpub\wwwroot\testdir.php on line 2 Warning: opendir(//someserver/someshare/somefolder) [function.opendir]: failed to open dir: No such file or directory in C:\inetpub\wwwroot\testdir.php on line 2 -
Bug #51527 [Com]: is_callable() returning true for non-static callbacks
Edit report at http://bugs.php.net/bug.php?id=51527&edit=1
ID: 51527
Comment by: hnzksq at gmail dot com
Reported by: weierophin...@php.net
Summary: is_callable() returning true for non-static callbacks
Status: Open
Type: Bug
Package: Class/Object related
Operating System: Linux
PHP Version: 5.3.2
New Comment:
ææµè¯å¯ä»¥ç¨çã
Previous Comments:
[2010-05-07 16:39:56] crrodriguez at opensuse dot org
philduby at phriendly dot net : what you mention seems to be another
bug/misfeature.
[2010-05-05 07:03:50] philduby at phriendly dot net
Another variation that actually (unexpectedly) works:
Calling is_callable and call_user_func from inside an instance
(non-static) method using any of: 'self::otherInstanceMethod',
array('self','otherInstanceMethod'), array(self,'otherInstanceMethod')
succeed. It appears that (the context for) '$this' is carried over from
the original method, even though the calls are being done statically.
Calling self::otherInstanceMethod() directly also succeeds. It appears
that methods called from an instance method 'inherit' the context for
$this. A bit unexpected, but *reasonable*.
Win XP SP3
PHP 5.3.1 (xampp)
[2010-04-12 11:50:33] paj...@php.net
I don't like the optional flag idea. You can disable strictness using
error_reporting already.
However I would like to see this change in trunk, can you come up with a
RFC pls?
[2010-04-10 20:19:45] weierophin...@php.net
@johannes Perhaps an optional "strict" flag to is_callable() would
address this?
That would keep BC, while allowing for better checking for >= PHP-5
apps. Usage
would be:
$callback = array('Foo', 'bar');
if (is_callable($callback, true)) {
// Passed strict check
} else {
// failed strict check
}
Thoughts?
[2010-04-10 17:55:25] johan...@php.net
The method can always be called statically. The access to $this might be
forbidden but the method itself can be called. is_callable() doesn't
mean it will execute properly. (the $this error is basically the same as
a call to an undefined funciton in there or such)
To change this the only way would be to forbid calling non-static
methods statically. Maybe this can be done nowadays (we needed the
behavior for PHP 4 compatibility) but that's no bug but requires a RFC
and discussion on internals as this might break quite a few applications
(many PEAR-based things, many legacy applications not fully "converted"
to PHP 5 )
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=51527
--
Edit this bug report at http://bugs.php.net/bug.php?id=51527&edit=1
Req #52381 [Opn->Bgs]: You're doing the wrong thing with string accessors
Edit report at http://bugs.php.net/bug.php?id=52381&edit=1
ID: 52381
Updated by: ahar...@php.net
Reported by: mbt at gator dot net
Summary: You're doing the wrong thing with string accessors
-Status: Open
+Status: Bogus
Type: Feature/Change Request
Package: Unknown/Other Function
Operating System: Linux
PHP Version: 5.3.2
New Comment:
This decision dates back the best part of five years at this stage to
the developer meeting in November 2005. [0] It's come up a couple of
times on the Internals mailing list since then -- both immediately
after the developer meeting [1], and then to confirm the 5.3 migration
document was correct. [2]
To be blunt, the horse has already bolted on this. {} is deprecated,
and [] is the supported way to access strings by offset both now and
in the future.
[0] http://www.php.net/~derick/meeting-notes.html#cleanup-for-vs
[1] http://www.mail-archive.com/intern...@lists.php.net/msg18638.html
[2] http://www.mail-archive.com/intern...@lists.php.net/msg42883.html
Previous Comments:
[2010-07-20 01:53:12] mbt at gator dot net
Description:
I should have made more fuss about this earlier, but here it is now.
I think you are taking exactly the wrong approach to addressing single
characters in strings. I am of the very strong opinion that the direct
addressing of characters in strings have an obvious syntactic difference
from
the addressing of array elements. This means you should keep {} and
deprecate
[] for addressing characters in strings.
PHP is not C!! In C, strings are arrays, so [] is the preferred C
operator to
address single bytes (or character codes) in a string. In PHP, strings
are a
primitive type; they are not arrays. The notation $foo{0} makes it
plain that
$foo is a string, not an array and that you are accessing a byte, not an
array
element. Making this obvious through the syntax is more important than
you
might think.
Imagine $bar to be a 3x3 array of strings. In this case, what are you
to
assume when you see in the middle of a script, far away from the
assignment to
$bar, when you read
$baz = $bar[$a][$b][$c];
If you have instead
$baz = $bar[$a][$b]{$c};
you know you're not doing ordinary array addressing.
These issues become important for the people who have to maintain the
code.
Consider two more ways confusion can arise because strings are not
arrays.
If $abc is a string,
$d = $abc[2];
works but
$abc[2] = array('boo');
fails. The elements of a string "array" do not work like true array
elements.
Indices to strings must be integers; unlike arrays, strings do not
allow
associative indices. This fails:
$abc['key'] = 'def';
I believe that indicating single-byte access via [] is such a bad idea
that if
you're dead set on removing {}, I would prefer to deprecate that kind of
access
altogether in favor of substr() and friends.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52381&edit=1
Doc->Bug #52380 [Opn->Asn]: Typo in lcfirst comment docs
Edit report at http://bugs.php.net/bug.php?id=52380&edit=1
ID: 52380
Updated by: ahar...@php.net
Reported by: toddw at activestate dot com
Summary: Typo in lcfirst comment docs
-Status: Open
+Status: Assigned
-Type:Documentation Problem
+Type:Bug
-Package: Documentation problem
+Package: Strings related
PHP Version: trunk-SVN-2010-07-19 (SVN)
-Assigned To:
+Assigned To: aharvey
Previous Comments:
[2010-07-19 21:46:24] toddw at activestate dot com
Description:
The lcfirst function has the wrong proto comment name - being "ucfirst"
instead of "lcfirst", see snippet from "ext/standard/string.c" below:
/* {{{ proto string ucfirst(string str)
Make a string's first character lowercase */
PHP_FUNCTION(lcfirst)
{
--
Edit this bug report at http://bugs.php.net/bug.php?id=52380&edit=1
Bug #52380 [Asn->Sus]: Typo in lcfirst comment docs
Edit report at http://bugs.php.net/bug.php?id=52380&edit=1
ID: 52380
Updated by: ahar...@php.net
Reported by: toddw at activestate dot com
Summary: Typo in lcfirst comment docs
-Status: Assigned
+Status: Suspended
Type:Bug
Package: Strings related
PHP Version: trunk-SVN-2010-07-19 (SVN)
Assigned To: aharvey
New Comment:
Fixed on trunk. Will MFH once the 5.2.14 and 5.3.3 releases are out.
Previous Comments:
[2010-07-20 06:26:59] ahar...@php.net
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&revision=301412
Log: Fix bug #52380 (Typo in lcfirst comment docs) by updating the
commented
prototype for lcfirst() to actually read lcfirst().
[2010-07-19 21:46:24] toddw at activestate dot com
Description:
The lcfirst function has the wrong proto comment name - being "ucfirst"
instead of "lcfirst", see snippet from "ext/standard/string.c" below:
/* {{{ proto string ucfirst(string str)
Make a string's first character lowercase */
PHP_FUNCTION(lcfirst)
{
--
Edit this bug report at http://bugs.php.net/bug.php?id=52380&edit=1
