#39388 [NEW]: provide --with-libzip-dir configure option to allow usage of system's libzip

[judas dot iscariote at gmail dot com]

From: judas dot iscariote at gmail dot com
Operating system: Linux
PHP version:  5CVS-2006-11-05 (CVS)
PHP Bug Type: Zip Related
Bug description:  provide --with-libzip-dir configure option to allow usage of 
system's libzip

Description:

Currently there is no  --with-libzip-dir to easily allow distributions to
use independantly packaged system libraries.

Reproduce code:
---
./configure --help | grep zip

Expected result:

--enable-zipInclude Zip read/write support.
--with-zlib-dir=DIR   zip: Set the path to libz install prefix.
--with-libzip=DIR zip : path to libzip sources if not using the
bundled library.

Actual result:
--
--enable-zipInclude Zip read/write support.
--with-zlib-dir=DIR   zip: Set the path to libz install prefix.

-- 
Edit bug report at http://bugs.php.net/?id=39388&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39388&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39388&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39388&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39388&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39388&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39388&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39388&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39388&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39388&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39388&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39388&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39388&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39388&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39388&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39388&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39388&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39388&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39388&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39388&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39388&r=mysqlcfg

#39362 [Asn]: imap_open retries 3 times on failed auth

[askalski at gmail dot com]

 ID:   39362
 User updated by:  askalski at gmail dot com
 Reported By:  askalski at gmail dot com
 Status:   Assigned
 Bug Type: IMAP related
 Operating System: Linux
 PHP Version:  5CVS-2006-11-03 (snap)
 Assigned To:  iliaa
 New Comment:

Is there really any point in retrying with the same failed credentials?
 The only reasonable setting for MAXLOGINTRIALS in this case is 1. 
(There is no benefit in setting it any higher in PHP, so it wouldn't
make sense to add the ability to control it.)


Previous Comments:


[2006-11-04 19:11:31] [EMAIL PROTECTED]

Actually this is more of a feature request to add the ability 
to control the number of retries, something the current API 
does not allow.



[2006-11-03 20:48:44] askalski at gmail dot com

I'm sorry if I did not make this clear enough in the original bug
report.

This is very much a bug in PHP.  While you're correct in saying
c-client controls the number of retries it makes, it's up to PHP to
change MAXLOGINTRIALS from its default of 3 to 1.

There is no way to work around this from a PHP script, because the
mail_parameters() function is not exposed through the PHP imap module. 
The only way is for PHP to make a mail_parameters() call in
ext/imap/php_imap.c during module initialization.



[2006-11-03 20:03:22] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

PHP does not control the number of retries performed, that is 
something the imap (c-client) library controls.



[2006-11-03 15:47:18] askalski at gmail dot com

Description:

imap_open will retry 3 times on bad credentials.  Some IMAP or POP
servers delay on successive bad logins, making a failed imap_open take
very long.  Worse, some servers will lock the user out because of
repeated failed login attempts.

Somewhere during module initialization, this call needs to be made:

mail_parameters(NIL, SET_MAXLOGINTRIALS, (void *) 1);


Reproduce code:
---
imap_open("{mailserver/pop}", "user", "badpass");


Expected result:

It should try logging in only once.


Actual result:
--
It tries logging in three times (watch with a packet sniffer or
strace).

write(0, "AUTH LOGIN\r\n", 12)  = 12
...
read(0, "-ERR Bad authentication\r\n", 8192) = 25
write(0, "AUTH LOGIN\r\n", 12)  = 12
...
read(0, "-ERR Bad authentication\r\n", 8192) = 25
write(0, "AUTH LOGIN\r\n", 12)  = 12
...
read(0, "-ERR Bad authentication\r\n", 8192) = 25
write(0, "QUIT\r\n", 6) = 6
read(0, "+OK Sayonara\r\n", 8192)   = 14
write(1, "\nWarning: imap_open(): Couldn\'t "..., 104) = 104






-- 
Edit this bug report at http://bugs.php.net/?id=39362&edit=1

#39295 [Opn]: openssl_csr_sign and options

[bassijunior at yahoo dot com dot br]

 ID:   39295
 User updated by:  bassijunior at yahoo dot com dot br
 Reported By:  bassijunior at yahoo dot com dot br
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Windows XP
 PHP Version:  5.1.6
 Assigned To:  pajoye
 New Comment:

Hi,

I can add fields of DN(distinguished name)using the openssl_csr_new
function. $csr = openssl_csr_new($dn, $privkey, $configarg);
I did a test. I placed a subjectAltName in $dn the variable and the
openssl_csr_new added a subjectAltName like a distinguished name, but
subjectAltName is a extension, not a DN.
$dn = array(
   "countryName" => "$nacionalidade",
   "stateOrProvinceName" => "$estado",
   "localityName" => "$cidade",
   "commonName" => "$commomName",
   "emailAddress" => "$email",
   "subjectAltName" => "123456789",

What is happening? 

Here a certificate:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1162687748 (0x454d3504)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=BR, ST=RJ, L=Rio de Janeiro, O=Home, OU=quarto,
CN=Junior/[EMAIL PROTECTED]
Validity
Not Before: Nov  5 00:49:08 2006 GMT
Not After : Nov  5 00:49:08 2007 GMT
Subject: C=BR, ST=RJ, L=Rio, CN=Jos\xE9 Alberto
Bassi/[EMAIL PROTECTED]/subjectAltName=123456789
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:ea:49:5c:e7:5b:59:77:e2:af:1e:1b:b5:6a:08:
d2:2b:2c:97:c6:01:9f:2f:44:20:4a:3a:09:47:54:
bb:09:af:92:4a:fc:e7:96:6d:8b:06:75:3e:3d:c7:
50:60:92:9f:47:26:86:d2:68:3b:1b:26:77:f3:9c:
26:fb:59:7e:35:d7:14:8d:86:32:65:36:89:94:20:
c6:28:3f:2c:b4:0a:74:8c:ee:14:0c:e5:5a:81:3a:
06:4f:2d:41:c7:c9:2e:b1:30:ef:89:fd:e3:5f:d0:
37:86:35:2f:67:bd:be:81:cd:c1:93:a9:a1:4a:df:
b4:08:1f:a0:8d:f7:fc:8c:fd
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: 
CA:FALSE
X509v3 Key Usage: 
Digital Signature, Non Repudiation, Key Encipherment
Signature Algorithm: sha1WithRSAEncryption
52:82:a4:2f:57:36:43:9a:dd:22:65:73:f8:7c:88:52:18:fc:
c9:3e:54:50:f1:60:ec:07:4c:a4:3b:97:45:3e:ac:ad:db:37:
45:71:a1:67:cd:19:ad:e5:ee:21:26:e1:b3:70:18:66:af:b6:
06:ba:f4:64:95:6c:88:61:93:fc:18:86:7d:28:13:64:ee:a2:
a6:ad:32:7f:6a:ce:ec:c5:27:80:17:38:c6:2a:4a:ff:9b:77:
d9:45:a8:73:ef:5f:07:b9:de:ba:81:bd:c9:04:76:0d:36:03:
43:23:d0:f9:1f:69:fa:05:6f:4c:4c:10:e1:48:88:19:94:ca:
8d:cd
-BEGIN CERTIFICATE-
MIICmTCCAgKgAwIBAgIERU01BDANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMC
QlIxCzAJBgNVBAgTAlJKMRcwFQYDVQQHEw5SaW8gZGUgSmFuZWlybzENMAsGA1UE
ChMESG9tZTEPMA0GA1UECxMGcXVhcnRvMQ8wDQYDVQQDEwZKdW5pb3IxHDAaBgkq
hkiG9w0BCQEWDWJiQG9waWl3ZS5jb20wHhcNMDYxMTA1MDA0OTA4WhcNMDcxMTA1
MDA0OTA4WjCBgjELMAkGA1UEBhMCQlIxCzAJBgNVBAgTAlJKMQwwCgYDVQQHEwNS
aW8xGzAZBgNVBAMUEkpvc+kgQWxiZXJ0byBCYXNzaTEnMCUGCSqGSIb3DQEJARYY
YmFzc2lqdW5pb3JAeWFob28uY29tLmJyMRIwEAYDVR0REwkxMjM0NTY3ODkwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOpJXOdbWXfirx4btWoI0issl8YBny9E
IEo6CUdUuwmvkkr855ZtiwZ1Pj3HUGCSn0cmhtJoOxsmd/OcJvtZfjXXFI2GMmU2
iZQgxig/LLQKdIzuFAzlWoE6Bk8tQcfJLrEw74n941/QN4Y1L2e9voHNwZOpoUrf
tAgfoI33/Iz9AgMBAAGjGjAYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMA0GCSqG
SIb3DQEBBQUAA4GBAFKCpC9XNkOa3SJlc/h8iFIY/Mk+VFDxYOwHTKQ7l0U+rK3b
N0VxoWfNGa3l7iEm4bNwGGavtga69GSVbIhhk/wYhn0oE2TuoqatMn9qzuzFJ4AX
OMYqSv+bd9lFqHPvXwe53rqBvckEdg02A0Mj0PkfafoFb0xMEOFIiBmUyo3N
-END CERTIFICATE-


Thanks!


Previous Comments:


[2006-10-31 01:47:10] bassijunior at yahoo dot com dot br

I will get the certificate request from a Data Base(Mysql).

After that( in other file), I have to sign this request. But, I want to
add some extensions in the certificate, in the moment of signature. To
sign the request, I use: $usercert_2 = openssl_csr_sign($req_dados,
$cert_dados, $pkeyid, 365, $config, time());

Where $config is: $config = array(
   'digest_alg' => 'sha1',
   "config" => "$pwd\\openssl.cnf");

Is there some way to put some extensions in the variable $config?


Thanks!



[2006-10-30 16:30:04] [EMAIL PROTECTED]

Do you want to create the certificate and sign at the same time?

If not, can you explain what you want with some kind of pseudo code?



[2006-10-30 00:16:03] bassijunior at yahoo dot com dot br

OK.
I know this function.
But this function is used to create a request.
I want to add extension in the moment of signature.
Thanks

--

#39387 [NEW]: preg_match/replace segfaults on certain user data.

[php at vicaya dot com]

From: php at vicaya dot com
Operating system: Linux/amd64
PHP version:  5.2.0
PHP Bug Type: PCRE related
Bug description:  preg_match/replace segfaults on certain user data.

Description:

Both PHP 5.2.0 (pcre 6.7) and 5.1.6 (pcre 6.6) have this problem:

A working pattern segfaults on certain user data. Could be stack overflow
in pcre_exec/match.

This patterns is almost straight from the documentation:
/\{(?:(?>[^{}]+)|(?R))+\}/Us

Basically to match nested {} (instead of parentheses)

I found a simple workaround to the particular problem I have, but the code
should not segfault.

Note if you change the 12000 in the code to anything less than 8158, it
will produce the correct result.

Reproduce code:
---
[^{}]+)|(?R))+}/Us',
'{open'. str_repeat('.', 12000) .'{open}'), "\n"?>


Expected result:

1

Actual result:
--
Segmentation fault


-- 
Edit bug report at http://bugs.php.net/?id=39387&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39387&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39387&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39387&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39387&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39387&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39387&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39387&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39387&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39387&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39387&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39387&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39387&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39387&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39387&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39387&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39387&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39387&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39387&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39387&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39387&r=mysqlcfg

#31323 [Com]: session file permissions differ randomly

[bclaydon at volved dot com]

 ID:   31323
 Comment by:   bclaydon at volved dot com
 Reported By:  julien dot mathieu at gmail dot com
 Status:   No Feedback
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  5.1.2, 4.3.9
 New Comment:

To provide further details, I am also using Debian (Sarge) with the
latest 4.3.10-16 PHP4 package.

My /var/liv/php4 looks exactly as 'pieter at q-go dot com' mentioned:

drwx-wx-wt   2 root root 4.0K 2006-11-04 18:58 ./
drwxr-xr-x  35 root root 4.0K 2006-09-08 19:11 ../
-rw---   1 www-data www-data   77 2006-11-04 18:58
sess_7b8da94a2febce75775d9082cd20d58d
-rw---   1 www-data www-data  116 2006-11-04 19:05
sess_856401c969cc1d4e68b6ffd75457c743
-rw---   1 www-data www-data  116 2006-11-04 18:58
sess_b5419618a3586b7e3b940a0eaf137fb9
-rw---   1 www-data www-data  116 2006-11-04 19:09
sess_f7d957b726ff923b4b1f6178f8db489f


I am seeing this issue fairly frequently during usage of CakePHP
framework which has fairly detailed usage of session functions.

I hope this is resolved at some point, especially if it is still open
as of 5.2.0


Previous Comments:


[2006-05-22 09:20:29] pieter at q-go dot com

We have similar problems on Debian with PHP 5.1.2 and 5.1.4.

Sessions are all created with correct permissions, but we get the same
permission denied error in 5% of the cases.

drwx-wx-wt   2 root root 4096 May 22 11:03 .
drwxr-xr-x  27 root root 4096 May 18 13:44 ..
-rw---   1 www-data www-data0 May 22 11:03
sess_11f06ca5b4701f4be8be30b275e4e51e
-rw---   1 www-data www-data 1569 May 22 11:00
sess_1856e3c4630f074a1b0490c4792c3e53
-rw---   1 www-data www-data0 May 22 10:21
sess_d110fb48e440d1ec4ac610243e897c69
-rw---   1 www-data www-data 1717 May 22 11:05
sess_f9668179e8a92714f4d9553504bdcd93

Changing the default Debian permissions on /var/lib/php5 from
drwx-wx-wt to drwxrwxrwt seems to help.

I am putting this here because if the two cases are related, the
problem might be more general.



[2006-03-28 13:15:10] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2006-03-21 19:02:31] jd at godaddy dot com

I should note that after we cleaned all of the sess_* files in /tmp,
the problem seems to have gone away (at least for the moment).  Why are
future PHP session file permissions being corrupted by preexisting
session files?  Is there possibly a buffer overflow possible in the
session files, where perhaps a corrupted session file can clobber these
pages?



[2006-03-21 17:35:39] jd at godaddy dot com

We're seeing this with PHP 4.4.1 and Zend Platform v2.1.0 when using
phpMyAdmin.

Check out these permissions

-rwxr-xr-x1 nobody   nobody  15187 Mar 16 12:06
sess_0834d5863159f74b560ee4c64fab1eb5
-rwxrwxrwx1 nobody   nobody  0 Mar 21 09:29
sess_243458755660a3b6be9cd416c67bb7e7
-rwxrwxrwx1 nobody   nobody  15186 Mar 15 12:20
sess_435fad9a208051008e0efa69bd1d6fc7
-rwxrwxrwx1 root root0 Mar 21 09:25
sess_47957086e32d77933e6fd8a1dc63e1f7
-rwx--x--T1 nobody   nobody  15187 Mar 15 12:54
sess_7b9a5a1840f81a13e86c0ae8ced7ff7a
-rwx--x--T1 nobody   nobody  15187 Mar 15 12:44
sess_9bedbfafd824c4a3495e7e36070daaca
-rwxr-xr-x1 nobody   nobody  15191 Mar 13 16:55
sess_b01db0867b79aa251c20356e519cac8b
-rwx--x--T1 nobody   nobody  15187 Mar 15 15:06
sess_ec5699d9df2be07f8c06c4676230c3de
-rwx--x--T1 nobody   nobody  15191 Mar 15 11:47
sess_fb0e71df00e24b1b6d22b771fb4c7281



[2006-02-07 11:15:11] julien dot mathieu at gmail dot com

I work now with the 5.1.2 version. The problem still occurs.



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/31323

-- 
Edit this bug report at http://bugs.php.net/?id=31323&edit=1

#39383 [Bgs]: PHP erroneously converts keys to integer

[lamotkin at softhome dot net]

 ID:   39383
 User updated by:  lamotkin at softhome dot net
 Reported By:  lamotkin at softhome dot net
 Status:   Bogus
 Bug Type: Arrays related
 Operating System: Windows 98
 PHP Version:  5.2.0
 New Comment:

Oops, I realized a nonsense in my logic,
the 'in_array' in examples above search
for the values, not keys, and they probably
will work right.
I corrected my real script (which implies
a bit more complicated code), and the
described is not an issue for me now ...

Sorry, Derick, for wasting your precious
time.
Please delete this "bug"
from the database.


Previous Comments:


[2006-11-04 21:45:40] [EMAIL PROTECTED]

Maybe, but we can't just start breaking things for people so we ain't
changing this.



[2006-11-04 21:21:09] lamotkin at softhome dot net

Well, you are right, Derick, the doc covered the issue.
But I believe this is a software design error,
because neither

in_array($some_var, $Test, true)
nor
in_array($some_var, $Test, false)

produces no correct results.
But if array keys would be of the type specified
on definition, the

in_array($some_var, $Test, true)

work right.



[2006-11-04 20:38:01] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

.



[2006-11-04 20:33:55] lamotkin at softhome dot net

Description:

PHP erroneously converts keys to integer if possible,
but my script is type-sensitive with that code.


Reproduce code:
---
$Test =
array(  "" => "No set",
"1" => "Yes",
"0" => "No");
var_dump($Test);
echo "";
$Test =
array(  "" => "No set",
1 => "Yes",
0 => "No");
var_dump($Test);
echo "";


Expected result:

'var_dump's must NOT be the same


Actual result:
--
'var_dump's ARE the same






-- 
Edit this bug report at http://bugs.php.net/?id=39383&edit=1

#39383 [Opn->Bgs]: PHP erroneously converts keys to integer

[derick]

 ID:   39383
 Updated by:   [EMAIL PROTECTED]
 Reported By:  lamotkin at softhome dot net
-Status:   Open
+Status:   Bogus
 Bug Type: Arrays related
 Operating System: Windows 98
 PHP Version:  5.2.0
 New Comment:

Maybe, but we can't just start breaking things for people so we ain't
changing this.


Previous Comments:


[2006-11-04 21:21:09] lamotkin at softhome dot net

Well, you are right, Derick, the doc covered the issue.
But I believe this is a software design error,
because neither

in_array($some_var, $Test, true)
nor
in_array($some_var, $Test, false)

produces no correct results.
But if array keys would be of the type specified
on definition, the

in_array($some_var, $Test, true)

work right.



[2006-11-04 20:38:01] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

.



[2006-11-04 20:33:55] lamotkin at softhome dot net

Description:

PHP erroneously converts keys to integer if possible,
but my script is type-sensitive with that code.


Reproduce code:
---
$Test =
array(  "" => "No set",
"1" => "Yes",
"0" => "No");
var_dump($Test);
echo "";
$Test =
array(  "" => "No set",
1 => "Yes",
0 => "No");
var_dump($Test);
echo "";


Expected result:

'var_dump's must NOT be the same


Actual result:
--
'var_dump's ARE the same






-- 
Edit this bug report at http://bugs.php.net/?id=39383&edit=1

#39365 [Opn->Bgs]: getElementsByTagNameNS() does not return elements in a default namespace

[rrichards]

 ID:   39365
 Updated by:   [EMAIL PROTECTED]
 Reported By:  z_rules55 at hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: DOM XML related
 Operating System: WinXP Professional
 PHP Version:  5.2.0
 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

You are mixing level 1 and level 2 functionality. Specs also indicate
that doing this will lead to unexpected behavior. Must use
createElementNS().


Previous Comments:


[2006-11-04 14:26:26] z_rules55 at hotmail dot com

Per the XML spec, setting the xmlns attribute on an element but with no
prefix (like I did with $root) sets a default namespace for that element
and its descendants. $default_ns_element and $explicit_ns_element,
therefore, do not need the xmlns attribute to be in 'my_namespace'
because they inherit the namespace from $root by default.



[2006-11-04 08:03:04] [EMAIL PROTECTED]

$xml->createElement('element', 'default_ns_element')

That's not in the default namespace, that's in no namespace at 
all this way.

Can't work this way



[2006-11-03 21:28:54] z_rules55 at hotmail dot com

Additional note: getElementsByTagName('element') does, in fact, find
both nodes.



[2006-11-03 21:12:54] z_rules55 at hotmail dot com

Description:

Calling getElementsByTagNameNS() on a DOMDocument or a DOMElement does
not return elements that are under a default namespace. The example
below finds $explicit_ns_element, but not $default_ns_element.

Reproduce code:
---
appendChild($xml->createElementNS($namespace, 'root'));
$default_ns_element = $root->appendChild($xml->createElement('element',
'default_ns_element'));
$explicit_ns_element =
$root->appendChild($xml->createElementNS($namespace, 'element',
'explicit_ns_element'));
foreach($xml->getElementsByTagNameNS($namespace, 'element') as $el) {
echo $el->nodeValue."\n";
}
echo "\n";
foreach($root->getElementsByTagNameNS($namespace, 'element') as $el) {
echo $el->nodeValue."\n";
}
?>

Expected result:

default_ns_element
explicit_ns_element

default_ns_element
explicit_ns_element

Actual result:
--
explicit_ns_element

explicit_ns_element





-- 
Edit this bug report at http://bugs.php.net/?id=39365&edit=1

#39382 [Opn->Bgs]: "Undeclared entity error" with latin1 entities

[phpbugs at thequod dot de]

 ID:   39382
 User updated by:  phpbugs at thequod dot de
-Summary:  "Undeclared entity error"
 Reported By:  phpbugs at thequod dot de
-Status:   Open
+Status:   Bogus
 Bug Type: XML related
 Operating System: Ubuntu Linux
 PHP Version:  5CVS-2006-11-04 (CVS)
 New Comment:

I'm closing it myself.
http://bugs.php.net/bug.php?id=15092 explains why it does 
not work.

Would be interested in why it works with PHP4 though..


Previous Comments:


[2006-11-04 20:31:15] phpbugs at thequod dot de

Description:

Using a regular entity like "®" throws a "Undeclared 
entity warning" error with xml_parse().

If this is bogus, please give a hint about what I'm doing 
wrong.
Is this maybe a libxml problem?

btw: it also fails with other DOCTYPEs or with a full 
html-head-body construct.

Reproduce code:
---

http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
®';

$parser = xml_parser_create();
if (!xml_parse($parser, $xml))
{
echo xml_error_string(xml_get_error_code($parser)) . "\n";
}
xml_parser_free($parser);
?>


Expected result:

Nothing.

(as with PHP4)

Actual result:
--
Undeclared entity warning





-- 
Edit this bug report at http://bugs.php.net/?id=39382&edit=1

#39383 [Bgs->Opn]: PHP erroneously converts keys to integer

[lamotkin at softhome dot net]

 ID:   39383
 User updated by:  lamotkin at softhome dot net
 Reported By:  lamotkin at softhome dot net
-Status:   Bogus
+Status:   Open
 Bug Type: Arrays related
 Operating System: Windows 98
 PHP Version:  5.2.0
 New Comment:

Well, you are right, Derick, the doc covered the issue.
But I believe this is a software design error,
because neither

in_array($some_var, $Test, true)
nor
in_array($some_var, $Test, false)

produces no correct results.
But if array keys would be of the type specified
on definition, the

in_array($some_var, $Test, true)

work right.


Previous Comments:


[2006-11-04 20:38:01] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

.



[2006-11-04 20:33:55] lamotkin at softhome dot net

Description:

PHP erroneously converts keys to integer if possible,
but my script is type-sensitive with that code.


Reproduce code:
---
$Test =
array(  "" => "No set",
"1" => "Yes",
"0" => "No");
var_dump($Test);
echo "";
$Test =
array(  "" => "No set",
1 => "Yes",
0 => "No");
var_dump($Test);
echo "";


Expected result:

'var_dump's must NOT be the same


Actual result:
--
'var_dump's ARE the same






-- 
Edit this bug report at http://bugs.php.net/?id=39383&edit=1

#39386 [NEW]: ftp_rawlist() complains about open_basedir restriction

[webmaster at eeb-world dot de]

From: webmaster at eeb-world dot de
Operating system: Linux Debian
PHP version:  5.2.0
PHP Bug Type: FTP related
Bug description:  ftp_rawlist() complains about open_basedir restriction

Description:

ftp_rawlist() complains about open_basedir restriction effect and a failed
creation of a temporary file.

I backtraced this function in the PHP-source:

ftp_rawlist() =>

INTERNAL BACKTRACE:

ftp_list()   (in php_ftp.con line 732)
ftp_genlist()(in ftp.con line 651)
php_stream_fopen_tmpfile()   (in ftp.con line 1600)
php_open_temporary_fd()  (in plain_wrapper.c  on line 152) with first
param = NULL

And this function (php_open_temporary_fd()) has a new open_basedir check
since 5.2.0.

( http://www.eeb-welt.de/php-error.gif )

I dont want to place /tmp in the open_basedir - param too or add an
alternative TMPDIR to the env-vars.

Reproduce code:
---
function file_list($dir, $mode) {
$result = ftp_rawlist($this->stream, $dir);
$data = array();
if (is_array($result)) {
foreach ($result as $key => $elem) {
preg_match("#^(d|-)([rwx\-]{9}) +([\d]+) ([\w\d\-]+)
+([\w\d\-]+) +([\d]+) ([\w]{3}) +([\d]{1,2}) ([\d :]{5}) (.{3,})#i",
$elem, $result_detailed);
if (isset($result_detailed[1])) {
$today = getdate();
$time = strtotime("$result_detailed[8]
$result_detailed[7] $today[year] $result_detailed[9]");
if ($result_detailed[1] == "d" && $mode == 0) {
$data[] = array($result_detailed[10],
$result_detailed[6], $time, 0);
} elseif ($result_detailed[1] == "-" && $mode == 1
&& 
  !substr_count($result_detailed[10],
".ht") && 
  !substr_count($result_detailed[10],
".php")) {
$data[] = array($result_detailed[10],
$result_detailed[6], $time, 1);
} elseif ($mode == 2) {
$type = ($result_detailed[1] == "-") ? 1 : 0;
$data[] = array($result_detailed[10],
$result_detailed[6], $time, $type);
}
}
}
return $data;
}
}


Expected result:

Usually a 2-dimensional array and no basedir-errors

Actual result:
--
Warning: ftp_rawlist() [function.ftp-rawlist]: open_basedir restriction in
effect. File(/tmp) is not within the allowed path(s):
(/var/www/web1/html/:/var/www/web1/phptmp/:/var/www/web1/files/) in
/var/www/web1/html/admin/classes/class_ftp.php on line 51

Warning: ftp_rawlist() [function.ftp-rawlist]: Unable to create temporary
file. Check permissions in temporary files directory. in
/var/www/web1/html/admin/classes/class_ftp.php on line 51


-- 
Edit bug report at http://bugs.php.net/?id=39386&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39386&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39386&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39386&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39386&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39386&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39386&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39386&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39386&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39386&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39386&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39386&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39386&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39386&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39386&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39386&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39386&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39386&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39386&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39386&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39386&r=mysqlcfg

#39385 [NEW]: International friendly mktime alternative

[thehub at lofty dot net dot au]

From: thehub at lofty dot net dot au
Operating system: any
PHP version:  4.4.4
PHP Bug Type: *Languages/Translation
Bug description:  International friendly mktime alternative

Description:

I've had to make my own mkdate function to call mktime and rearrange the
params because mktime uses the usa-only format that doesn't make
mathematical sense. Please add these functions to the standard php
date/time functions.

Reproduce code:
---
mkdate($day[, $month[, $year]])

mkitime($second[, $minute[, $hour[, $day[, $month[, $year[,
$is_dst]]))

mkidate($year[, $month[, $day[, $hour[, $minute[, $second[, $is_dst]])

Expected result:

Give the writer of the original mktime function a good whack upside the
head for me, for thinking that repeating a mistake enough times will make
it right.


-- 
Edit bug report at http://bugs.php.net/?id=39385&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39385&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39385&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39385&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39385&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39385&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39385&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39385&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39385&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39385&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39385&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39385&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39385&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39385&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39385&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39385&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39385&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39385&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39385&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39385&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39385&r=mysqlcfg

#39384 [NEW]: PHP assumes that an object will not be used after serialize() is called on it

[cw264701 at ohiou dot edu]

From: cw264701 at ohiou dot edu
Operating system: Ubuntu Linux
PHP version:  5.2.0
PHP Bug Type: Class/Object related
Bug description:  PHP assumes that an object will not be used after serialize() 
is called on it

Description:

PHP assumes that I will not use an object after serializing it.  This
shouldn't cause problems if my object's class does not define a __sleep()
function, but if it does, and that __sleep() function modifies the object,
then I can't reliably use that object until it is recreated using
unserialize().

There is no mention of this in the documentation for the serialize()
function, or anywhere else that I saw.  More importantly, if PHP expects
me to *not* use an object after calling serialize() on it, then PHP should
produce an error message if I *do* try to use that object before
unserialization.

This is one of several problems (not all necessarily "bugs", but shaky
designs), that I've come across recently, which greatly reduces the
ability for PHP applications to take advantage of *transparency*.  I.e., I
should not have to care how a class is implemented (for instance, whether
or not it uses the magic __sleep() function) to make use of it.

I recently adopted the ezpdo (http://ezpdo.net/) ORM tool.  It has
probably hurt my productivity more than it has helped because it makes use
of such leaky abstractions.  Some of these may be the fault of that tool,
but many flaws like this seem to be more general PHP problems.  (Sorry for
the rant, but I think issues like this are pretty important, and the reason
I very often become frustrated with PHP.)

Reproduce code:
---
size = $size;
for( $a = 1; $a <= $size; ++$a ) {
  for( $b = 1; $b <= $size; ++$b ) {
$this->table[$a][$b] = $a * $b;
  }
}
  }

  public function __sleep() {
$this->table = null;
return( array("size") );
  }

  public function __wakeup() {
$this->MultiplicationTable($this->size);
  }
}

$mt = new MultiplicationTable(4);
echo $mt->size . ", " . $mt->table[4][4] . "\n";
$serialized_mt = serialize($mt);
echo $mt->size . ", " . $mt->table[4][4] . "\n";
$unserialized_mt = unserialize($serialized_mt);
echo $unserialized_mt->size . ", " . $unserialized_mt->table[4][4] .
"\n";

?>

Expected result:

Well, ideally the object would still "work" after creating a serialize()'d
version of it, but I think making that work would require significant
changes to PHP's whole serialization model (or perhaps you could just have
__wakeup() be called right after serialization; perhaps only if the object
is accessed again).  But, the more realistic solution would probably
result in some kind of error message when I try to access my $mt object
after calling serialize() on it.

Actual result:
--
4, 16
4,
4, 16

-- 
Edit bug report at http://bugs.php.net/?id=39384&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39384&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39384&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39384&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39384&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39384&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39384&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39384&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39384&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39384&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39384&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39384&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39384&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39384&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39384&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39384&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39384&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39384&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39384&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39384&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39384&r=mysqlcfg

#39383 [Opn->Bgs]: PHP erroneously converts keys to integer

[derick]

 ID:   39383
 Updated by:   [EMAIL PROTECTED]
 Reported By:  lamotkin at softhome dot net
-Status:   Open
+Status:   Bogus
 Bug Type: Arrays related
 Operating System: Windows 98
 PHP Version:  5.2.0
 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

.


Previous Comments:


[2006-11-04 20:33:55] lamotkin at softhome dot net

Description:

PHP erroneously converts keys to integer if possible,
but my script is type-sensitive with that code.


Reproduce code:
---
$Test =
array(  "" => "No set",
"1" => "Yes",
"0" => "No");
var_dump($Test);
echo "";
$Test =
array(  "" => "No set",
1 => "Yes",
0 => "No");
var_dump($Test);
echo "";


Expected result:

'var_dump's must NOT be the same


Actual result:
--
'var_dump's ARE the same






-- 
Edit this bug report at http://bugs.php.net/?id=39383&edit=1

#39383 [NEW]: PHP erroneously converts keys to integer

[lamotkin at softhome dot net]

From: lamotkin at softhome dot net
Operating system: Windows 98
PHP version:  5.2.0
PHP Bug Type: Arrays related
Bug description:  PHP erroneously converts keys to integer

Description:

PHP erroneously converts keys to integer if possible,
but my script is type-sensitive with that code.


Reproduce code:
---
$Test =
array(  "" => "No set",
"1" => "Yes",
"0" => "No");
var_dump($Test);
echo "";
$Test =
array(  "" => "No set",
1 => "Yes",
0 => "No");
var_dump($Test);
echo "";


Expected result:

'var_dump's must NOT be the same


Actual result:
--
'var_dump's ARE the same


-- 
Edit bug report at http://bugs.php.net/?id=39383&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39383&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39383&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39383&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39383&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39383&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39383&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39383&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39383&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39383&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39383&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39383&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39383&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39383&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39383&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39383&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39383&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39383&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39383&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39383&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39383&r=mysqlcfg

#39382 [NEW]: "Undeclared entity error"

[phpbugs at thequod dot de]

From: phpbugs at thequod dot de
Operating system: Ubuntu Linux
PHP version:  5CVS-2006-11-04 (CVS)
PHP Bug Type: XML related
Bug description:  "Undeclared entity error"

Description:

Using a regular entity like "®" throws a "Undeclared 
entity warning" error with xml_parse().

If this is bogus, please give a hint about what I'm doing 
wrong.
Is this maybe a libxml problem?

btw: it also fails with other DOCTYPEs or with a full 
html-head-body construct.

Reproduce code:
---

http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
®';

$parser = xml_parser_create();
if (!xml_parse($parser, $xml))
{
echo xml_error_string(xml_get_error_code($parser)) . "\n";
}
xml_parser_free($parser);
?>


Expected result:

Nothing.

(as with PHP4)

Actual result:
--
Undeclared entity warning

-- 
Edit bug report at http://bugs.php.net/?id=39382&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39382&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39382&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39382&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39382&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39382&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39382&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39382&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39382&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39382&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39382&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39382&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39382&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39382&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39382&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39382&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39382&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39382&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39382&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39382&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39382&r=mysqlcfg

#39353 [Bgs]: more imagecopyresized() alpha problems

[pajoye]

 ID:   39353
 Updated by:   [EMAIL PROTECTED]
 Reported By:  seth at pricepages dot org
 Status:   Bogus
 Bug Type: GD related
 Operating System: Mac 10.4
 PHP Version:  5CVS-2006-11-02 (snap)
 Assigned To:  pajoye
 New Comment:

It is in there since a long times and all the new functions (that I
added for example) do not have this obvious problem and access the
right buffer directly.

As I agree about the lack of performance of the GD library in some
areas, I do not see the points to criticize it as you did in this
report. Especially not when you get help and support. It is also very
easy to spot problems in other codes without actually taking care about
the reasoning or the history.


Previous Comments:


[2006-11-04 19:53:23] seth at pricepages dot org

> For example?

gdImageCopyResized() in our example (palette -> true color, 
no alpha blending) requires 11+ branches and 3 function 
calls per input pixel. There is another function call and 4+ 
branches per output pixel. I'm skipping a good number of 
branches created by the short-circuiting in each of those 15 
if statements. Those create bubbles in your processor 
pipeline which are going to kill your performance much 
faster than initializing each pixel 3 times.

It's a good thing we are working with small images on fast 
computers. :)

No reply requested.



[2006-11-04 19:32:15] [EMAIL PROTECTED]

A last comment is this free support session, you certainly do not know
that the default contents of an image create by imagecreatetruecolor is
black and not transparent/NULL.



[2006-11-04 19:21:46] [EMAIL PROTECTED]

"That is a workaround. imagecopyresized() isn't working as 
defined in the manual, so you've changed the destination 
image to compensate."

Now you've reached my patience limit.

http://blog.thepimp.net/misc/bug39353_with_alpha.png
is exactly what you expect.

Now if you do not understand the different between the TRANSPARENT
COLOR and the alpha channel of each independent pixel, I cannot help
you further.

But you keep considering other apps behaviors as what should happen in
gd. It is not the case for various reasons (backward compatibility is
one of them).

"But I've seen worse code in the GD library..."

For example?




[2006-11-04 19:16:05] seth at pricepages dot org

That is a workaround. imagecopyresized() isn't working as 
defined in the manual, so you've changed the destination 
image to compensate.

I suppose it's fine if you don't want to fix it, I think I 
can use this workaround for now.

There is a waste of pixel processing, though. You need to 
process the entire final image twice. But I've seen worse 
code in the GD library...



[2006-11-04 18:59:26] [EMAIL PROTECTED]


$img = imagecreatetruecolor($width, $height);
$bgdalpha = imagecolorallocatealpha($img,0,0,0, 127);
imagefill($img, 0,0, $bgdalpha);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW,$srcH);
imagesavealpha($img, 1);
imagepng($img, 'a.png');




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/39353

-- 
Edit this bug report at http://bugs.php.net/?id=39353&edit=1

#39353 [Bgs]: more imagecopyresized() alpha problems

[seth at pricepages dot org]

 ID:   39353
 User updated by:  seth at pricepages dot org
 Reported By:  seth at pricepages dot org
 Status:   Bogus
 Bug Type: GD related
 Operating System: Mac 10.4
 PHP Version:  5CVS-2006-11-02 (snap)
 Assigned To:  pajoye
 New Comment:

> For example?

gdImageCopyResized() in our example (palette -> true color, 
no alpha blending) requires 11+ branches and 3 function 
calls per input pixel. There is another function call and 4+ 
branches per output pixel. I'm skipping a good number of 
branches created by the short-circuiting in each of those 15 
if statements. Those create bubbles in your processor 
pipeline which are going to kill your performance much 
faster than initializing each pixel 3 times.

It's a good thing we are working with small images on fast 
computers. :)

No reply requested.


Previous Comments:


[2006-11-04 19:32:15] [EMAIL PROTECTED]

A last comment is this free support session, you certainly do not know
that the default contents of an image create by imagecreatetruecolor is
black and not transparent/NULL.



[2006-11-04 19:21:46] [EMAIL PROTECTED]

"That is a workaround. imagecopyresized() isn't working as 
defined in the manual, so you've changed the destination 
image to compensate."

Now you've reached my patience limit.

http://blog.thepimp.net/misc/bug39353_with_alpha.png
is exactly what you expect.

Now if you do not understand the different between the TRANSPARENT
COLOR and the alpha channel of each independent pixel, I cannot help
you further.

But you keep considering other apps behaviors as what should happen in
gd. It is not the case for various reasons (backward compatibility is
one of them).

"But I've seen worse code in the GD library..."

For example?




[2006-11-04 19:16:05] seth at pricepages dot org

That is a workaround. imagecopyresized() isn't working as 
defined in the manual, so you've changed the destination 
image to compensate.

I suppose it's fine if you don't want to fix it, I think I 
can use this workaround for now.

There is a waste of pixel processing, though. You need to 
process the entire final image twice. But I've seen worse 
code in the GD library...



[2006-11-04 18:59:26] [EMAIL PROTECTED]


$img = imagecreatetruecolor($width, $height);
$bgdalpha = imagecolorallocatealpha($img,0,0,0, 127);
imagefill($img, 0,0, $bgdalpha);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW,$srcH);
imagesavealpha($img, 1);
imagepng($img, 'a.png');




[2006-11-04 18:10:10] seth at pricepages dot org

But I *still* can't produce the image that I want. I simply 
want to enlarge $small. How can I do this?



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/39353

-- 
Edit this bug report at http://bugs.php.net/?id=39353&edit=1

#39353 [Bgs]: more imagecopyresized() alpha problems

[pajoye]

 ID:   39353
 Updated by:   [EMAIL PROTECTED]
 Reported By:  seth at pricepages dot org
 Status:   Bogus
 Bug Type: GD related
 Operating System: Mac 10.4
 PHP Version:  5CVS-2006-11-02 (snap)
 Assigned To:  pajoye
 New Comment:

A last comment is this free support session, you certainly do not know
that the default contents of an image create by imagecreatetruecolor is
black and not transparent/NULL.


Previous Comments:


[2006-11-04 19:21:46] [EMAIL PROTECTED]

"That is a workaround. imagecopyresized() isn't working as 
defined in the manual, so you've changed the destination 
image to compensate."

Now you've reached my patience limit.

http://blog.thepimp.net/misc/bug39353_with_alpha.png
is exactly what you expect.

Now if you do not understand the different between the TRANSPARENT
COLOR and the alpha channel of each independent pixel, I cannot help
you further.

But you keep considering other apps behaviors as what should happen in
gd. It is not the case for various reasons (backward compatibility is
one of them).

"But I've seen worse code in the GD library..."

For example?




[2006-11-04 19:16:05] seth at pricepages dot org

That is a workaround. imagecopyresized() isn't working as 
defined in the manual, so you've changed the destination 
image to compensate.

I suppose it's fine if you don't want to fix it, I think I 
can use this workaround for now.

There is a waste of pixel processing, though. You need to 
process the entire final image twice. But I've seen worse 
code in the GD library...



[2006-11-04 18:59:26] [EMAIL PROTECTED]


$img = imagecreatetruecolor($width, $height);
$bgdalpha = imagecolorallocatealpha($img,0,0,0, 127);
imagefill($img, 0,0, $bgdalpha);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW,$srcH);
imagesavealpha($img, 1);
imagepng($img, 'a.png');




[2006-11-04 18:10:10] seth at pricepages dot org

But I *still* can't produce the image that I want. I simply 
want to enlarge $small. How can I do this?



[2006-11-04 17:50:39] [EMAIL PROTECTED]

"Shouldn't it be default?"

Backward compatibility... GD is an old library. But things are getting
better.

No bug > bogus.



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/39353

-- 
Edit this bug report at http://bugs.php.net/?id=39353&edit=1

#39353 [Bgs]: more imagecopyresized() alpha problems

[pajoye]

 ID:   39353
 Updated by:   [EMAIL PROTECTED]
 Reported By:  seth at pricepages dot org
 Status:   Bogus
 Bug Type: GD related
 Operating System: Mac 10.4
 PHP Version:  5CVS-2006-11-02 (snap)
 Assigned To:  pajoye
 New Comment:

"That is a workaround. imagecopyresized() isn't working as 
defined in the manual, so you've changed the destination 
image to compensate."

Now you've reached my patience limit.

http://blog.thepimp.net/misc/bug39353_with_alpha.png
is exactly what you expect.

Now if you do not understand the different between the TRANSPARENT
COLOR and the alpha channel of each independent pixel, I cannot help
you further.

But you keep considering other apps behaviors as what should happen in
gd. It is not the case for various reasons (backward compatibility is
one of them).

"But I've seen worse code in the GD library..."

For example?



Previous Comments:


[2006-11-04 19:16:05] seth at pricepages dot org

That is a workaround. imagecopyresized() isn't working as 
defined in the manual, so you've changed the destination 
image to compensate.

I suppose it's fine if you don't want to fix it, I think I 
can use this workaround for now.

There is a waste of pixel processing, though. You need to 
process the entire final image twice. But I've seen worse 
code in the GD library...



[2006-11-04 18:59:26] [EMAIL PROTECTED]


$img = imagecreatetruecolor($width, $height);
$bgdalpha = imagecolorallocatealpha($img,0,0,0, 127);
imagefill($img, 0,0, $bgdalpha);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW,$srcH);
imagesavealpha($img, 1);
imagepng($img, 'a.png');




[2006-11-04 18:10:10] seth at pricepages dot org

But I *still* can't produce the image that I want. I simply 
want to enlarge $small. How can I do this?



[2006-11-04 17:50:39] [EMAIL PROTECTED]

"Shouldn't it be default?"

Backward compatibility... GD is an old library. But things are getting
better.

No bug > bogus.



[2006-11-04 17:48:46] seth at pricepages dot org

Oh! No, I didn't realize imagesavealpha() existed. Why is 
saving the alpha a separate function? Shouldn't it be default?



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/39353

-- 
Edit this bug report at http://bugs.php.net/?id=39353&edit=1

#39381 [Opn]: __destruct bug

[rygorde4 at sbcglobal dot net]

 ID:   39381
 User updated by:  rygorde4 at sbcglobal dot net
 Reported By:  rygorde4 at sbcglobal dot net
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Not Applicable
 PHP Version:  5.2.0
 New Comment:

Description:

If functions are called within __destruct without
register_shutdown_function being called on __destruct within a class,
and global variables (that are assigned classes) called in that class
will not work. This is a bug
specificly with PHP 5.2.0.

This bug was reported multiple times at my discussion system (here
http://community.mybboard.net/showthread.php?tid=13506 and here
http://community.mybboard.net/showthread.php?tid=12430). Calling
register_shutdown_function on __destruct, I was able to use that as a
workaround, but the problem remains with  __destruct. Please contact
me
with any information you need, and I will gladly assist you.

Reproduce code:
---
You can install a fresh version of MyBB 1.2 here:
http://mybboard.com/downloads.php using PHP 5.2.0. The problems lay in
inc/class_core.php

Expected result:

No error, shutdown functions should run properly

Actual result:
--
Fatal error: Call to a member function run_hooks() on a non-object in
/www/xxx/pub/inc/functions.php on line 146


Previous Comments:


[2006-11-04 19:18:23] rygorde4 at sbcglobal dot net

Description:

If functions are called within __destruct without
register_shutdown_function being called on __destruct within a class,
and global variables that are classes will not work. This is a bug
specificly with PHP 5.2.0.

This bug was reported multiple times at my discussion system (here
http://community.mybboard.net/showthread.php?tid=13506 and here
http://community.mybboard.net/showthread.php?tid=12430). Calling
register_shutdown_function on __destruct, I was able to use that as a
workaround, but the problem remains with  __destruct. Please contact me
with any information you need, and I will gladly assist you.

Reproduce code:
---
You can install a fresh version of MyBB 1.2 here:
http://mybboard.com/downloads.php using PHP 5.2.0. The problems lay in
inc/class_core.php

Expected result:

No error, shutdown functions should run properly

Actual result:
--
Fatal error: Call to a member function run_hooks() on a non-object in
/www/xxx/pub/inc/functions.php on line 146 





-- 
Edit this bug report at http://bugs.php.net/?id=39381&edit=1

#39381 [NEW]: __destruct bug

[rygorde4 at sbcglobal dot net]

From: rygorde4 at sbcglobal dot net
Operating system: Not Applicable
PHP version:  5.2.0
PHP Bug Type: Unknown/Other Function
Bug description:  __destruct bug

Description:

If functions are called within __destruct without
register_shutdown_function being called on __destruct within a class, and
global variables that are classes will not work. This is a bug specificly
with PHP 5.2.0.

This bug was reported multiple times at my discussion system (here
http://community.mybboard.net/showthread.php?tid=13506 and here
http://community.mybboard.net/showthread.php?tid=12430). Calling
register_shutdown_function on __destruct, I was able to use that as a
workaround, but the problem remains with  __destruct. Please contact me
with any information you need, and I will gladly assist you.

Reproduce code:
---
You can install a fresh version of MyBB 1.2 here:
http://mybboard.com/downloads.php using PHP 5.2.0. The problems lay in
inc/class_core.php

Expected result:

No error, shutdown functions should run properly

Actual result:
--
Fatal error: Call to a member function run_hooks() on a non-object in
/www/xxx/pub/inc/functions.php on line 146 

-- 
Edit bug report at http://bugs.php.net/?id=39381&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39381&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39381&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39381&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39381&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39381&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39381&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39381&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39381&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39381&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39381&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39381&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39381&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39381&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39381&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39381&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39381&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39381&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39381&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39381&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39381&r=mysqlcfg

#39353 [Bgs]: more imagecopyresized() alpha problems

[seth at pricepages dot org]

 ID:   39353
 User updated by:  seth at pricepages dot org
 Reported By:  seth at pricepages dot org
 Status:   Bogus
 Bug Type: GD related
 Operating System: Mac 10.4
 PHP Version:  5CVS-2006-11-02 (snap)
 Assigned To:  pajoye
 New Comment:

That is a workaround. imagecopyresized() isn't working as 
defined in the manual, so you've changed the destination 
image to compensate.

I suppose it's fine if you don't want to fix it, I think I 
can use this workaround for now.

There is a waste of pixel processing, though. You need to 
process the entire final image twice. But I've seen worse 
code in the GD library...


Previous Comments:


[2006-11-04 18:59:26] [EMAIL PROTECTED]


$img = imagecreatetruecolor($width, $height);
$bgdalpha = imagecolorallocatealpha($img,0,0,0, 127);
imagefill($img, 0,0, $bgdalpha);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW,$srcH);
imagesavealpha($img, 1);
imagepng($img, 'a.png');




[2006-11-04 18:10:10] seth at pricepages dot org

But I *still* can't produce the image that I want. I simply 
want to enlarge $small. How can I do this?



[2006-11-04 17:50:39] [EMAIL PROTECTED]

"Shouldn't it be default?"

Backward compatibility... GD is an old library. But things are getting
better.

No bug > bogus.



[2006-11-04 17:48:46] seth at pricepages dot org

Oh! No, I didn't realize imagesavealpha() existed. Why is 
saving the alpha a separate function? Shouldn't it be default?



[2006-11-04 17:45:05] seth at pricepages dot org

I am simply trying to enlarge the original image. I can't find 
a work-around in PHP, but I can create the image in Adobe 
Photoshop.

This is what I'm attempting to create:
http://pricepages.org/temp/partialTrans2.png

By the way, this image is the outline of Bermuda. :)



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/39353

-- 
Edit this bug report at http://bugs.php.net/?id=39353&edit=1

#39362 [Opn->Asn]: imap_open retries 3 times on failed auth

[iliaa]

 ID:   39362
 Updated by:   [EMAIL PROTECTED]
 Reported By:  askalski at gmail dot com
-Status:   Open
+Status:   Assigned
 Bug Type: IMAP related
 Operating System: Linux
 PHP Version:  5CVS-2006-11-03 (snap)
-Assigned To:  
+Assigned To:  iliaa
 New Comment:

Actually this is more of a feature request to add the ability 
to control the number of retries, something the current API 
does not allow.


Previous Comments:


[2006-11-03 20:48:44] askalski at gmail dot com

I'm sorry if I did not make this clear enough in the original bug
report.

This is very much a bug in PHP.  While you're correct in saying
c-client controls the number of retries it makes, it's up to PHP to
change MAXLOGINTRIALS from its default of 3 to 1.

There is no way to work around this from a PHP script, because the
mail_parameters() function is not exposed through the PHP imap module. 
The only way is for PHP to make a mail_parameters() call in
ext/imap/php_imap.c during module initialization.



[2006-11-03 20:03:22] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

PHP does not control the number of retries performed, that is 
something the imap (c-client) library controls.



[2006-11-03 15:47:18] askalski at gmail dot com

Description:

imap_open will retry 3 times on bad credentials.  Some IMAP or POP
servers delay on successive bad logins, making a failed imap_open take
very long.  Worse, some servers will lock the user out because of
repeated failed login attempts.

Somewhere during module initialization, this call needs to be made:

mail_parameters(NIL, SET_MAXLOGINTRIALS, (void *) 1);


Reproduce code:
---
imap_open("{mailserver/pop}", "user", "badpass");


Expected result:

It should try logging in only once.


Actual result:
--
It tries logging in three times (watch with a packet sniffer or
strace).

write(0, "AUTH LOGIN\r\n", 12)  = 12
...
read(0, "-ERR Bad authentication\r\n", 8192) = 25
write(0, "AUTH LOGIN\r\n", 12)  = 12
...
read(0, "-ERR Bad authentication\r\n", 8192) = 25
write(0, "AUTH LOGIN\r\n", 12)  = 12
...
read(0, "-ERR Bad authentication\r\n", 8192) = 25
write(0, "QUIT\r\n", 6) = 6
read(0, "+OK Sayonara\r\n", 8192)   = 14
write(1, "\nWarning: imap_open(): Couldn\'t "..., 104) = 104






-- 
Edit this bug report at http://bugs.php.net/?id=39362&edit=1

#39353 [Bgs]: more imagecopyresized() alpha problems

[pajoye]

 ID:   39353
 Updated by:   [EMAIL PROTECTED]
 Reported By:  seth at pricepages dot org
 Status:   Bogus
 Bug Type: GD related
 Operating System: Mac 10.4
 PHP Version:  5CVS-2006-11-02 (snap)
 Assigned To:  pajoye
 New Comment:


$img = imagecreatetruecolor($width, $height);
$bgdalpha = imagecolorallocatealpha($img,0,0,0, 127);
imagefill($img, 0,0, $bgdalpha);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW,$srcH);
imagesavealpha($img, 1);
imagepng($img, 'a.png');



Previous Comments:


[2006-11-04 18:10:10] seth at pricepages dot org

But I *still* can't produce the image that I want. I simply 
want to enlarge $small. How can I do this?



[2006-11-04 17:50:39] [EMAIL PROTECTED]

"Shouldn't it be default?"

Backward compatibility... GD is an old library. But things are getting
better.

No bug > bogus.



[2006-11-04 17:48:46] seth at pricepages dot org

Oh! No, I didn't realize imagesavealpha() existed. Why is 
saving the alpha a separate function? Shouldn't it be default?



[2006-11-04 17:45:05] seth at pricepages dot org

I am simply trying to enlarge the original image. I can't find 
a work-around in PHP, but I can create the image in Adobe 
Photoshop.

This is what I'm attempting to create:
http://pricepages.org/temp/partialTrans2.png

By the way, this image is the outline of Bermuda. :)



[2006-11-04 17:42:49] [EMAIL PROTECTED]


Another thing you may not know is how to preserve the alpha channel
information on save:

http://blog.thepimp.net/misc/bug39353_with_alpha.png

you have to use imagesavealpha($img,true); before calling imagepng.





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/39353

-- 
Edit this bug report at http://bugs.php.net/?id=39353&edit=1

#39359 [Opn->Bgs]: Server API says 2.0 instead of 2.0

[iliaa]

 ID:   39359
 Updated by:   [EMAIL PROTECTED]
 Reported By:  OlafvdSpek at Gmail dot Com
-Status:   Open
+Status:   Bogus
 Bug Type: Apache2 related
 Operating System: Windows XP
 PHP Version:  5.2.0
 New Comment:

no.


Previous Comments:


[2006-11-04 12:09:16] OlafvdSpek at Gmail dot Com

> It is the same sapi, 2.0 refers to major Apache version.

But 2.0 is major.minor, shouldn't it say Apache 2 then?



[2006-11-03 19:57:46] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The sapi name does not change with the Apache version. It is 
the same sapi, 2.0 refers to major Apache version.



[2006-11-03 13:17:59] OlafvdSpek at Gmail dot Com

Description:

Hi,

phpinfo() says "Server API: Apache 2.0 Handler" although it's running
on 2.2.3.

Reproduce code:
---
phpinfo();

Expected result:

Server API: Apache 2.2 Handler

Actual result:
--
Server API: Apache 2.0 Handler





-- 
Edit this bug report at http://bugs.php.net/?id=39359&edit=1

#39376 [Com]: Unable to load dynamic library 'ext/php_oci8.dll'

[crescentfreshpot at yahoo dot com]

 ID:   39376
 Comment by:   crescentfreshpot at yahoo dot com
 Reported By:  automap at gmail dot com
 Status:   Open
 Bug Type: OCI8 related
 Operating System: WindowsXP
 PHP Version:  5.2.0
 New Comment:

You need oracle instant client installed. See bug #39360


Previous Comments:


[2006-11-04 12:09:06] automap at gmail dot com

Description:

after I upgraded the Apache from 2.0.59 to 2.2.3
then I downloaded php5.2.0 to replace the original php5.0.5
but when I start apache, error log shows as below:
Unable to load dynamic library 'C:/php52/ext/php_oci8.dll' -
\xd5\xd2\xb2\xbb\xb5\xbd\xd6\xb8\xb6\xa8\xb5\xc4\xb3\xcc\xd0\xf2\xa1\xa3\r\n
in Unknown on line 0

Reproduce code:
---
the error log shows that the php_oci8.dll is not loaded when Apache is
started
my oracle client version is 9.2.0.1
it's good to load oci8 dll before I upgrade
because I upgrded php and apache , so I'm not sure whether it's a
problem of php, either inside apache

Expected result:

I need to load oci8 into the apache ,so I can connect my oracle db

Actual result:
--
now the oci8 dll can't be loaded.is it the problem of php5.2.0?





-- 
Edit this bug report at http://bugs.php.net/?id=39376&edit=1

#39353 [Bgs]: more imagecopyresized() alpha problems

[seth at pricepages dot org]

 ID:   39353
 User updated by:  seth at pricepages dot org
 Reported By:  seth at pricepages dot org
 Status:   Bogus
 Bug Type: GD related
 Operating System: Mac 10.4
 PHP Version:  5CVS-2006-11-02 (snap)
 Assigned To:  pajoye
 New Comment:

But I *still* can't produce the image that I want. I simply 
want to enlarge $small. How can I do this?


Previous Comments:


[2006-11-04 17:50:39] [EMAIL PROTECTED]

"Shouldn't it be default?"

Backward compatibility... GD is an old library. But things are getting
better.

No bug > bogus.



[2006-11-04 17:48:46] seth at pricepages dot org

Oh! No, I didn't realize imagesavealpha() existed. Why is 
saving the alpha a separate function? Shouldn't it be default?



[2006-11-04 17:45:05] seth at pricepages dot org

I am simply trying to enlarge the original image. I can't find 
a work-around in PHP, but I can create the image in Adobe 
Photoshop.

This is what I'm attempting to create:
http://pricepages.org/temp/partialTrans2.png

By the way, this image is the outline of Bermuda. :)



[2006-11-04 17:42:49] [EMAIL PROTECTED]


Another thing you may not know is how to preserve the alpha channel
information on save:

http://blog.thepimp.net/misc/bug39353_with_alpha.png

you have to use imagesavealpha($img,true); before calling imagepng.





[2006-11-04 17:26:18] [EMAIL PROTECTED]

"I thought that a color with alpha = 127 will produce the 
same results as a color marked as transparent. I want the 
contents of $small to overwrite everything in $img. This is 
not correct?"

But this color (imagecolortransparent($small)) *IS* the transparent
color and is ignored on copy.

http://blog.thepimp.net/misc/bug39353_out.png is it not what you
expect?

If not, provide an image to show what you expect.



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/39353

-- 
Edit this bug report at http://bugs.php.net/?id=39353&edit=1

#39353 [Opn->Bgs]: more imagecopyresized() alpha problems

[pajoye]

 ID:   39353
 Updated by:   [EMAIL PROTECTED]
 Reported By:  seth at pricepages dot org
-Status:   Open
+Status:   Bogus
 Bug Type: GD related
 Operating System: Mac 10.4
 PHP Version:  5CVS-2006-11-02 (snap)
 Assigned To:  pajoye
 New Comment:

"Shouldn't it be default?"

Backward compatibility... GD is an old library. But things are getting
better.

No bug > bogus.


Previous Comments:


[2006-11-04 17:48:46] seth at pricepages dot org

Oh! No, I didn't realize imagesavealpha() existed. Why is 
saving the alpha a separate function? Shouldn't it be default?



[2006-11-04 17:45:05] seth at pricepages dot org

I am simply trying to enlarge the original image. I can't find 
a work-around in PHP, but I can create the image in Adobe 
Photoshop.

This is what I'm attempting to create:
http://pricepages.org/temp/partialTrans2.png

By the way, this image is the outline of Bermuda. :)



[2006-11-04 17:42:49] [EMAIL PROTECTED]


Another thing you may not know is how to preserve the alpha channel
information on save:

http://blog.thepimp.net/misc/bug39353_with_alpha.png

you have to use imagesavealpha($img,true); before calling imagepng.





[2006-11-04 17:26:18] [EMAIL PROTECTED]

"I thought that a color with alpha = 127 will produce the 
same results as a color marked as transparent. I want the 
contents of $small to overwrite everything in $img. This is 
not correct?"

But this color (imagecolortransparent($small)) *IS* the transparent
color and is ignored on copy.

http://blog.thepimp.net/misc/bug39353_out.png is it not what you
expect?

If not, provide an image to show what you expect.



[2006-11-04 17:11:55] seth at pricepages dot org

Also, if you alter the transparency of a color to be 64, and 
you fill the image with that color, shouldn't the final 
image have a transparency of 64?

imagecolorsforindex() gives the correct alpha value, but the 
"true color" PNG produced in my browser has no partial 
transparency. (it is all opaque)

The code that I am using looks like this:
...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocatealpha($img, 255,0,0, 64);
imagefill($img, 0,0, $red);
imagealphablending($img, false);

/*
var_dump(imagecolorsforindex($img, imagecolorat($img, 
0,0)));
exit;
//*/

header('Content-Type: image/png');
...



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/39353

-- 
Edit this bug report at http://bugs.php.net/?id=39353&edit=1

#39353 [Opn]: more imagecopyresized() alpha problems

[seth at pricepages dot org]

 ID:   39353
 User updated by:  seth at pricepages dot org
 Reported By:  seth at pricepages dot org
 Status:   Open
 Bug Type: GD related
 Operating System: Mac 10.4
 PHP Version:  5CVS-2006-11-02 (snap)
 Assigned To:  pajoye
 New Comment:

Oh! No, I didn't realize imagesavealpha() existed. Why is 
saving the alpha a separate function? Shouldn't it be default?


Previous Comments:


[2006-11-04 17:45:05] seth at pricepages dot org

I am simply trying to enlarge the original image. I can't find 
a work-around in PHP, but I can create the image in Adobe 
Photoshop.

This is what I'm attempting to create:
http://pricepages.org/temp/partialTrans2.png

By the way, this image is the outline of Bermuda. :)



[2006-11-04 17:42:49] [EMAIL PROTECTED]


Another thing you may not know is how to preserve the alpha channel
information on save:

http://blog.thepimp.net/misc/bug39353_with_alpha.png

you have to use imagesavealpha($img,true); before calling imagepng.





[2006-11-04 17:26:18] [EMAIL PROTECTED]

"I thought that a color with alpha = 127 will produce the 
same results as a color marked as transparent. I want the 
contents of $small to overwrite everything in $img. This is 
not correct?"

But this color (imagecolortransparent($small)) *IS* the transparent
color and is ignored on copy.

http://blog.thepimp.net/misc/bug39353_out.png is it not what you
expect?

If not, provide an image to show what you expect.



[2006-11-04 17:11:55] seth at pricepages dot org

Also, if you alter the transparency of a color to be 64, and 
you fill the image with that color, shouldn't the final 
image have a transparency of 64?

imagecolorsforindex() gives the correct alpha value, but the 
"true color" PNG produced in my browser has no partial 
transparency. (it is all opaque)

The code that I am using looks like this:
...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocatealpha($img, 255,0,0, 64);
imagefill($img, 0,0, $red);
imagealphablending($img, false);

/*
var_dump(imagecolorsforindex($img, imagecolorat($img, 
0,0)));
exit;
//*/

header('Content-Type: image/png');
...



[2006-11-04 17:01:40] seth at pricepages dot org

I thought that a color with alpha = 127 will produce the 
same results as a color marked as transparent. I want the 
contents of $small to overwrite everything in $img. This is 
not correct?

The "bug#1" and "bug#2" that I wrote were not intended to be 
links, they were just supposed to show that I believe there 
are two bugs at work here. This web site turned them into 
links.

To reproduce the second bug without changing the first, 
alter my code to look like this:

...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img, 255,0,0);
imagecolortransparent($img, $red);
imagefill($img, 0,0, $red);

imagecopyresized($img, $small, 0,0, 0,0, $width, $height, 
$srcW, $srcH);
...

The background is supposed to be transparent, but where 
$small has partial transparency, $img becomes fully opaque. 
The final image should have partial transparency around the 
object, but it does not.



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/39353

-- 
Edit this bug report at http://bugs.php.net/?id=39353&edit=1

#39353 [Fbk->Opn]: more imagecopyresized() alpha problems

[seth at pricepages dot org]

 ID:   39353
 User updated by:  seth at pricepages dot org
 Reported By:  seth at pricepages dot org
-Status:   Feedback
+Status:   Open
 Bug Type: GD related
 Operating System: Mac 10.4
 PHP Version:  5CVS-2006-11-02 (snap)
 Assigned To:  pajoye
 New Comment:

I am simply trying to enlarge the original image. I can't find 
a work-around in PHP, but I can create the image in Adobe 
Photoshop.

This is what I'm attempting to create:
http://pricepages.org/temp/partialTrans2.png

By the way, this image is the outline of Bermuda. :)


Previous Comments:


[2006-11-04 17:42:49] [EMAIL PROTECTED]


Another thing you may not know is how to preserve the alpha channel
information on save:

http://blog.thepimp.net/misc/bug39353_with_alpha.png

you have to use imagesavealpha($img,true); before calling imagepng.





[2006-11-04 17:26:18] [EMAIL PROTECTED]

"I thought that a color with alpha = 127 will produce the 
same results as a color marked as transparent. I want the 
contents of $small to overwrite everything in $img. This is 
not correct?"

But this color (imagecolortransparent($small)) *IS* the transparent
color and is ignored on copy.

http://blog.thepimp.net/misc/bug39353_out.png is it not what you
expect?

If not, provide an image to show what you expect.



[2006-11-04 17:11:55] seth at pricepages dot org

Also, if you alter the transparency of a color to be 64, and 
you fill the image with that color, shouldn't the final 
image have a transparency of 64?

imagecolorsforindex() gives the correct alpha value, but the 
"true color" PNG produced in my browser has no partial 
transparency. (it is all opaque)

The code that I am using looks like this:
...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocatealpha($img, 255,0,0, 64);
imagefill($img, 0,0, $red);
imagealphablending($img, false);

/*
var_dump(imagecolorsforindex($img, imagecolorat($img, 
0,0)));
exit;
//*/

header('Content-Type: image/png');
...



[2006-11-04 17:01:40] seth at pricepages dot org

I thought that a color with alpha = 127 will produce the 
same results as a color marked as transparent. I want the 
contents of $small to overwrite everything in $img. This is 
not correct?

The "bug#1" and "bug#2" that I wrote were not intended to be 
links, they were just supposed to show that I believe there 
are two bugs at work here. This web site turned them into 
links.

To reproduce the second bug without changing the first, 
alter my code to look like this:

...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img, 255,0,0);
imagecolortransparent($img, $red);
imagefill($img, 0,0, $red);

imagecopyresized($img, $small, 0,0, 0,0, $width, $height, 
$srcW, $srcH);
...

The background is supposed to be transparent, but where 
$small has partial transparency, $img becomes fully opaque. 
The final image should have partial transparency around the 
object, but it does not.



[2006-11-04 15:52:11] [EMAIL PROTECTED]

"imagecopyresized() is ignoring alpha the blending mode. 
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is 
this code that skips processing transparent pixels:"

My statement covers this part of your report, which is wrong. It is the
expected behavior to do not copy the transparent color.

The transparent color has nothing to do with the *alpha* channel of any
other pixels.

The alpha blending mode affects *only* pixels with alpha channels, not
the transparent color.

Which second bug are you talking about? The link bug#1 and bug#2 does
not work, maybe you are refering to them?

As a sidenote, it makes no sense to call colorresolve for truecolor
images, just use imagecolorallocate or imagecolorallocatealpha.

Here is your example, with a check for truecolor or indexed image, and
showing which color is the *transparent* color
(imagecolortransparent):
$small = imagecreatefrompng('bug39353.png');
if (imageistruecolor($small)) {
echo "truecolor image\n"; 
} else {
$c = imagecolortransparent($small);
echo "transparent index: " . $c . "\n";
print_r( imagecolorsforindex($small,$c));
}

$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);

$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img,255,0,0);
imagefill($img, 0,0, $red);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW,$srcH);
imagepng($img, 'a.png');
?>
and the result image:
http://blog.thepimp.net/misc/bug39353_out.png

Please note that the transparent color is the index 0 and has these
values:
transparent index: 0
Array
(
[red] => 246
[green] => 24

#39353 [Fbk]: more imagecopyresized() alpha problems

[pajoye]

 ID:   39353
 Updated by:   [EMAIL PROTECTED]
 Reported By:  seth at pricepages dot org
 Status:   Feedback
 Bug Type: GD related
 Operating System: Mac 10.4
 PHP Version:  5CVS-2006-11-02 (snap)
 Assigned To:  pajoye
 New Comment:


Another thing you may not know is how to preserve the alpha channel
information on save:

http://blog.thepimp.net/misc/bug39353_with_alpha.png

you have to use imagesavealpha($img,true); before calling imagepng.




Previous Comments:


[2006-11-04 17:26:18] [EMAIL PROTECTED]

"I thought that a color with alpha = 127 will produce the 
same results as a color marked as transparent. I want the 
contents of $small to overwrite everything in $img. This is 
not correct?"

But this color (imagecolortransparent($small)) *IS* the transparent
color and is ignored on copy.

http://blog.thepimp.net/misc/bug39353_out.png is it not what you
expect?

If not, provide an image to show what you expect.



[2006-11-04 17:11:55] seth at pricepages dot org

Also, if you alter the transparency of a color to be 64, and 
you fill the image with that color, shouldn't the final 
image have a transparency of 64?

imagecolorsforindex() gives the correct alpha value, but the 
"true color" PNG produced in my browser has no partial 
transparency. (it is all opaque)

The code that I am using looks like this:
...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocatealpha($img, 255,0,0, 64);
imagefill($img, 0,0, $red);
imagealphablending($img, false);

/*
var_dump(imagecolorsforindex($img, imagecolorat($img, 
0,0)));
exit;
//*/

header('Content-Type: image/png');
...



[2006-11-04 17:01:40] seth at pricepages dot org

I thought that a color with alpha = 127 will produce the 
same results as a color marked as transparent. I want the 
contents of $small to overwrite everything in $img. This is 
not correct?

The "bug#1" and "bug#2" that I wrote were not intended to be 
links, they were just supposed to show that I believe there 
are two bugs at work here. This web site turned them into 
links.

To reproduce the second bug without changing the first, 
alter my code to look like this:

...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img, 255,0,0);
imagecolortransparent($img, $red);
imagefill($img, 0,0, $red);

imagecopyresized($img, $small, 0,0, 0,0, $width, $height, 
$srcW, $srcH);
...

The background is supposed to be transparent, but where 
$small has partial transparency, $img becomes fully opaque. 
The final image should have partial transparency around the 
object, but it does not.



[2006-11-04 15:52:11] [EMAIL PROTECTED]

"imagecopyresized() is ignoring alpha the blending mode. 
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is 
this code that skips processing transparent pixels:"

My statement covers this part of your report, which is wrong. It is the
expected behavior to do not copy the transparent color.

The transparent color has nothing to do with the *alpha* channel of any
other pixels.

The alpha blending mode affects *only* pixels with alpha channels, not
the transparent color.

Which second bug are you talking about? The link bug#1 and bug#2 does
not work, maybe you are refering to them?

As a sidenote, it makes no sense to call colorresolve for truecolor
images, just use imagecolorallocate or imagecolorallocatealpha.

Here is your example, with a check for truecolor or indexed image, and
showing which color is the *transparent* color
(imagecolortransparent):
$small = imagecreatefrompng('bug39353.png');
if (imageistruecolor($small)) {
echo "truecolor image\n"; 
} else {
$c = imagecolortransparent($small);
echo "transparent index: " . $c . "\n";
print_r( imagecolorsforindex($small,$c));
}

$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);

$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img,255,0,0);
imagefill($img, 0,0, $red);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW,$srcH);
imagepng($img, 'a.png');
?>
and the result image:
http://blog.thepimp.net/misc/bug39353_out.png

Please note that the transparent color is the index 0 and has these
values:
transparent index: 0
Array
(
[red] => 246
[green] => 246
[blue] => 246
[alpha] => 127
)

Is it more clear now?





[2006-11-04 00:28:54] seth at pricepages dot org

Well, you can tell me what I'm doing wrong then. I have a 
source image with fully transparent pixels. I would like to 
copy it over another image, so the final image has fully 
transparent pixels.

To do this, I set imagealphablen

#39353 [Opn->Fbk]: more imagecopyresized() alpha problems

[pajoye]

 ID:   39353
 Updated by:   [EMAIL PROTECTED]
 Reported By:  seth at pricepages dot org
-Status:   Open
+Status:   Feedback
 Bug Type: GD related
 Operating System: Mac 10.4
 PHP Version:  5CVS-2006-11-02 (snap)
 Assigned To:  pajoye
 New Comment:

"I thought that a color with alpha = 127 will produce the 
same results as a color marked as transparent. I want the 
contents of $small to overwrite everything in $img. This is 
not correct?"

But this color (imagecolortransparent($small)) *IS* the transparent
color and is ignored on copy.

http://blog.thepimp.net/misc/bug39353_out.png is it not what you
expect?

If not, provide an image to show what you expect.


Previous Comments:


[2006-11-04 17:11:55] seth at pricepages dot org

Also, if you alter the transparency of a color to be 64, and 
you fill the image with that color, shouldn't the final 
image have a transparency of 64?

imagecolorsforindex() gives the correct alpha value, but the 
"true color" PNG produced in my browser has no partial 
transparency. (it is all opaque)

The code that I am using looks like this:
...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocatealpha($img, 255,0,0, 64);
imagefill($img, 0,0, $red);
imagealphablending($img, false);

/*
var_dump(imagecolorsforindex($img, imagecolorat($img, 
0,0)));
exit;
//*/

header('Content-Type: image/png');
...



[2006-11-04 17:01:40] seth at pricepages dot org

I thought that a color with alpha = 127 will produce the 
same results as a color marked as transparent. I want the 
contents of $small to overwrite everything in $img. This is 
not correct?

The "bug#1" and "bug#2" that I wrote were not intended to be 
links, they were just supposed to show that I believe there 
are two bugs at work here. This web site turned them into 
links.

To reproduce the second bug without changing the first, 
alter my code to look like this:

...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img, 255,0,0);
imagecolortransparent($img, $red);
imagefill($img, 0,0, $red);

imagecopyresized($img, $small, 0,0, 0,0, $width, $height, 
$srcW, $srcH);
...

The background is supposed to be transparent, but where 
$small has partial transparency, $img becomes fully opaque. 
The final image should have partial transparency around the 
object, but it does not.



[2006-11-04 15:52:11] [EMAIL PROTECTED]

"imagecopyresized() is ignoring alpha the blending mode. 
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is 
this code that skips processing transparent pixels:"

My statement covers this part of your report, which is wrong. It is the
expected behavior to do not copy the transparent color.

The transparent color has nothing to do with the *alpha* channel of any
other pixels.

The alpha blending mode affects *only* pixels with alpha channels, not
the transparent color.

Which second bug are you talking about? The link bug#1 and bug#2 does
not work, maybe you are refering to them?

As a sidenote, it makes no sense to call colorresolve for truecolor
images, just use imagecolorallocate or imagecolorallocatealpha.

Here is your example, with a check for truecolor or indexed image, and
showing which color is the *transparent* color
(imagecolortransparent):
$small = imagecreatefrompng('bug39353.png');
if (imageistruecolor($small)) {
echo "truecolor image\n"; 
} else {
$c = imagecolortransparent($small);
echo "transparent index: " . $c . "\n";
print_r( imagecolorsforindex($small,$c));
}

$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);

$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img,255,0,0);
imagefill($img, 0,0, $red);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW,$srcH);
imagepng($img, 'a.png');
?>
and the result image:
http://blog.thepimp.net/misc/bug39353_out.png

Please note that the transparent color is the index 0 and has these
values:
transparent index: 0
Array
(
[red] => 246
[green] => 246
[blue] => 246
[alpha] => 127
)

Is it more clear now?





[2006-11-04 00:28:54] seth at pricepages dot org

Well, you can tell me what I'm doing wrong then. I have a 
source image with fully transparent pixels. I would like to 
copy it over another image, so the final image has fully 
transparent pixels.

To do this, I set imagealphablending() to false, and I copy 
via imagecopyresized(). But no fully transparent pixels are 
copied.

Your statement does not address the second bug that I 
mentioned.



[2006-11-04 00:17:25] [EMAIL PROTECTED]

"But if the alpha blending

#39380 [NEW]: php crashes in preg_match

[corinl at gmx dot de]

From: corinl at gmx dot de
Operating system: linux debian
PHP version:  5.2.0
PHP Bug Type: Scripting Engine problem
Bug description:  php crashes in preg_match

Description:

running the reproduce code crashes php 5.1.6 and 5.2.0 with a segmentation
fault.

--
(gdb) set args php_crash.php
(gdb) run
Starting program: /usr/bin/php php_crash.php
[Thread debugging using libthread_db enabled]
[New Thread -1486911808 (LWP 25359)]
ok1
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1486911808 (LWP 25359)]
0x080b167d in match (
eptr=0xa73d1542 "t; schwierig\r\n>< seltsam ><
sensibel >< spontan >< stur >< tätowiert ><
treu >< unberechenbar \r\n\r\n>< unentschlossen
>utf8;   /* Local copy of the flag */
(gdb)


Reproduce code:
---
http://www.netskin.de/download/php_crash.php.txt

Expected result:

ok1
ok2


Actual result:
--
ok1
-> crashes before echo('ok2')

-- 
Edit bug report at http://bugs.php.net/?id=39380&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39380&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39380&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39380&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39380&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39380&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39380&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39380&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39380&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39380&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39380&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39380&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39380&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39380&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39380&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39380&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39380&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39380&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39380&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39380&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39380&r=mysqlcfg

#39353 [Opn]: more imagecopyresized() alpha problems

[seth at pricepages dot org]

 ID:   39353
 User updated by:  seth at pricepages dot org
 Reported By:  seth at pricepages dot org
 Status:   Open
 Bug Type: GD related
 Operating System: Mac 10.4
 PHP Version:  5CVS-2006-11-02 (snap)
 Assigned To:  pajoye
 New Comment:

Also, if you alter the transparency of a color to be 64, and 
you fill the image with that color, shouldn't the final 
image have a transparency of 64?

imagecolorsforindex() gives the correct alpha value, but the 
"true color" PNG produced in my browser has no partial 
transparency. (it is all opaque)

The code that I am using looks like this:
...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocatealpha($img, 255,0,0, 64);
imagefill($img, 0,0, $red);
imagealphablending($img, false);

/*
var_dump(imagecolorsforindex($img, imagecolorat($img, 
0,0)));
exit;
//*/

header('Content-Type: image/png');
...


Previous Comments:


[2006-11-04 17:01:40] seth at pricepages dot org

I thought that a color with alpha = 127 will produce the 
same results as a color marked as transparent. I want the 
contents of $small to overwrite everything in $img. This is 
not correct?

The "bug#1" and "bug#2" that I wrote were not intended to be 
links, they were just supposed to show that I believe there 
are two bugs at work here. This web site turned them into 
links.

To reproduce the second bug without changing the first, 
alter my code to look like this:

...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img, 255,0,0);
imagecolortransparent($img, $red);
imagefill($img, 0,0, $red);

imagecopyresized($img, $small, 0,0, 0,0, $width, $height, 
$srcW, $srcH);
...

The background is supposed to be transparent, but where 
$small has partial transparency, $img becomes fully opaque. 
The final image should have partial transparency around the 
object, but it does not.



[2006-11-04 15:52:11] [EMAIL PROTECTED]

"imagecopyresized() is ignoring alpha the blending mode. 
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is 
this code that skips processing transparent pixels:"

My statement covers this part of your report, which is wrong. It is the
expected behavior to do not copy the transparent color.

The transparent color has nothing to do with the *alpha* channel of any
other pixels.

The alpha blending mode affects *only* pixels with alpha channels, not
the transparent color.

Which second bug are you talking about? The link bug#1 and bug#2 does
not work, maybe you are refering to them?

As a sidenote, it makes no sense to call colorresolve for truecolor
images, just use imagecolorallocate or imagecolorallocatealpha.

Here is your example, with a check for truecolor or indexed image, and
showing which color is the *transparent* color
(imagecolortransparent):
$small = imagecreatefrompng('bug39353.png');
if (imageistruecolor($small)) {
echo "truecolor image\n"; 
} else {
$c = imagecolortransparent($small);
echo "transparent index: " . $c . "\n";
print_r( imagecolorsforindex($small,$c));
}

$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);

$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img,255,0,0);
imagefill($img, 0,0, $red);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW,$srcH);
imagepng($img, 'a.png');
?>
and the result image:
http://blog.thepimp.net/misc/bug39353_out.png

Please note that the transparent color is the index 0 and has these
values:
transparent index: 0
Array
(
[red] => 246
[green] => 246
[blue] => 246
[alpha] => 127
)

Is it more clear now?





[2006-11-04 00:28:54] seth at pricepages dot org

Well, you can tell me what I'm doing wrong then. I have a 
source image with fully transparent pixels. I would like to 
copy it over another image, so the final image has fully 
transparent pixels.

To do this, I set imagealphablending() to false, and I copy 
via imagecopyresized(). But no fully transparent pixels are 
copied.

Your statement does not address the second bug that I 
mentioned.



[2006-11-04 00:17:25] [EMAIL PROTECTED]

"But if the alpha blending is set to false, you want to copy 
the transparent pixels."

No, you do not want. Alpha channel and transparent color are two
different things. Alpha blending works with the alpha channel not with
the transparent color.

I closed this bug (bogus), reopen it if you think that I misunderstood
your problem.



[2006-11-03 00:23:48] seth at pricepages dot org

Description:

I'm not sure how many bugs are hidden here, but I thought 
this should be submitted.

imagecopyresized(

#39353 [Fbk->Opn]: more imagecopyresized() alpha problems

[seth at pricepages dot org]

 ID:   39353
 User updated by:  seth at pricepages dot org
 Reported By:  seth at pricepages dot org
-Status:   Feedback
+Status:   Open
 Bug Type: GD related
 Operating System: Mac 10.4
 PHP Version:  5CVS-2006-11-02 (snap)
 Assigned To:  pajoye
 New Comment:

I thought that a color with alpha = 127 will produce the 
same results as a color marked as transparent. I want the 
contents of $small to overwrite everything in $img. This is 
not correct?

The "bug#1" and "bug#2" that I wrote were not intended to be 
links, they were just supposed to show that I believe there 
are two bugs at work here. This web site turned them into 
links.

To reproduce the second bug without changing the first, 
alter my code to look like this:

...
$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img, 255,0,0);
imagecolortransparent($img, $red);
imagefill($img, 0,0, $red);

imagecopyresized($img, $small, 0,0, 0,0, $width, $height, 
$srcW, $srcH);
...

The background is supposed to be transparent, but where 
$small has partial transparency, $img becomes fully opaque. 
The final image should have partial transparency around the 
object, but it does not.


Previous Comments:


[2006-11-04 15:52:11] [EMAIL PROTECTED]

"imagecopyresized() is ignoring alpha the blending mode. 
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is 
this code that skips processing transparent pixels:"

My statement covers this part of your report, which is wrong. It is the
expected behavior to do not copy the transparent color.

The transparent color has nothing to do with the *alpha* channel of any
other pixels.

The alpha blending mode affects *only* pixels with alpha channels, not
the transparent color.

Which second bug are you talking about? The link bug#1 and bug#2 does
not work, maybe you are refering to them?

As a sidenote, it makes no sense to call colorresolve for truecolor
images, just use imagecolorallocate or imagecolorallocatealpha.

Here is your example, with a check for truecolor or indexed image, and
showing which color is the *transparent* color
(imagecolortransparent):
$small = imagecreatefrompng('bug39353.png');
if (imageistruecolor($small)) {
echo "truecolor image\n"; 
} else {
$c = imagecolortransparent($small);
echo "transparent index: " . $c . "\n";
print_r( imagecolorsforindex($small,$c));
}

$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);

$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img,255,0,0);
imagefill($img, 0,0, $red);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW,$srcH);
imagepng($img, 'a.png');
?>
and the result image:
http://blog.thepimp.net/misc/bug39353_out.png

Please note that the transparent color is the index 0 and has these
values:
transparent index: 0
Array
(
[red] => 246
[green] => 246
[blue] => 246
[alpha] => 127
)

Is it more clear now?





[2006-11-04 00:28:54] seth at pricepages dot org

Well, you can tell me what I'm doing wrong then. I have a 
source image with fully transparent pixels. I would like to 
copy it over another image, so the final image has fully 
transparent pixels.

To do this, I set imagealphablending() to false, and I copy 
via imagecopyresized(). But no fully transparent pixels are 
copied.

Your statement does not address the second bug that I 
mentioned.



[2006-11-04 00:17:25] [EMAIL PROTECTED]

"But if the alpha blending is set to false, you want to copy 
the transparent pixels."

No, you do not want. Alpha channel and transparent color are two
different things. Alpha blending works with the alpha channel not with
the transparent color.

I closed this bug (bogus), reopen it if you think that I misunderstood
your problem.



[2006-11-03 00:23:48] seth at pricepages dot org

Description:

I'm not sure how many bugs are hidden here, but I thought 
this should be submitted.

imagecopyresized() is ignoring alpha the blending mode. 
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is 
this code that skips processing transparent pixels:
  tmp = gdImageGetPixel (src, x, y);
  if (gdImageGetTransparent (src) == tmp) {
  tox += stx[x - srcX];
  continue;
  }

But if the alpha blending is set to false, you want to copy 
the transparent pixels. So commenting out this if statement 
removes one bug. There is other similar code in this loop, 
so maybe it should all be removed?

Unfortunately, all result pixels still opaque, when the 
source image pixels are partially transparent. So this code 
does not fix the problem.

Reproduce code:
---
http://pricepages.org/temp/partialTrans.png')

#39379 [NEW]: something worong with function rename()

[[EMAIL PROTECTED]]

From: [EMAIL PROTECTED]
Operating system: windows xp sp2
PHP version:  5.2.0
PHP Bug Type: *Directory/Filesystem functions
Bug description:  something worong with function rename()

Description:

When I use function rename() to rename a folder by recursion.
But it doesn't work as usual.It renamed the file twice.

Reproduce code:
---
function addDomain($directory)
{
if (is_dir($directory))
{
$dirHandle = opendir($directory);   

while ($file = readdir($dirHandle))
{
if ($file != '.' && $file != '..')
{
if (is_dir($file))
{   
//do nothing;
}
else 
{

rename($directory.$file,$directory.$file.'r');
echo $directory.$file.'';
}
}
}

closedir($dirHandle);
}
}

addDomain("test/");

Expected result:

test/Q4.phptest/Q5.php

Actual result:
--
test/Q4.phptest/Q5.phptest/Q4.phprtest/Q5.phpr

-- 
Edit bug report at http://bugs.php.net/?id=39379&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39379&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39379&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39379&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39379&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39379&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39379&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39379&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39379&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39379&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39379&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39379&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39379&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39379&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39379&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39379&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39379&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39379&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39379&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39379&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39379&r=mysqlcfg

#39378 [Fbk->Opn]: Php page secure ftp change directory command fails

[sanjib dot biswas at ieee dot org]

 ID:   39378
 User updated by:  sanjib dot biswas at ieee dot org
 Reported By:  sanjib dot biswas at ieee dot org
-Status:   Feedback
+Status:   Open
 Bug Type: Directory function related
 Operating System: Windos XP
-PHP Version:  4.3.1.4
+PHP Version:  4.4.4
 New Comment:

n/a


Previous Comments:


[2006-11-04 15:56:40] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

This php version does not exist.

Please test using php 5.2.0 or 4.4.x.



[2006-11-04 15:43:30] sanjib dot biswas at ieee dot org

I have corrected the PHP version we are using.



[2006-11-04 15:30:00] sanjib dot biswas at ieee dot org

Description:

Although from the php page we are able to connect to a secure ftp
server. But change directory (cd/chdir) command inside a php page to a
secure ftp server always fails.

Reproduce code:
---


Expected result:

I should get:
Current directory: \
Current directory is now: \somedir

Actual result:
--
I get:
Current directory: \
Couldn't change directory





-- 
Edit this bug report at http://bugs.php.net/?id=39378&edit=1

#39378 [Opn->Fbk]: Php page secure ftp change directory command fails

[pajoye]

 ID:   39378
 Updated by:   [EMAIL PROTECTED]
 Reported By:  sanjib dot biswas at ieee dot org
-Status:   Open
+Status:   Feedback
 Bug Type: Directory function related
 Operating System: Windos XP
 PHP Version:  4.3.1.4
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

This php version does not exist.

Please test using php 5.2.0 or 4.4.x.


Previous Comments:


[2006-11-04 15:43:30] sanjib dot biswas at ieee dot org

I have corrected the PHP version we are using.



[2006-11-04 15:30:00] sanjib dot biswas at ieee dot org

Description:

Although from the php page we are able to connect to a secure ftp
server. But change directory (cd/chdir) command inside a php page to a
secure ftp server always fails.

Reproduce code:
---


Expected result:

I should get:
Current directory: \
Current directory is now: \somedir

Actual result:
--
I get:
Current directory: \
Couldn't change directory





-- 
Edit this bug report at http://bugs.php.net/?id=39378&edit=1

#39353 [Bgs->Fbk]: more imagecopyresized() alpha problems

[pajoye]

 ID:   39353
 Updated by:   [EMAIL PROTECTED]
 Reported By:  seth at pricepages dot org
-Status:   Bogus
+Status:   Feedback
 Bug Type: GD related
 Operating System: Mac 10.4
 PHP Version:  5CVS-2006-11-02 (snap)
 Assigned To:  pajoye
 New Comment:

"imagecopyresized() is ignoring alpha the blending mode. 
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is 
this code that skips processing transparent pixels:"

My statement covers this part of your report, which is wrong. It is the
expected behavior to do not copy the transparent color.

The transparent color has nothing to do with the *alpha* channel of any
other pixels.

The alpha blending mode affects *only* pixels with alpha channels, not
the transparent color.

Which second bug are you talking about? The link bug#1 and bug#2 does
not work, maybe you are refering to them?

As a sidenote, it makes no sense to call colorresolve for truecolor
images, just use imagecolorallocate or imagecolorallocatealpha.

Here is your example, with a check for truecolor or indexed image, and
showing which color is the *transparent* color
(imagecolortransparent):
$small = imagecreatefrompng('bug39353.png');
if (imageistruecolor($small)) {
echo "truecolor image\n"; 
} else {
$c = imagecolortransparent($small);
echo "transparent index: " . $c . "\n";
print_r( imagecolorsforindex($small,$c));
}

$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);

$img = imagecreatetruecolor($width, $height);
$red = imagecolorallocate($img,255,0,0);
imagefill($img, 0,0, $red);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height,
$srcW,$srcH);
imagepng($img, 'a.png');
?>
and the result image:
http://blog.thepimp.net/misc/bug39353_out.png

Please note that the transparent color is the index 0 and has these
values:
transparent index: 0
Array
(
[red] => 246
[green] => 246
[blue] => 246
[alpha] => 127
)

Is it more clear now?




Previous Comments:


[2006-11-04 00:28:54] seth at pricepages dot org

Well, you can tell me what I'm doing wrong then. I have a 
source image with fully transparent pixels. I would like to 
copy it over another image, so the final image has fully 
transparent pixels.

To do this, I set imagealphablending() to false, and I copy 
via imagecopyresized(). But no fully transparent pixels are 
copied.

Your statement does not address the second bug that I 
mentioned.



[2006-11-04 00:17:25] [EMAIL PROTECTED]

"But if the alpha blending is set to false, you want to copy 
the transparent pixels."

No, you do not want. Alpha channel and transparent color are two
different things. Alpha blending works with the alpha channel not with
the transparent color.

I closed this bug (bogus), reopen it if you think that I misunderstood
your problem.



[2006-11-03 00:23:48] seth at pricepages dot org

Description:

I'm not sure how many bugs are hidden here, but I thought 
this should be submitted.

imagecopyresized() is ignoring alpha the blending mode. 
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is 
this code that skips processing transparent pixels:
  tmp = gdImageGetPixel (src, x, y);
  if (gdImageGetTransparent (src) == tmp) {
  tox += stx[x - srcX];
  continue;
  }

But if the alpha blending is set to false, you want to copy 
the transparent pixels. So commenting out this if statement 
removes one bug. There is other similar code in this loop, 
so maybe it should all be removed?

Unfortunately, all result pixels still opaque, when the 
source image pixels are partially transparent. So this code 
does not fix the problem.

Reproduce code:
---
http://pricepages.org/temp/partialTrans.png');

$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);

$img = imagecreatetruecolor($width, $height);
$red = imagecolorresolve($img,255,0,0);
imagefill($img, 0,0, $red);
imagealphablending($img, false);

imagecopyresized($img, $small, 0,0, 0,0, $width, $height, $srcW,
$srcH);

header('Content-Type: image/png');
imagepng($img);
?>

Expected result:

The image is filled with red, and a partially transparent 
black-and-white image is composited on top of it. Because 
alpha blending is set to false, there should be no red showing 
in the final image. (bug#1, squashed above)

Also, because the greyscale image should have partial 
transparency, there should be a gradient between black and 
red, but there is none. It is only black or only red. (bug#2)







-- 
Edit this bug report at http://bugs.php.net/?id=39353&edit=1

#39378 [Opn]: Php page secure ftp change directory command fails

[sanjib dot biswas at ieee dot org]

 ID:   39378
 User updated by:  sanjib dot biswas at ieee dot org
 Reported By:  sanjib dot biswas at ieee dot org
 Status:   Open
 Bug Type: Directory function related
 Operating System: Windos XP
-PHP Version:  4.4.4
+PHP Version:  4.3.1.4
 New Comment:

I have corrected the PHP version we are using.


Previous Comments:


[2006-11-04 15:30:00] sanjib dot biswas at ieee dot org

Description:

Although from the php page we are able to connect to a secure ftp
server. But change directory (cd/chdir) command inside a php page to a
secure ftp server always fails.

Reproduce code:
---


Expected result:

I should get:
Current directory: \
Current directory is now: \somedir

Actual result:
--
I get:
Current directory: \
Couldn't change directory





-- 
Edit this bug report at http://bugs.php.net/?id=39378&edit=1

#39378 [NEW]: Php page secure ftp change directory command fails

[sanjib dot biswas at ieee dot org]

From: sanjib dot biswas at ieee dot org
Operating system: Windos XP
PHP version:  4.4.4
PHP Bug Type: Directory function related
Bug description:  Php page secure ftp change directory command fails

Description:

Although from the php page we are able to connect to a secure ftp server.
But change directory (cd/chdir) command inside a php page to a secure ftp
server always fails.

Reproduce code:
---


Expected result:

I should get:
Current directory: \
Current directory is now: \somedir

Actual result:
--
I get:
Current directory: \
Couldn't change directory

-- 
Edit bug report at http://bugs.php.net/?id=39378&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39378&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39378&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39378&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39378&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39378&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39378&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39378&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39378&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39378&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39378&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39378&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39378&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39378&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39378&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39378&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39378&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39378&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39378&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39378&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39378&r=mysqlcfg

#39130 [Com]: Compile failure with the compiler of VC++ 2005

[sailormax at inbox dot lv]

 ID:   39130
 Comment by:   sailormax at inbox dot lv
 Reported By:  ben dot yan at msn dot com
 Status:   Assigned
 Bug Type: Compile Failure
 Operating System: Windows
 PHP Version:  5.2.0RC5
 Assigned To:  wez
 New Comment:

I have same error while trying compile my module. With previous PHP all
was fine.
With 5.2.0 all fine too, if comment 2 lines at config.w32.h:
#define _USE_32BIT_TIME_T 1
#define HAVE_STDLIB_H 1

used VC++ 2005 Express Edition


Previous Comments:


[2006-10-12 11:19:20] [EMAIL PROTECTED]

I've seen this before; I think have the fix on a company laptop that is
currently occupied and I'll commit it just as soon as I can get access
to it again.



[2006-10-12 08:28:29] [EMAIL PROTECTED]

Wez, you added those lines for VC++ 2005 compability. Could you have a
look?



[2006-10-11 18:29:43] ben dot yan at msn dot com

Description:

Compile with VS.NET 2005

c:\program files\microsoft visual studio 8\vc\include\sys\stat.inl(44)
: error C2466: cannot allocate an array of constant size 0
c:\program files\microsoft visual studio 8\vc\include\sys\stat.inl(49)
: error C2466: cannot allocate an array of constant size 0
c:\program files\microsoft visual studio 8\vc\include\sys\utime.inl(39)
: error C2466: cannot allocate an array of constant size 0
c:\program files\microsoft visual studio 8\vc\include\sys\utime.inl(44)
: error C2466: cannot allocate an array of constant size 0
c:\program files\microsoft visual studio 8\vc\include\sys\utime.inl(49)
: error C2466: cannot allocate an array of constant size 0
c:\program files\microsoft visual studio 8\vc\include\sys\utime.inl(78)
: error C2466: cannot allocate an array of constant size 0


Reproduce code:
---
look the zend.h :

...

#include 

/*
 * general definitions
 */

#ifdef ZEND_WIN32
# include "zend_config.w32.h"
# define ZEND_PATHS_SEPARATOR   ';'
#elif defined(XXX)
...
#endif


Expected result:

Look the line 151 at the <../main/config.w32.h>:

/* vs.net 2005 has a 64-bit time_t.  This will likely break
 * 3rdParty libs that were built with older compilers; switch
 * back to 32-bit */
#define _USE_32BIT_TIME_T 1
#define HAVE_STDLIB_H 1


so the config.w32.h should be included first. But it isn't so in the
zend.h:

#include 

/*
 * general definitions
 */

#ifdef ZEND_WIN32
# include "zend_config.w32.h"
# define ZEND_PATHS_SEPARATOR   ';'
#elif defined(XXX)
...
#endif


This would induce the compile error. and if 

#include 

BEHIND the 

#ifdef ZEND_WIN32
# include "zend_config.w32.h"
# define ZEND_PATHS_SEPARATOR   ';'
#elif defined(XXX)
...
#endif

,it will be ok.

Actual result:
--
error C2466: cannot allocate an array of constant size 0





-- 
Edit this bug report at http://bugs.php.net/?id=39130&edit=1

#39356 [Bgs->Opn]: in_array() causes "Nesting level too deep" fatal error

[cynic]

 ID:   39356
 Updated by:   [EMAIL PROTECTED]
 Reported By:  7am dot online at gmail dot com
-Status:   Bogus
+Status:   Open
 Bug Type: Arrays related
 Operating System: Windows XP
 PHP Version:  5.2.0
 New Comment:

http://php.net/in_array is completely quiet about references

this is a change from 5.1 so it should at least be a documentation
problem.


Previous Comments:


[2006-11-03 14:01:24] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

In php 5 objects are passed by reference, so your code does in  
fact create a circular dependency. 



[2006-11-03 03:04:24] 7am dot online at gmail dot com

Description:

Doing a in_array() check against an array containing objects with
recursive dependency causes a "Nesting level too deep - recursive
dependency?" fatal error.

Reproduce code:
---
a = $a;
$a->b = $b;

$test = array($a, $b);

var_dump(in_array($a, $test));

Expected result:

bool(true), as in PHP5.1.6

Actual result:
--
Fatal error: Nesting level too deep - recursive dependency? in
[FILENAME] on line 19





-- 
Edit this bug report at http://bugs.php.net/?id=39356&edit=1

#39365 [Bgs->Opn]: getElementsByTagNameNS() does not return elements in a default namespace

[z_rules55 at hotmail dot com]

 ID:   39365
 User updated by:  z_rules55 at hotmail dot com
 Reported By:  z_rules55 at hotmail dot com
-Status:   Bogus
+Status:   Open
 Bug Type: DOM XML related
 Operating System: WinXP Professional
 PHP Version:  5.2.0
 New Comment:

Per the XML spec, setting the xmlns attribute on an element but with no
prefix (like I did with $root) sets a default namespace for that element
and its descendants. $default_ns_element and $explicit_ns_element,
therefore, do not need the xmlns attribute to be in 'my_namespace'
because they inherit the namespace from $root by default.


Previous Comments:


[2006-11-04 08:03:04] [EMAIL PROTECTED]

$xml->createElement('element', 'default_ns_element')

That's not in the default namespace, that's in no namespace at 
all this way.

Can't work this way



[2006-11-03 21:28:54] z_rules55 at hotmail dot com

Additional note: getElementsByTagName('element') does, in fact, find
both nodes.



[2006-11-03 21:12:54] z_rules55 at hotmail dot com

Description:

Calling getElementsByTagNameNS() on a DOMDocument or a DOMElement does
not return elements that are under a default namespace. The example
below finds $explicit_ns_element, but not $default_ns_element.

Reproduce code:
---
appendChild($xml->createElementNS($namespace, 'root'));
$default_ns_element = $root->appendChild($xml->createElement('element',
'default_ns_element'));
$explicit_ns_element =
$root->appendChild($xml->createElementNS($namespace, 'element',
'explicit_ns_element'));
foreach($xml->getElementsByTagNameNS($namespace, 'element') as $el) {
echo $el->nodeValue."\n";
}
echo "\n";
foreach($root->getElementsByTagNameNS($namespace, 'element') as $el) {
echo $el->nodeValue."\n";
}
?>

Expected result:

default_ns_element
explicit_ns_element

default_ns_element
explicit_ns_element

Actual result:
--
explicit_ns_element

explicit_ns_element





-- 
Edit this bug report at http://bugs.php.net/?id=39365&edit=1

#39377 [NEW]: Transform element ( ) incorrectly

[craig at skrabacz dot com]

From: craig at skrabacz dot com
Operating system: Windows XP
PHP version:  4.4.4
PHP Bug Type: XSLT related
Bug description:  Transform element ( ) incorrectly

Description:

call to xslt_process() transforms non-breaking space incorrectly.  

Reproduce code:
---
$xslt = xslt_create();
$xmlFile = "/../data/pictures.xml";
$xslFile = "picturePage.xsl";
xslt_set_encoding($xslt, 'UTF-8');
$parameters = array (
  'linkKey' => $_GET['page']
);
$transformed =  xslt_process($xslt, $xmlFile, $xslFile, NULL ,NULL,
$parameters);
if ($transformed) {
echo $transformed;
} else {
echo "Error Transforming pictures.xml by applying picturePage.xslt into
employee.html";
echo "Error description " . xslt_error($xslt);
echo "Error code  " . xslt_errno($xslt);
}
xslt_free($xslt);
<->
XSL:


RegLink
picture.html?picture=/

 




Expected result:

formatted transformation with non-breaking space between images.

Actual result:
--
transformation with "Â" instead of non-breaking space.

-- 
Edit bug report at http://bugs.php.net/?id=39377&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39377&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39377&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39377&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39377&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39377&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39377&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39377&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39377&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39377&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39377&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39377&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39377&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39377&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39377&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39377&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39377&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39377&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39377&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39377&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39377&r=mysqlcfg

#39367 [Opn]: Entries from the realpath cache should be refreshed after unlink() and rename()

[j at pureftpd dot org]

 ID:   39367
 User updated by:  j at pureftpd dot org
 Reported By:  j at pureftpd dot org
 Status:   Open
 Bug Type: Filesystem function related
 Operating System: Any
 PHP Version:  5.2.0
 New Comment:

Another fix is to have clearstatcache() also clear the 
realpath cache.

Patch follows. Also available from ftp://ftp.c9x.org/misc/
php_clearstatcache_should_clear_realpath_cache.diff

--- ext/standard/filestat.c.origSat Nov  4 13:14:10 
2006
+++ ext/standard/filestat.c Sat Nov  4 13:14:40 2006
@@ -633,6 +633,7 @@
efree(BG(CurrentLStatFile));
BG(CurrentLStatFile) = NULL;
}
+   realpath_cache_empty();
 }
 /* }}} */
 
--- TSRM/tsrm_virtual_cwd.c.origSat Nov  4 00:56:05 
2006
+++ TSRM/tsrm_virtual_cwd.c Sat Nov  4 13:28:29 2006
@@ -360,6 +360,24 @@
return NULL;
 }
 
+CWD_API int realpath_cache_empty(void)
+{
+   int i;
+   
+   for (i = 0; i < sizeof(CWDG(realpath_cache)) / 
sizeof(CWDG(realpath_cache)[0]); i++) {
+   realpath_cache_bucket *bucket = CWDG
(realpath_cache)[i];
+
+   while (bucket != NULL) {
+   realpath_cache_bucket *r = bucket;
+   bucket = bucket->next;
+   free(r);
+   }
+   CWDG(realpath_cache)[i] = NULL;
+   }
+   CWDG(realpath_cache_size) = 0;
+   
+   return 0;
+}
 
 /* Resolve path relatively to state and put the real path 
into state */
 /* returns 0 for ok, 1 for error */
--- TSRM/tsrm_virtual_cwd.h.origSat Nov  4 02:39:04 
2006
+++ TSRM/tsrm_virtual_cwd.h Sat Nov  4 13:12:50 2006
@@ -156,6 +156,7 @@
 CWD_API DIR *virtual_opendir(const char *pathname 
TSRMLS_DC);
 CWD_API FILE *virtual_popen(const char *command, const char 
*type TSRMLS_DC);
 CWD_API int virtual_access(const char *pathname, int mode 
TSRMLS_DC);
+CWD_API int realpath_cache_empty(void);
 #if defined(TSRM_WIN32)
 /* these are not defined in win32 headers */
 #ifndef W_OK


Previous Comments:


[2006-11-04 02:00:22] j at pureftpd dot org

I think the real bug is that unlink(), rename() and rmdir() 
don't refresh the related realpath cache entries.

Here's a patch that fixes this, also available from ftp://
ftp.c9x.org/misc/
php_sync_realpath_cache_with_unlink_and_rename.diff



--- TSRM/tsrm_virtual_cwd.c.origSat Nov  4 00:56:05 
2006
+++ TSRM/tsrm_virtual_cwd.c Sat Nov  4 02:53:13 2006
@@ -361,6 +361,23 @@
 }
 
 
+CWD_API int realpath_cache_delete(const char *path, int 
path_len) {
+   unsigned long key = realpath_cache_key(path, 
path_len);
+   unsigned long n = key % (sizeof(CWDG
(realpath_cache)) / sizeof(CWDG(realpath_cache)[0]));
+   realpath_cache_bucket **bucket = &CWDG
(realpath_cache)[n];
+
+   while (*bucket != NULL) {
+   if (key == (*bucket)->key && path_len == 
(*bucket)->path_len &&
+  memcmp(path, (*bucket)->path, 
path_len) == 0) {
+   realpath_cache_bucket *r = *bucket;
+   *bucket = (*bucket)->next;
+   CWDG(realpath_cache_size) -= sizeof
(realpath_cache_bucket) + r->path_len + 1 + r->realpath_len 
+ 1;
+   free(r);
+   }
+   }
+   return 0;
+}
+
 /* Resolve path relatively to state and put the real path 
into state */
 /* returns 0 for ok, 1 for error */
 CWD_API int virtual_file_ex(cwd_state *state, const char 
*path, verify_path_func verify_path, int use_realpath)
--- TSRM/tsrm_virtual_cwd.h.origSat Nov  4 02:39:04 
2006
+++ TSRM/tsrm_virtual_cwd.h Sat Nov  4 02:48:04 2006
@@ -232,14 +232,14 @@
 #define VCWD_CHDIR_FILE(path) virtual_chdir_file(path, 
virtual_chdir TSRMLS_CC)
 #define VCWD_GETWD(buf)
 #define VCWD_REALPATH(path, real_path) virtual_realpath
(path, real_path TSRMLS_CC)
-#define VCWD_RENAME(oldname, newname) virtual_rename
(oldname, newname TSRMLS_CC)
+#define VCWD_RENAME(oldname, newname) (virtual_rename
(oldname, newname TSRMLS_CC) + realpath_cache_delete
(oldname, strlen(oldname)) + realpath_cache_delete(newname, 
strlen(newname)))
 #define VCWD_STAT(path, buff) virtual_stat(path, buff 
TSRMLS_CC)
 #if !defined(TSRM_WIN32)
 #define VCWD_LSTAT(path, buff) virtual_lstat(path, buff 
TSRMLS_CC)
 #endif
-#define VCWD_UNLINK(path) virtual_unlink(path TSRMLS_CC)
+#define VCWD_UNLINK(path) (virtual_unlink(path TSRMLS_CC) + 
realpath_cache_delete(path, strlen(path)))
 #define VCWD_MKDIR(pathname, mode) virtual_mkdir(pathname, 
mode TSRMLS_CC)
-#define VCWD_RMDIR(pathname) virtual_rmdir(pathname 
TSRMLS_CC)
+#define VCWD_RMDIR(pathname) (virtual_rmdir(pathname 
TSRMLS_CC) + realpath_cache_delete(pathname, strlen
(pathname)))
 #define VCWD_OPENDIR(pathname) virtual_opendir(pathname 
TSRMLS_CC)
 #define VCWD_POPEN(command, type) virtual_popen(command, 
type TSRMLS_CC)
 #define VCWD_ACCESS(pathnam

#39359 [Bgs->Opn]: Server API says 2.0 instead of 2.0

[OlafvdSpek at Gmail dot Com]

 ID:   39359
 User updated by:  OlafvdSpek at Gmail dot Com
 Reported By:  OlafvdSpek at Gmail dot Com
-Status:   Bogus
+Status:   Open
 Bug Type: Apache2 related
 Operating System: Windows XP
 PHP Version:  5.2.0
 New Comment:

> It is the same sapi, 2.0 refers to major Apache version.

But 2.0 is major.minor, shouldn't it say Apache 2 then?


Previous Comments:


[2006-11-03 19:57:46] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The sapi name does not change with the Apache version. It is 
the same sapi, 2.0 refers to major Apache version.



[2006-11-03 13:17:59] OlafvdSpek at Gmail dot Com

Description:

Hi,

phpinfo() says "Server API: Apache 2.0 Handler" although it's running
on 2.2.3.

Reproduce code:
---
phpinfo();

Expected result:

Server API: Apache 2.2 Handler

Actual result:
--
Server API: Apache 2.0 Handler





-- 
Edit this bug report at http://bugs.php.net/?id=39359&edit=1

#39376 [NEW]: Unable to load dynamic library 'ext/php_oci8.dll'

[automap at gmail dot com]

From: automap at gmail dot com
Operating system: WindowsXP
PHP version:  5.2.0
PHP Bug Type: OCI8 related
Bug description:  Unable to load dynamic library 'ext/php_oci8.dll' 

Description:

after I upgraded the Apache from 2.0.59 to 2.2.3
then I downloaded php5.2.0 to replace the original php5.0.5
but when I start apache, error log shows as below:
Unable to load dynamic library 'C:/php52/ext/php_oci8.dll' -
\xd5\xd2\xb2\xbb\xb5\xbd\xd6\xb8\xb6\xa8\xb5\xc4\xb3\xcc\xd0\xf2\xa1\xa3\r\n
in Unknown on line 0

Reproduce code:
---
the error log shows that the php_oci8.dll is not loaded when Apache is
started
my oracle client version is 9.2.0.1
it's good to load oci8 dll before I upgrade
because I upgrded php and apache , so I'm not sure whether it's a problem
of php, either inside apache

Expected result:

I need to load oci8 into the apache ,so I can connect my oracle db

Actual result:
--
now the oci8 dll can't be loaded.is it the problem of php5.2.0?

-- 
Edit bug report at http://bugs.php.net/?id=39376&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39376&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39376&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39376&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39376&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39376&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39376&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39376&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39376&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39376&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39376&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39376&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39376&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39376&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39376&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39376&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39376&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39376&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39376&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39376&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39376&r=mysqlcfg

#39374 [Opn->Bgs]: it add greater-than sign all page

[derick]

 ID:   39374
 Updated by:   [EMAIL PROTECTED]
 Reported By:  phunsanit at Hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Output Control
 Operating System: win-xp
 PHP Version:  5.2.0
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

.


Previous Comments:


[2006-11-04 11:06:35] Phunsanit at Hotmail dot com

evertime it add & l t ;



[2006-11-04 10:57:56] phunsanit at Hotmail dot com

Description:

# Apache 2.2.3
# PHP 5.1.6
# MySQL 5.0.24a

it add greater-than sign all page






-- 
Edit this bug report at http://bugs.php.net/?id=39374&edit=1

#39373 [Bgs]: strftime does not output %D (%m/%d/%y)

[djhobson at bigpond dot net dot au]

 ID:   39373
 User updated by:  djhobson at bigpond dot net dot au
 Reported By:  djhobson at bigpond dot net dot au
 Status:   Bogus
 Bug Type: Date/time related
 Operating System: Win XP SP 2 - Latest Patches
 PHP Version:  5.2.0
 New Comment:

Sorry Derek,

I see now after searching a bit more through the documentation that
this is clearly indicated.

--
Note: 
Not all conversion specifiers may be supported by your C library, in
which case they will not be supported by PHP's strftime().
Additionally, not all platforms support negative timestamps, therefore
your date range may be limited to no earlier than the Unix epoch. This
means that e.g. %e, %T, %R and %D (there might be more) and dates prior
to Jan 1, 1970 will not work on Windows, some Linux distributions, and a
few other operating systems. For Windows systems a complete overview of
supported conversion specifiers can be found at this » MSDN website. 
-

My bad, and I appologise!


Previous Comments:


[2006-11-04 11:14:03] djhobson at bigpond dot net dot au

Hey Derek!

Would you not think this is wise to put this into your documentation to
alert window users of such circumstances with the current C libraries
they may have installed on their systems?



[2006-11-04 11:10:29] djhobson at bigpond dot net dot au

OIC Now!!! k, thanks derek, please ignore this post and I will repost
on my later findings.  Thank you!



[2006-11-04 11:04:35] djhobson at bigpond dot net dot au

Read 2nd paragraph of strftime() and results are the same! 

THIS IS A MAJOR BUG!



[2006-11-04 10:28:25] [EMAIL PROTECTED]

Please read the 2nd paragraph of:
http://no2.php.net/strftime



[2006-11-04 10:12:55] djhobson at bigpond dot net dot au

Description:

strftime() is failing to output the designated results as given to the
specified online PHP documents.

Reproduce code:
---
Script Name:-
gettime.php

Script contents:-



Output:-

Y:\>php gettime.php


Y:\>

PS: I see there is already a post in regards to %T output, but %D is
the same!

Expected result:

Expected results from online & current downloadable documentation is
that from the given code I should see something like:-

%D - same as %m/%d/%y 

%T - current time, equal to %H:%M:%S 

Simply, NOT HAPPENING MAN!






-- 
Edit this bug report at http://bugs.php.net/?id=39373&edit=1

#39373 [Bgs]: strftime does not output %D (%m/%d/%y)

[djhobson at bigpond dot net dot au]

 ID:   39373
 User updated by:  djhobson at bigpond dot net dot au
 Reported By:  djhobson at bigpond dot net dot au
 Status:   Bogus
 Bug Type: Date/time related
 Operating System: Win XP SP 2 - Latest Patches
 PHP Version:  5.2.0
 New Comment:

Hey Derek!

Would you not think this is wise to put this into your documentation to
alert window users of such circumstances with the current C libraries
they may have installed on their systems?


Previous Comments:


[2006-11-04 11:10:29] djhobson at bigpond dot net dot au

OIC Now!!! k, thanks derek, please ignore this post and I will repost
on my later findings.  Thank you!



[2006-11-04 11:04:35] djhobson at bigpond dot net dot au

Read 2nd paragraph of strftime() and results are the same! 

THIS IS A MAJOR BUG!



[2006-11-04 10:28:25] [EMAIL PROTECTED]

Please read the 2nd paragraph of:
http://no2.php.net/strftime



[2006-11-04 10:12:55] djhobson at bigpond dot net dot au

Description:

strftime() is failing to output the designated results as given to the
specified online PHP documents.

Reproduce code:
---
Script Name:-
gettime.php

Script contents:-



Output:-

Y:\>php gettime.php


Y:\>

PS: I see there is already a post in regards to %T output, but %D is
the same!

Expected result:

Expected results from online & current downloadable documentation is
that from the given code I should see something like:-

%D - same as %m/%d/%y 

%T - current time, equal to %H:%M:%S 

Simply, NOT HAPPENING MAN!






-- 
Edit this bug report at http://bugs.php.net/?id=39373&edit=1

#39373 [Bgs]: strftime does not output %D (%m/%d/%y)

[djhobson at bigpond dot net dot au]

 ID:   39373
 User updated by:  djhobson at bigpond dot net dot au
 Reported By:  djhobson at bigpond dot net dot au
 Status:   Bogus
 Bug Type: Date/time related
 Operating System: Win XP SP 2 - Latest Patches
 PHP Version:  5.2.0
 New Comment:

OIC Now!!! k, thanks derek, please ignore this post and I will repost
on my later findings.  Thank you!


Previous Comments:


[2006-11-04 11:04:35] djhobson at bigpond dot net dot au

Read 2nd paragraph of strftime() and results are the same! 

THIS IS A MAJOR BUG!



[2006-11-04 10:28:25] [EMAIL PROTECTED]

Please read the 2nd paragraph of:
http://no2.php.net/strftime



[2006-11-04 10:12:55] djhobson at bigpond dot net dot au

Description:

strftime() is failing to output the designated results as given to the
specified online PHP documents.

Reproduce code:
---
Script Name:-
gettime.php

Script contents:-



Output:-

Y:\>php gettime.php


Y:\>

PS: I see there is already a post in regards to %T output, but %D is
the same!

Expected result:

Expected results from online & current downloadable documentation is
that from the given code I should see something like:-

%D - same as %m/%d/%y 

%T - current time, equal to %H:%M:%S 

Simply, NOT HAPPENING MAN!






-- 
Edit this bug report at http://bugs.php.net/?id=39373&edit=1

#39374 [Com]: it add greater-than sign all page

[Phunsanit at Hotmail dot com]

 ID:   39374
 Comment by:   Phunsanit at Hotmail dot com
 Reported By:  phunsanit at Hotmail dot com
 Status:   Open
 Bug Type: Output Control
 Operating System: win-xp
 PHP Version:  5.2.0
 New Comment:

evertime it add & l t ;


Previous Comments:


[2006-11-04 10:57:56] phunsanit at Hotmail dot com

Description:

# Apache 2.2.3
# PHP 5.1.6
# MySQL 5.0.24a

it add greater-than sign all page






-- 
Edit this bug report at http://bugs.php.net/?id=39374&edit=1

#39373 [Bgs]: strftime does not output %D (%m/%d/%y)

[djhobson at bigpond dot net dot au]

 ID:   39373
 User updated by:  djhobson at bigpond dot net dot au
 Reported By:  djhobson at bigpond dot net dot au
 Status:   Bogus
 Bug Type: Date/time related
 Operating System: Win XP SP 2 - Latest Patches
 PHP Version:  5.2.0
 New Comment:

Read 2nd paragraph of strftime() and results are the same! 

THIS IS A MAJOR BUG!


Previous Comments:


[2006-11-04 10:28:25] [EMAIL PROTECTED]

Please read the 2nd paragraph of:
http://no2.php.net/strftime



[2006-11-04 10:12:55] djhobson at bigpond dot net dot au

Description:

strftime() is failing to output the designated results as given to the
specified online PHP documents.

Reproduce code:
---
Script Name:-
gettime.php

Script contents:-



Output:-

Y:\>php gettime.php


Y:\>

PS: I see there is already a post in regards to %T output, but %D is
the same!

Expected result:

Expected results from online & current downloadable documentation is
that from the given code I should see something like:-

%D - same as %m/%d/%y 

%T - current time, equal to %H:%M:%S 

Simply, NOT HAPPENING MAN!






-- 
Edit this bug report at http://bugs.php.net/?id=39373&edit=1

#39375 [NEW]: PHP Warning: imap_fetchstructure(): No body information available in a.php

[queences dot sam at tallysolutions dot com]

From: queences dot sam at tallysolutions dot com
Operating system: linux
PHP version:  5.2.0
PHP Bug Type: IMAP related
Bug description:  PHP Warning:  imap_fetchstructure(): No body information 
available in a.php

Description:

While tring to process mails from the mailbox using imap function at times
we encounter this error. But the mail number etc everything that it picks
up is correct. Below given line is the exact error that we get:

PHP Warning:  imap_fetchstructure(): No body information available in
/var/www/html/tallyweb/modules/forums/intranet/CRecvMailProcessMgr.php on
line 1044


We have noticed that the error goes of once we restart the services -
sendmail, httpd & mysql.

Please let us know if this is already a noted bug in PHP imap library.
When is it going to be resolved.

Queences


-- 
Edit bug report at http://bugs.php.net/?id=39375&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39375&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39375&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39375&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39375&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39375&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39375&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39375&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39375&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39375&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39375&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39375&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39375&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39375&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39375&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39375&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39375&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39375&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39375&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39375&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39375&r=mysqlcfg

#39374 [NEW]: it add greater-than sign all page

[phunsanit at Hotmail dot com]

From: phunsanit at Hotmail dot com
Operating system: win-xp
PHP version:  5.2.0
PHP Bug Type: Output Control
Bug description:  it add greater-than sign all page

Description:

# Apache 2.2.3
# PHP 5.1.6
# MySQL 5.0.24a

it add greater-than sign all page


-- 
Edit bug report at http://bugs.php.net/?id=39374&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39374&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39374&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39374&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39374&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39374&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39374&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39374&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39374&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39374&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39374&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39374&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39374&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39374&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39374&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39374&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39374&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39374&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39374&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39374&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39374&r=mysqlcfg

#39372 [Opn->Sus]: Incompatibility in the PHP API.

[rasmus]

 ID:   39372
 Updated by:   [EMAIL PROTECTED]
 Reported By:  cm at cmunt dot demon dot co dot uk
-Status:   Open
+Status:   Suspended
 Bug Type: *Compile Issues
 Operating System: All
 PHP Version:  5.2.0
 New Comment:

We take these breaks extremely seriously and go out of our way to not
break BC.  We never break BC in a sub-release (the z part of x.y.z) and
if you look at the frequency of the other releases you will find that
there is actually quite a while between BC breaks.

Of course, if you download intermediate versions from CVS during
development, you will be hit more often.  But the actual recent bumps
have been:

For the 4.x branch:

4.3.0  Dec.27, 2002
4.4.0  Jul 11, 2005

In the 4.3 to 4.4 case, the change was minor, but necessary.  Most
extensions weren't actually affected, but it was still a change, and we
didn't want to hide it.

For the 5.x branch:

5.0.0  Jul 13, 2004
5.1.0  Nov 24, 2005
5.2.0  Nov  2, 2006

Each of these have also been quite necessary in order to improve a
number of areas in the API.  It's nice to say this can be solved by API
abstraction, but that means getting the API perfect up front.



Previous Comments:


[2006-11-04 09:49:59] cm at cmunt dot demon dot co dot uk

Description:

You will probably not regard this issue as bug and it is something that
you are no doubt already aware of but it is a problem that, in our
experience, causes no end of confusion and frustration among many users
of PHP.

The issue is this:  pretty much every new release of PHP (including a
significant number of minor upgrades) requires that all third party
extension modules be rebuilt from source.  There doesn’t appear to be
any technical reason why this should be the case – after all, I’ve yet
to see a situation where module code has to be changed on upgrade.

This is a huge nuisance – particularly since many PHP systems these
days are either pre-installed in binary form or tend to be distributed
as pre-built kits (e.g. Windows).

The requirement to rebuild could be removed by abstracting the data
structures used in the PHP API to a higher level – in much the same was
as Microsoft has done with ISAPI extensions to IIS.

Incidentally, I seem to remember the PHP community being up in arms in
the early days of Apache v2 when every minor upgrade (2.0.x) required
third party Apache modules to be rebuilt – i.e. the PHP DSO.  In the
end the Apache Group capitulated and properly abstracted the API such
that a rebuild would only be necessary between _major_ upgrades.  This
brings me to another problem with PHP:  there seems to be no way of
telling in advance whether or not third party modules will need
rebuilding.  Sometimes a minor upgrade will require a module rebuild;
sometimes not.

A little more effort and/or rationalization in this area would be much
appreciated !







-- 
Edit this bug report at http://bugs.php.net/?id=39372&edit=1

#39373 [Opn->Bgs]: strftime does not output %D (%m/%d/%y)

[derick]

 ID:   39373
 Updated by:   [EMAIL PROTECTED]
 Reported By:  djhobson at bigpond dot net dot au
-Status:   Open
+Status:   Bogus
-Bug Type: Output Control
+Bug Type: Date/time related
 Operating System: Win XP SP 2 - Latest Patches
 PHP Version:  5.2.0
 New Comment:

Please read the 2nd paragraph of:
http://no2.php.net/strftime


Previous Comments:


[2006-11-04 10:12:55] djhobson at bigpond dot net dot au

Description:

strftime() is failing to output the designated results as given to the
specified online PHP documents.

Reproduce code:
---
Script Name:-
gettime.php

Script contents:-



Output:-

Y:\>php gettime.php


Y:\>

PS: I see there is already a post in regards to %T output, but %D is
the same!

Expected result:

Expected results from online & current downloadable documentation is
that from the given code I should see something like:-

%D - same as %m/%d/%y 

%T - current time, equal to %H:%M:%S 

Simply, NOT HAPPENING MAN!






-- 
Edit this bug report at http://bugs.php.net/?id=39373&edit=1

#39369 [Opn->Bgs]: PHP 5.2.0 will not compiled with MySQL support

[derick]

 ID:   39369
 Updated by:   [EMAIL PROTECTED]
 Reported By:  nathan at officelink dot net dot au
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: FreeBSD 6.1-RELEASE-p10
 PHP Version:  5.2.0
 New Comment:

Ok, not a bug then... but make *really* sure you want the problems of a
threaded apache. I suggest to pick the worker mpm.


Previous Comments:


[2006-11-04 10:09:24] nathan at officelink dot net dot au

Thanks Rasmus, that has fixed my problem.

I'm confused as to why this worked under versions earlier of PHP but I
now understand what was wrong. I have now compiled MySQL with
--enable-thread-safe-client.

Thanks again,

Nathan



[2006-11-04 09:38:22] [EMAIL PROTECTED]

Ok, and do you have libmysqlclient_r installed?  You need the
threadsafe version of that library or you need to use the prefork mpm
with Apache.



[2006-11-04 09:24:31] nathan at officelink dot net dot au

Yes, here is my Apache configure line:

./configure --prefix=/usr/local/apache --enable-module=so
--with-mpm=worker --enable-ssl --enable-deflate --enable-cern-meta
--enable-expires --enable-headers --enable-vhost-alias --enable-rewrite
--enable-access --enable-auth --enable-include --enable-log_config
--enable-env --enable-setenvif --enable-http --enable-mime
--enable-status --enable-autoindex --enable-asis --enable-cgi
--enable-negotiation --enable-dir --enable-actions --enable-userdir
--enable-alias -enable-mem-cache --enable-cache --enable-headers
--enable-deflate



[2006-11-04 09:19:38] [EMAIL PROTECTED]

Are you using a threaded mpm in Apache2?  It is looking for the
threadsafe mysqlclient library as a result.



[2006-11-04 04:57:05] nathan at officelink dot net dot au

Description:

Unable to get PHP 5.2.0 to compile with MySQL support. PHP versions
prior to this work perfectly with an identical ./configure line.



Reproduce code:
---
./configure --with-apxs2=/usr/local/apache/bin/apxs  --enable-ftp 
--enable-magic-quotes  --enable-track-vars  --enable-sockets 
--with-gettext  --with-gd  --with-zlib-dir=/usr/local 
--with-freetype-dir=/usr/local  --enable-soap 
--with-mysqli=/usr/local/mysql/bin/mysql_config  --with-xmlrpc 
--with-imap=/usr/local/src/imap-2004g  --enable-mbstring=all 
--with-mime-magic=/usr/share/misc/magic.mime  --with-mcrypt 
--with-iconv  --enable-mbregex  --enable-mime-magic 
--with-openssl=/usr/local/ssl  --with-imap-ssl 
--with-mysql=/usr/local/mysql

on PHP 5.2.0 I get:

checking for MySQL support... yes
checking for specified location of the MySQL UNIX socket... no
checking for MySQL UNIX socket location... no
configure: error: Cannot find libmysqlclient_r under /usr/local/mysql.
Note that the MySQL client library is not bundled anymore!

MySQL version is 

mysql  Ver 14.12 Distrib 5.0.27, for unknown-freebsd6.1 (i386) using 
EditLine wrapper

compiled from source with

./configure --prefix=/usr/local/mysql --without-debug



Expected result:

on PHP 5.1.6 I get:

checking for MySQL support... yes
checking for specified location of the MySQL UNIX socket... no
checking for MySQL UNIX socket location... no
checking for mysql_close in -lmysqlclient... yes
checking for MySQLi support... yes
checking whether to enable embedded MySQLi support... no
checking for mysql_set_server_option in -lmysqlclient... yes
checking for mysql_stmt_field_count in -lmysqlclient... yes






-- 
Edit this bug report at http://bugs.php.net/?id=39369&edit=1

#39371 [Opn->Bgs]: PHP 5.2.0 and Zend Problem

[derick]

 ID:   39371
 Updated by:   [EMAIL PROTECTED]
 Reported By:  lawatia_mhm at yahoo dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: CentOS 4.4
 PHP Version:  5.2.0
 New Comment:

Do not file bugs when you have Zend extensions (zend_extension=)
loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache,
APC, Xdebug and ionCube loader.  These extensions often modify engine
behavior which is not related to PHP itself.

"Zend 3.0.2" has nothing to do with Zend engine that is in PHP, it's a
product (with a different name I presume) of Zend. Please file a
bugreport with them.


Previous Comments:


[2006-11-04 09:40:01] lawatia_mhm at yahoo dot com

Description:

Hello dear ..
I just upgraded php from 5.1.6 CGI to 5.2.0 CGI but I got problem with
Zend 3.0.2 ...

The problem is :
After finishing installing 5.2.0 when I type :
php -v

it shows :
Zend Engine 2.2.0

Then I installed manually Zend 3.0.2 .. 

And still shows 2.2.0 so the site that encrypt the config.php of
vBulleting ..

Is not working !!






-- 
Edit this bug report at http://bugs.php.net/?id=39371&edit=1

#39373 [NEW]: strftime does not output %D (%m/%d/%y)

[djhobson at bigpond dot net dot au]

From: djhobson at bigpond dot net dot au
Operating system: Win XP SP 2 - Latest Patches
PHP version:  5.2.0
PHP Bug Type: Output Control
Bug description:  strftime does not output %D (%m/%d/%y)

Description:

strftime() is failing to output the designated results as given to the
specified online PHP documents.

Reproduce code:
---
Script Name:-
gettime.php

Script contents:-



Output:-

Y:\>php gettime.php


Y:\>

PS: I see there is already a post in regards to %T output, but %D is the
same!

Expected result:

Expected results from online & current downloadable documentation is that
from the given code I should see something like:-

%D - same as %m/%d/%y 

%T - current time, equal to %H:%M:%S 

Simply, NOT HAPPENING MAN!


-- 
Edit bug report at http://bugs.php.net/?id=39373&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39373&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39373&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39373&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39373&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39373&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39373&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39373&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39373&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39373&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39373&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39373&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39373&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39373&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39373&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39373&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39373&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39373&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39373&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39373&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39373&r=mysqlcfg

#39369 [Opn]: PHP 5.2.0 will not compiled with MySQL support

[nathan at officelink dot net dot au]

 ID:   39369
 User updated by:  nathan at officelink dot net dot au
 Reported By:  nathan at officelink dot net dot au
 Status:   Open
 Bug Type: Compile Failure
 Operating System: FreeBSD 6.1-RELEASE-p10
 PHP Version:  5.2.0
 New Comment:

Thanks Rasmus, that has fixed my problem.

I'm confused as to why this worked under versions earlier of PHP but I
now understand what was wrong. I have now compiled MySQL with
--enable-thread-safe-client.

Thanks again,

Nathan


Previous Comments:


[2006-11-04 09:38:22] [EMAIL PROTECTED]

Ok, and do you have libmysqlclient_r installed?  You need the
threadsafe version of that library or you need to use the prefork mpm
with Apache.



[2006-11-04 09:24:31] nathan at officelink dot net dot au

Yes, here is my Apache configure line:

./configure --prefix=/usr/local/apache --enable-module=so
--with-mpm=worker --enable-ssl --enable-deflate --enable-cern-meta
--enable-expires --enable-headers --enable-vhost-alias --enable-rewrite
--enable-access --enable-auth --enable-include --enable-log_config
--enable-env --enable-setenvif --enable-http --enable-mime
--enable-status --enable-autoindex --enable-asis --enable-cgi
--enable-negotiation --enable-dir --enable-actions --enable-userdir
--enable-alias -enable-mem-cache --enable-cache --enable-headers
--enable-deflate



[2006-11-04 09:19:38] [EMAIL PROTECTED]

Are you using a threaded mpm in Apache2?  It is looking for the
threadsafe mysqlclient library as a result.



[2006-11-04 04:57:05] nathan at officelink dot net dot au

Description:

Unable to get PHP 5.2.0 to compile with MySQL support. PHP versions
prior to this work perfectly with an identical ./configure line.



Reproduce code:
---
./configure --with-apxs2=/usr/local/apache/bin/apxs  --enable-ftp 
--enable-magic-quotes  --enable-track-vars  --enable-sockets 
--with-gettext  --with-gd  --with-zlib-dir=/usr/local 
--with-freetype-dir=/usr/local  --enable-soap 
--with-mysqli=/usr/local/mysql/bin/mysql_config  --with-xmlrpc 
--with-imap=/usr/local/src/imap-2004g  --enable-mbstring=all 
--with-mime-magic=/usr/share/misc/magic.mime  --with-mcrypt 
--with-iconv  --enable-mbregex  --enable-mime-magic 
--with-openssl=/usr/local/ssl  --with-imap-ssl 
--with-mysql=/usr/local/mysql

on PHP 5.2.0 I get:

checking for MySQL support... yes
checking for specified location of the MySQL UNIX socket... no
checking for MySQL UNIX socket location... no
configure: error: Cannot find libmysqlclient_r under /usr/local/mysql.
Note that the MySQL client library is not bundled anymore!

MySQL version is 

mysql  Ver 14.12 Distrib 5.0.27, for unknown-freebsd6.1 (i386) using 
EditLine wrapper

compiled from source with

./configure --prefix=/usr/local/mysql --without-debug



Expected result:

on PHP 5.1.6 I get:

checking for MySQL support... yes
checking for specified location of the MySQL UNIX socket... no
checking for MySQL UNIX socket location... no
checking for mysql_close in -lmysqlclient... yes
checking for MySQLi support... yes
checking whether to enable embedded MySQLi support... no
checking for mysql_set_server_option in -lmysqlclient... yes
checking for mysql_stmt_field_count in -lmysqlclient... yes






-- 
Edit this bug report at http://bugs.php.net/?id=39369&edit=1

#39372 [NEW]: Incompatibility in the PHP API.

[cm at cmunt dot demon dot co dot uk]

From: cm at cmunt dot demon dot co dot uk
Operating system: All
PHP version:  5.2.0
PHP Bug Type: *Compile Issues
Bug description:  Incompatibility in the PHP API.

Description:

You will probably not regard this issue as bug and it is something that
you are no doubt already aware of but it is a problem that, in our
experience, causes no end of confusion and frustration among many users of
PHP.

The issue is this:  pretty much every new release of PHP (including a
significant number of minor upgrades) requires that all third party
extension modules be rebuilt from source.  There doesn’t appear to be any
technical reason why this should be the case – after all, I’ve yet to see
a situation where module code has to be changed on upgrade.

This is a huge nuisance – particularly since many PHP systems these days
are either pre-installed in binary form or tend to be distributed as
pre-built kits (e.g. Windows).

The requirement to rebuild could be removed by abstracting the data
structures used in the PHP API to a higher level – in much the same was as
Microsoft has done with ISAPI extensions to IIS.

Incidentally, I seem to remember the PHP community being up in arms in the
early days of Apache v2 when every minor upgrade (2.0.x) required third
party Apache modules to be rebuilt – i.e. the PHP DSO.  In the end the
Apache Group capitulated and properly abstracted the API such that a
rebuild would only be necessary between _major_ upgrades.  This brings me
to another problem with PHP:  there seems to be no way of telling in
advance whether or not third party modules will need rebuilding. 
Sometimes a minor upgrade will require a module rebuild; sometimes not.

A little more effort and/or rationalization in this area would be much
appreciated !



-- 
Edit bug report at http://bugs.php.net/?id=39372&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39372&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39372&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39372&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39372&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39372&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39372&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39372&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39372&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39372&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39372&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39372&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39372&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39372&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39372&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39372&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39372&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39372&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39372&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39372&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39372&r=mysqlcfg

#39371 [NEW]: PHP 5.2.0 and Zend Problem

[lawatia_mhm at yahoo dot com]

From: lawatia_mhm at yahoo dot com
Operating system: CentOS 4.4
PHP version:  5.2.0
PHP Bug Type: Unknown/Other Function
Bug description:  PHP 5.2.0 and Zend Problem

Description:

Hello dear ..
I just upgraded php from 5.1.6 CGI to 5.2.0 CGI but I got problem with
Zend 3.0.2 ...

The problem is :
After finishing installing 5.2.0 when I type :
php -v

it shows :
Zend Engine 2.2.0

Then I installed manually Zend 3.0.2 .. 

And still shows 2.2.0 so the site that encrypt the config.php of
vBulleting ..

Is not working !!


-- 
Edit bug report at http://bugs.php.net/?id=39371&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39371&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39371&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39371&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39371&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39371&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39371&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39371&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39371&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39371&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39371&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39371&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39371&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39371&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39371&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39371&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39371&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39371&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39371&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39371&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39371&r=mysqlcfg

#39369 [Opn]: PHP 5.2.0 will not compiled with MySQL support

[rasmus]

 ID:   39369
 Updated by:   [EMAIL PROTECTED]
 Reported By:  nathan at officelink dot net dot au
 Status:   Open
 Bug Type: Compile Failure
 Operating System: FreeBSD 6.1-RELEASE-p10
 PHP Version:  5.2.0
 New Comment:

Ok, and do you have libmysqlclient_r installed?  You need the
threadsafe version of that library or you need to use the prefork mpm
with Apache.


Previous Comments:


[2006-11-04 09:24:31] nathan at officelink dot net dot au

Yes, here is my Apache configure line:

./configure --prefix=/usr/local/apache --enable-module=so
--with-mpm=worker --enable-ssl --enable-deflate --enable-cern-meta
--enable-expires --enable-headers --enable-vhost-alias --enable-rewrite
--enable-access --enable-auth --enable-include --enable-log_config
--enable-env --enable-setenvif --enable-http --enable-mime
--enable-status --enable-autoindex --enable-asis --enable-cgi
--enable-negotiation --enable-dir --enable-actions --enable-userdir
--enable-alias -enable-mem-cache --enable-cache --enable-headers
--enable-deflate



[2006-11-04 09:19:38] [EMAIL PROTECTED]

Are you using a threaded mpm in Apache2?  It is looking for the
threadsafe mysqlclient library as a result.



[2006-11-04 04:57:05] nathan at officelink dot net dot au

Description:

Unable to get PHP 5.2.0 to compile with MySQL support. PHP versions
prior to this work perfectly with an identical ./configure line.



Reproduce code:
---
./configure --with-apxs2=/usr/local/apache/bin/apxs  --enable-ftp 
--enable-magic-quotes  --enable-track-vars  --enable-sockets 
--with-gettext  --with-gd  --with-zlib-dir=/usr/local 
--with-freetype-dir=/usr/local  --enable-soap 
--with-mysqli=/usr/local/mysql/bin/mysql_config  --with-xmlrpc 
--with-imap=/usr/local/src/imap-2004g  --enable-mbstring=all 
--with-mime-magic=/usr/share/misc/magic.mime  --with-mcrypt 
--with-iconv  --enable-mbregex  --enable-mime-magic 
--with-openssl=/usr/local/ssl  --with-imap-ssl 
--with-mysql=/usr/local/mysql

on PHP 5.2.0 I get:

checking for MySQL support... yes
checking for specified location of the MySQL UNIX socket... no
checking for MySQL UNIX socket location... no
configure: error: Cannot find libmysqlclient_r under /usr/local/mysql.
Note that the MySQL client library is not bundled anymore!

MySQL version is 

mysql  Ver 14.12 Distrib 5.0.27, for unknown-freebsd6.1 (i386) using 
EditLine wrapper

compiled from source with

./configure --prefix=/usr/local/mysql --without-debug



Expected result:

on PHP 5.1.6 I get:

checking for MySQL support... yes
checking for specified location of the MySQL UNIX socket... no
checking for MySQL UNIX socket location... no
checking for mysql_close in -lmysqlclient... yes
checking for MySQLi support... yes
checking whether to enable embedded MySQLi support... no
checking for mysql_set_server_option in -lmysqlclient... yes
checking for mysql_stmt_field_count in -lmysqlclient... yes






-- 
Edit this bug report at http://bugs.php.net/?id=39369&edit=1

#39369 [Fbk->Opn]: PHP 5.2.0 will not compiled with MySQL support

[nathan at officelink dot net dot au]

 ID:   39369
 User updated by:  nathan at officelink dot net dot au
 Reported By:  nathan at officelink dot net dot au
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: FreeBSD 6.1-RELEASE-p10
 PHP Version:  5.2.0
 New Comment:

Yes, here is my Apache configure line:

./configure --prefix=/usr/local/apache --enable-module=so
--with-mpm=worker --enable-ssl --enable-deflate --enable-cern-meta
--enable-expires --enable-headers --enable-vhost-alias --enable-rewrite
--enable-access --enable-auth --enable-include --enable-log_config
--enable-env --enable-setenvif --enable-http --enable-mime
--enable-status --enable-autoindex --enable-asis --enable-cgi
--enable-negotiation --enable-dir --enable-actions --enable-userdir
--enable-alias -enable-mem-cache --enable-cache --enable-headers
--enable-deflate


Previous Comments:


[2006-11-04 09:19:38] [EMAIL PROTECTED]

Are you using a threaded mpm in Apache2?  It is looking for the
threadsafe mysqlclient library as a result.



[2006-11-04 04:57:05] nathan at officelink dot net dot au

Description:

Unable to get PHP 5.2.0 to compile with MySQL support. PHP versions
prior to this work perfectly with an identical ./configure line.



Reproduce code:
---
./configure --with-apxs2=/usr/local/apache/bin/apxs  --enable-ftp 
--enable-magic-quotes  --enable-track-vars  --enable-sockets 
--with-gettext  --with-gd  --with-zlib-dir=/usr/local 
--with-freetype-dir=/usr/local  --enable-soap 
--with-mysqli=/usr/local/mysql/bin/mysql_config  --with-xmlrpc 
--with-imap=/usr/local/src/imap-2004g  --enable-mbstring=all 
--with-mime-magic=/usr/share/misc/magic.mime  --with-mcrypt 
--with-iconv  --enable-mbregex  --enable-mime-magic 
--with-openssl=/usr/local/ssl  --with-imap-ssl 
--with-mysql=/usr/local/mysql

on PHP 5.2.0 I get:

checking for MySQL support... yes
checking for specified location of the MySQL UNIX socket... no
checking for MySQL UNIX socket location... no
configure: error: Cannot find libmysqlclient_r under /usr/local/mysql.
Note that the MySQL client library is not bundled anymore!

MySQL version is 

mysql  Ver 14.12 Distrib 5.0.27, for unknown-freebsd6.1 (i386) using 
EditLine wrapper

compiled from source with

./configure --prefix=/usr/local/mysql --without-debug



Expected result:

on PHP 5.1.6 I get:

checking for MySQL support... yes
checking for specified location of the MySQL UNIX socket... no
checking for MySQL UNIX socket location... no
checking for mysql_close in -lmysqlclient... yes
checking for MySQLi support... yes
checking whether to enable embedded MySQLi support... no
checking for mysql_set_server_option in -lmysqlclient... yes
checking for mysql_stmt_field_count in -lmysqlclient... yes






-- 
Edit this bug report at http://bugs.php.net/?id=39369&edit=1

#39369 [Opn->Fbk]: PHP 5.2.0 will not compiled with MySQL support

[rasmus]

 ID:   39369
 Updated by:   [EMAIL PROTECTED]
 Reported By:  nathan at officelink dot net dot au
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: FreeBSD 6.1-RELEASE-p10
 PHP Version:  5.2.0
 New Comment:

Are you using a threaded mpm in Apache2?  It is looking for the
threadsafe mysqlclient library as a result.


Previous Comments:


[2006-11-04 04:57:05] nathan at officelink dot net dot au

Description:

Unable to get PHP 5.2.0 to compile with MySQL support. PHP versions
prior to this work perfectly with an identical ./configure line.



Reproduce code:
---
./configure --with-apxs2=/usr/local/apache/bin/apxs  --enable-ftp 
--enable-magic-quotes  --enable-track-vars  --enable-sockets 
--with-gettext  --with-gd  --with-zlib-dir=/usr/local 
--with-freetype-dir=/usr/local  --enable-soap 
--with-mysqli=/usr/local/mysql/bin/mysql_config  --with-xmlrpc 
--with-imap=/usr/local/src/imap-2004g  --enable-mbstring=all 
--with-mime-magic=/usr/share/misc/magic.mime  --with-mcrypt 
--with-iconv  --enable-mbregex  --enable-mime-magic 
--with-openssl=/usr/local/ssl  --with-imap-ssl 
--with-mysql=/usr/local/mysql

on PHP 5.2.0 I get:

checking for MySQL support... yes
checking for specified location of the MySQL UNIX socket... no
checking for MySQL UNIX socket location... no
configure: error: Cannot find libmysqlclient_r under /usr/local/mysql.
Note that the MySQL client library is not bundled anymore!

MySQL version is 

mysql  Ver 14.12 Distrib 5.0.27, for unknown-freebsd6.1 (i386) using 
EditLine wrapper

compiled from source with

./configure --prefix=/usr/local/mysql --without-debug



Expected result:

on PHP 5.1.6 I get:

checking for MySQL support... yes
checking for specified location of the MySQL UNIX socket... no
checking for MySQL UNIX socket location... no
checking for mysql_close in -lmysqlclient... yes
checking for MySQLi support... yes
checking whether to enable embedded MySQLi support... no
checking for mysql_set_server_option in -lmysqlclient... yes
checking for mysql_stmt_field_count in -lmysqlclient... yes






-- 
Edit this bug report at http://bugs.php.net/?id=39369&edit=1

#39365 [Opn->Bgs]: getElementsByTagNameNS() does not return elements in a default namespace

[chregu]

 ID:   39365
 Updated by:   [EMAIL PROTECTED]
 Reported By:  z_rules55 at hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: DOM XML related
 Operating System: WinXP Professional
 PHP Version:  5.2.0
 New Comment:

$xml->createElement('element', 'default_ns_element')

That's not in the default namespace, that's in no namespace at 
all this way.

Can't work this way


Previous Comments:


[2006-11-03 21:28:54] z_rules55 at hotmail dot com

Additional note: getElementsByTagName('element') does, in fact, find
both nodes.



[2006-11-03 21:12:54] z_rules55 at hotmail dot com

Description:

Calling getElementsByTagNameNS() on a DOMDocument or a DOMElement does
not return elements that are under a default namespace. The example
below finds $explicit_ns_element, but not $default_ns_element.

Reproduce code:
---
appendChild($xml->createElementNS($namespace, 'root'));
$default_ns_element = $root->appendChild($xml->createElement('element',
'default_ns_element'));
$explicit_ns_element =
$root->appendChild($xml->createElementNS($namespace, 'element',
'explicit_ns_element'));
foreach($xml->getElementsByTagNameNS($namespace, 'element') as $el) {
echo $el->nodeValue."\n";
}
echo "\n";
foreach($root->getElementsByTagNameNS($namespace, 'element') as $el) {
echo $el->nodeValue."\n";
}
?>

Expected result:

default_ns_element
explicit_ns_element

default_ns_element
explicit_ns_element

Actual result:
--
explicit_ns_element

explicit_ns_element





-- 
Edit this bug report at http://bugs.php.net/?id=39365&edit=1