#38894 [Opn]: A solution

[m dot karoly at martondesign dot com]

 ID:   38894
 User updated by:  m dot karoly at martondesign dot com
-Summary:  Can't fetch data(PHP+Birdstep RDM server across ODBC)
 Reported By:  m dot karoly at martondesign dot com
 Status:   Open
 Bug Type: ODBC related
 Operating System: winxpprof
 PHP Version:  5.1.6
 New Comment:

With PDO extension i can fetch the right data!
odbc functions not working yet.


Previous Comments:


[2006-09-20 08:59:53] m dot karoly at martondesign dot com

Description:

The code i commented well, see below.

Short description:
When i try to make a SELECT, and get the rows, the odbc_fetch_rows,
odbc_fetch_array, odbc_result_all returns FALSE.
The connection works, the schema, table, columnnames i can receive in
php.

Platforms i tested:
Php 4.4.4 + Velocis (2.1) = Everythings work
Php 5.1.6 + Velocis (2.1) = Not working
Php 4.4.4 + Birdstep (6.0) = Not working
Php 5.1.6 + Birdstep (6.0) = Not working
Php 5.2.x-dev + Birdstep (6.0) = Not working

Reproduce code:
---
".odbc_result($result,"TABLE_SCHEM").'.'.odbc_result($result,"TABLE_NAME").".".odbc_result($result,"COLUMN_NAME");
}

$odbc_result = odbc_exec($conn, "SELECT * FROM schema.table"); // When
i make a query, it seems to be ok too. (returns with a resource id)

odbc_result_all($odbc_result); // but -as i mentioned above - if i
fetch the result of an odbc_exec (or odbc_do) query, it returns with
FALSE
// doesn't matter what fetch function i call, none of them returns data
(odbc_fetch_array, odbc_fetch_row, odbc_result_all...)

?>

Expected result:

odbc_fetch_array: returns array
odbc_fetch_row: returns string
odbc_result_all: returns html table


Actual result:
--
odbc_fetch_array: returns false
odbc_fetch_row: returns false
odbc_result_all: returns false





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

#39424 [NEW]: Function Arguments

[mojtaba2005sh at gmail dot com]

From: mojtaba2005sh at gmail dot com
Operating system: Windows and Linux
PHP version:  5.2.0
PHP Bug Type: Class/Object related
Bug description:  Function Arguments

Description:

When I want to set a default value for a funcion and set the default value
with for example 'rand(1,100)' or a class variable like '$this->m' it gives
a syntax error
this was the error:
syntax error, unexpected '(', expecting ')' 

Reproduce code:
---



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

#39423 [NEW]: fread expired

[base5 at 126 dot com]

From: base5 at 126 dot com
Operating system: windows xp
PHP version:  5.2.0
PHP Bug Type: Filesystem function related
Bug description:  fread expired

Description:

I used fgets/fread to read information from a pipe.
then,I wait and wait , and wait .

env: 
windows xp
php 5.2


Reproduce code:
---
$handle = popen('cmd.exe 2>&1', 'r');
do {
$data = fgets($handle, 100);
if (strlen($data) == 0) {
break;
}
$contents .= $data;
}while(true);

echo $contents;
pclose($handle);



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

#39422 [NEW]: Time shifts randomly between GMT and PST

[daemonist at guildmail dot sojurn dot org]

From: daemonist at guildmail dot sojurn dot org
Operating system: Windows 2003 Server
PHP version:  4CVS-2006-11-08 (CVS)
PHP Bug Type: Date/time related
Bug description:  Time shifts randomly between GMT and PST

Description:

Using Windows 2003 Server, PHP 4.4 (latest CVS as of 2006-11-08) with SMF
forums software.

The server date and time are set correctly, and viewing them at the
console confirm that.  Sometimes the forums will report the correct time
and date, and sometimes the forums will "switch" to the GMT (since the
server is in PST, that means +8 hours from the server time).

If I use a simple PHP script to query the date and time, I get the wrong
information (so that removes the forums as the cause of this).

If I stop and start IIS, then PHP seems to provide the correct
information.  Eventually, however, it will revert back to the erroneous
date and time.

I have posted the script code that I used to confirm that PHP is reporting
the date and time.

Reproduce code:
---
', strftime('%B %d, %Y, %I:%M %p');
?>



Expected result:

November 7, 2006, 10:35 pm
November 07, 2006, 10:35 PM

Actual result:
--
November 8, 2006, 6:35 am
November 08, 2006, 06:35 AM

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

#39421 [NEW]: tempnam() unexpected behavior

[ruslan_y at list dot ru]

From: ruslan_y at list dot ru
Operating system: Windows XP SP2
PHP version:  5.2.0
PHP Bug Type: *Directory/Filesystem functions
Bug description:  tempnam() unexpected behavior 

Description:

After the upgrade from old php 4.x to 5.2.0. Some of my web scripts stop
working. One of the reason is the changes in tempnam() behavior which stop
working with local path like "./dir" or "dir/" and force me to add system
temporary folder to open_basedir path.

Configuration: 
Windows XP SP2 | PHP 5.2.0 | Apache 2.0.55 (+ php5apache2.dll)

P.S. php.exe works as expected (except DOCUMENT_ROOT is null) 
(php.exe -q 1.php)

Reproduce code:
---
'."\n";
echo 'DOCUMENT_ROOT = '.$_SERVER['DOCUMENT_ROOT']."\n";
echo '$tmpfname1 = '.$tmpfname1."\n";
echo '$tmpfname2 = '.$tmpfname2."\n";
echo '$tmpfname3 = '.$tmpfname3."\n";
echo '$tmpfname4 = '.$tmpfname4."\n";
echo '$tmpfname5 = '.$tmpfname5."\n";
echo ''."\n";
?>

Expected result:

A new directory "2" and five files in it.

DOCUMENT_ROOT = C:/root/www/host2/www
$tmpfname1 = 2/FOOFA.tmp
$tmpfname2 = ./2/FOOFB.tmp
$tmpfname3 = 2\FOOFC.tmp
$tmpfname4 = .\2\FOOFD.tmp
$tmpfname5 = C:\root\www\host2\www\2\FOOFE.tmp

Actual result:
--
A new directory "2" and only one file in it. all other files in the
windows temp folder.

DOCUMENT_ROOT = C:/root/www/host2/www
$tmpfname1 = C:\WINDOWS\TEMP\FOO10A.tmp
$tmpfname2 = C:\WINDOWS\TEMP\FOO10B.tmp
$tmpfname3 = C:\WINDOWS\TEMP\FOO10C.tmp
$tmpfname4 = C:\WINDOWS\TEMP\FOO10D.tmp
$tmpfname5 = C:\root\www\host2\www\2\FOO10E.tmp

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

#39370 [Opn]: $_GET no longer works under FastCGI but works under CGI.

[trustpunk at gmail dot com]

 ID:   39370
 User updated by:  trustpunk at gmail dot com
 Reported By:  trustpunk at gmail dot com
 Status:   Open
 Bug Type: CGI related
 Operating System: Windows
 PHP Version:  6CVS-2006-11-04 (snap)
 New Comment:

BUMP! Has anyone even checked into this yet?


Previous Comments:


[2006-11-04 07:53:30] trustpunk at gmail dot com

Description:

The special $_GET variable no longer works under FastCGI. I'm
not sure if the others fail. $_SERVER seems to work.

Reproduce code:
---
PHP/6.0.0-DEV

Code:





URL: http://localhost/test.php?get=Hello


Expected result:

I expect to see some elements in the $_GET array after sending
a GET request from the URL.

Actual result:
--
I get nothing in the $_GET array after using a request like:

http://localhost/test.php?get=Hello

Note: Remember that CGI/1.1 is npot effected by this bug from
what I've tested.





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

#39420 [NEW]: setlocale fail to set china or japan

[liber at iproom dot com]

From: liber at iproom dot com
Operating system: windows 2000
PHP version:  5.2.0
PHP Bug Type: Strings related
Bug description:  setlocale fail to set china or japan

Description:

Can not setlocale to china or japan successful in Windows 2000 only.

Reproduce code:
---
$a = Array("ja", "jpn", "ja_JP", "Japanese_Japan", "japanese",
"Japanese");
//$a = array("ja_ja", "ja_jp", "jp_ja", "jp_jp");
foreach($a as $locale) {
if(setlocale(LC_ALL, $locale) !== false) {
echo "$locale is ok\n";
} else {
echo "$locale is bad\n";
}
}


Expected result:

ja is ok

Actual result:
--
ja is bad
jpn is bad
ja_JP is bad
Japanese_Japan is bad
japanese is bad
Japanese is bad

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

#39419 [NEW]: in CLI mode, echo isn't workint correctly

[prophet75 at gmail dot com]

From: prophet75 at gmail dot com
Operating system: Linux 2.6.9-22.ELsmp
PHP version:  5.2.0
PHP Bug Type: CGI related
Bug description:  in CLI mode, echo isn't workint correctly

Description:

in CLI mode, It is no output without over than 1024 byte character or new
line character.

Reproduce code:
---
in test.php


% php test.php

Expected result:

test

Actual result:
--
No output

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

#39417 [Opn->Bgs]: Tidy: Handling of 'new-blocklevel-tags' inconsistent

[iliaa]

 ID:   39417
 Updated by:   [EMAIL PROTECTED]
 Reported By:  konstantin dot ryabitsev at mcgill dot ca
-Status:   Open
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: Linux
 PHP Version:  5.1.6
 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.

This is a libtidy bug.


Previous Comments:


[2006-11-07 22:22:59] konstantin dot ryabitsev at mcgill dot ca

Specifying "Tidy:" in the Summary.



[2006-11-07 22:19:03] konstantin dot ryabitsev at mcgill dot ca

Description:

I seem to get odd behaviour running the following code. Theoretically
(and confirmed by running command-line tidy utility), the output should
contain all namespace-prepended tags. On my machine, the output only
contains the  element, and none of the elements contained
within.

It's really weird. If I change the names to "wps:blo", "wps:var" and
"wps:val", it works. I'm really confused at this point.

Reproduce code:
---

 
   
 
';
$config = array(
'new-blocklevel-tags' => 'wps:block,wps:var,wps:value'
);
$tidy = tidy_parse_string($contents, $config, 'utf8');
$tidy->cleanRepair();
print "{$tidy->value}\n";
?>

Expected result:














Actual result:
--














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

#39410 [NEW]: Installation on CGI mode fails

[gschizas at gmail dot com]

From: gschizas at gmail dot com
Operating system: Windows 2003
PHP version:  5.2.0
PHP Bug Type: IIS related
Bug description:  Installation on CGI mode fails

Description:

While installing (with the installer) in CGI Mode (Windows 2003 SP1,
IIS6), I get an error message at the end of the installation (There is a
problem with this Windows Installer Package)

Reproduce code:
---
Event Viewer shows this:

Product: PHP 5.2.0 -- Error 1721. There is a problem with this Windows
Installer package. A program required for this install to complete could
not be run. Contact your support personnel or package vendor. Action:
iisextVBS, location: C:\Program Files\PHP\, command:
"C:\WINDOWS\system32\iisext.vbs" /AddFile "C:\Program
Files\PHP\php-cgi.exe" 


I found this again as Bug #26185, for PHP 4.2.1, but obviously it reared
its ugly head again (#26185 is closed, but the behavior persists).

Expected result:

Installation not producing any error messages, and registering PHP in "Web
Service Extensions"

Actually this is probably a problem with the fact iisext.vbs requires more
parameters in Windows 2003. So instead of
"C:\WINDOWS\system32\iisext.vbs" /AddFile "C:\Program
Files\PHP\php-cgi.exe",
you should type
"C:\WINDOWS\system32\iisext.vbs" /AddFile "C:\Program
Files\PHP\php-cgi.exe" 1 PHP 1 "PHP: Hypertext Processor"

Use iisext.vbs /? to see the meaning of the parameters.

The installer needs to be fixed.

Actual result:
--
Installation produced the error message, PHP was not registered, but all
other things seemed to go well.

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

#39411 [Bgs]: php (cgi) binary is not produced when compiling with apxs2 configured

[thp3 at sigproc dot de]

 ID:   39411
 User updated by:  thp3 at sigproc dot de
 Reported By:  thp3 at sigproc dot de
 Status:   Bogus
 Bug Type: *Compile Issues
 Operating System: Linux 2.6.8
 PHP Version:  5.2.0
 New Comment:

If only the fact that only CLI + any other sapi can be compiled at a
time would be indicated in the installation notes, I would be quite
happy. Note BTW that the documenation does NOT talk about the CGI
executable as one of the sapis.

In any case the fact that I ran into the same misunderstanding as the
submitter of Bug #30682 shows that it is worth adjusting the
documentation. My enquiry thus should rather be considered a
"documentation request" than "bug report".


Previous Comments:


[2006-11-07 14:09:05] [EMAIL PROTECTED]

Please don't submit the same bug twice. You can only compile CLI + any
other sapi.



[2006-11-07 09:08:57] thp3 at sigproc dot de

Description:

Re-issueing of Bug #30682 (php (cgi) binary does not compile with apxs2
configured).

When having the "--with-apxs" option enabled, the CGI executable is not
generated during compilation, though this is implied by the naming of
the configure options and the current documentation in file INSTALL.

Rationale: though it might be trivial for the php developers to know
that the CGI executable is only one of the SAPI modules and that only
one SAPI module (+ cli) can be compiled at a time, for the average user
it is just puzzling not to find the CGI executable after use of a rather
unsuspicious configure command.

Please either 
a) adjust the naming of configure options (e.g. have an explicit option
for the target, i.e. --build-sapi={cgi|apache|...}), or
b) leave a small note in the documentation about the issue, preferably
in INSTALL or at the top of the "configure --help" text. (Something
like: "Note that enabling --with-apxs and alike will cease the CGI
executable from being built.")







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

#35634 [Com]: Erroneous "Class declarations may not be nested" error raised.

[a dot laquerre at videotron dot ca]

 ID:   35634
 Comment by:   a dot laquerre at videotron dot ca
 Reported By:  robert at interjinn dot com
 Status:   Assigned
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  5.1.1
 Assigned To:  dmitry
 New Comment:

I have upgraded to from version 5.1 to 5.2 on Windows with Apache and I
have an that error "Class declarations may not be nested".

I had that bug in that case:

class A extends C{

 static public function foo{
 
  require_once(B.class);
 }

}


Previous Comments:


[2006-08-14 17:27:28] [EMAIL PROTECTED]

http://www.xaraya.com/~rabbitt/zend.c.patch
Dmitry, could you plz check out this patch?



[2006-08-08 16:25:26] rabbitt at gmail dot com

if you think about it, it actually makes sense (and it doesn't at the
same time). When the exception is triggered, it's done from within
TestClass (during the declaration of the class
(zend_do_begin_function_declaration())), so the scope is still focused
there. So when errorHandler() is called due to the E_STRICT, it is
including (and thus, declaring) the 'errorClass' inside of the
errorHandler() function *inside* of TestClass.

Personally, I think this is a bug and, that the active_class_entry
should be saved and cleared prior to calling the errorhandler and then
restored afterwards. That would enable the error handler to work with
errors that are emitted within the context of a class that's in the
process of being declared (ie: scope is inbetween
zend_do_begin_class_declaration() and
zend_do_end_class_declaration()).

I'll attach a quick patch that does just this momentarily.



[2005-12-16 20:22:01] robert at interjinn dot com

I think this report should be given further consideration. I've read
the docs (not that I hadn't before), and I will assume you think this
is bogus because of the following int he PHP docs:

The following error types cannot be handled with
a user defined function: E_ERROR, E_PARSE, E_CORE_ERROR,
E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and
most of E_STRICT raised in the file where
set_error_handler() is called.

However, the E_STRICT raised int he error handler script should not be
raised in the first place since it is PHP erroneous context that
believes the class declaration is being nested, when in fact the class
declaration is not being nested. If the include context was properly
scoped, then no E_STRICT would be raised and I wouldn't be having a
problem.

If this is not why this bug was marked bogus, please shed some light
for me, since the bogus comment was pretty uninformative (yes I know
you're busy and don't have time for 50 million bogus bugs but there's
only so much RTFM I can do and hope I can come across exactly what you
think makes this a bogus bug).

Cheers,
Rob.



[2005-12-11 19:15:37] robert at interjinn dot com

Description:

PHP bails out with class declaration nesting error when an error
handler dynamically loads an error handling class during a class
related E_STRICT warning.

Reproduce code:
---
test.php
handleException(
$errorNumber, $errorMessage, $fileName, $lineNumber );
}


require_once( 'testClass.php' );

$test = new TestClass();
?>

-

testClass.php
__construct();
}
}

?>

-

errorClass.php




Expected result:

I expect to properly be able to handle the following E_STRICT in my
custom error class:


Strict Standards:  Redefining already defined constructor for
class TestClass in /home/suds/testClass.php on line 9



Actual result:
--
Fatal error:  Class declarations may not be nested in
/home/suds/errorClass.php on line 4






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

#39418 [Opn]: Crash in _zval_ptr_dtor()

[php at fiddaman dot net]

 ID:   39418
 User updated by:  php at fiddaman dot net
 Reported By:  php at fiddaman dot net
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Solaris 10
 PHP Version:  5.2.0
 New Comment:

Same result with latest 5.2 CVS

#0  _zval_ptr_dtor (zval_ptr=0x7fffd260)
at /data/src/build/php5.2-200611072130/Zend/zend_execute_API.c:412
412 (*zval_ptr)->refcount--;


Previous Comments:


[2006-11-07 23:22:16] php at fiddaman dot net

Description:

I've compiled PHP 5.2.0 as a replacement for 5.1.6 which is running
fine here. 5.2.0 crashes with any PHP web page.

This is Solaris 10, 64-bit.

I've recompiled without any extensions, same result.

./configure \
--prefix=$DIR \
--with-exec-dir=$DIR/bin \
--with-apxs2=/opt/apache/bin/apxs \
--disable-libgcc \
--disable-libxml \
--disable-dom \
--disable-simplexml \
--disable-xml \
--disable-xmlreader \
--disable-xmlwriter \
--without-pear

Not sure how to debug this further.

Reproduce code:
---


Expected result:

test

Actual result:
--
Program terminated with signal 11, Segmentation fault.
#0  _zval_ptr_dtor (zval_ptr=0x7fffd1a0)
at /data/src/build/php-5.2.0/Zend/zend_execute_API.c:412
412 (*zval_ptr)->refcount--;
(gdb) where
#0  _zval_ptr_dtor (zval_ptr=0x7fffd1a0)
at /data/src/build/php-5.2.0/Zend/zend_execute_API.c:412
#1  0x78abd1c8 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7fffd438)
at /data/src/build/php-5.2.0/Zend/zend_execute.h:149
#2  0x78aac2dc in execute (op_array=0x7fffe660)
at /data/src/build/php-5.2.0/Zend/zend_vm_execute.h:92
#3  0x78a8e1a8 in zend_execute_scripts (type=5034360,
retval=, file_count=2024194208)
at /data/src/build/php-5.2.0/Zend/zend.c:1097
#4  0x78a49fc4 in php_execute_script (primary_file=0x0)
at /data/src/build/php-5.2.0/main/main.c:1758
#5  0x78b18d98 in php_handler (r=0x0)
at
/data/src/build/php-5.2.0/sapi/apache2handler/sapi_apache2.c:592
#6  0x000100049e00 in ap_run_handler ()
#7  0x00010004abf0 in ap_invoke_handler ()
#8  0x0001000a6314 in ap_process_request ()
#9  0x0001000a1158 in ap_process_http_connection ()
#10 0x000100056710 in ap_run_process_connection ()
#11 0x000100056d8c in ap_process_connection ()
#12 0x0001000d9358 in child_main ()
#13 0x0001000d9674 in make_child ()
#14 0x0001000d9b68 in perform_idle_server_maintenance ()
#15 0x0001000da5ac in ap_mpm_run ()
#16 0x000100024c28 in main ()






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

#39418 [NEW]: Crash in _zval_ptr_dtor()

[php at fiddaman dot net]

From: php at fiddaman dot net
Operating system: Solaris 10
PHP version:  5.2.0
PHP Bug Type: Reproducible crash
Bug description:  Crash in _zval_ptr_dtor()

Description:

I've compiled PHP 5.2.0 as a replacement for 5.1.6 which is running fine
here. 5.2.0 crashes with any PHP web page.

This is Solaris 10, 64-bit.

I've recompiled without any extensions, same result.

./configure \
--prefix=$DIR \
--with-exec-dir=$DIR/bin \
--with-apxs2=/opt/apache/bin/apxs \
--disable-libgcc \
--disable-libxml \
--disable-dom \
--disable-simplexml \
--disable-xml \
--disable-xmlreader \
--disable-xmlwriter \
--without-pear

Not sure how to debug this further.

Reproduce code:
---


Expected result:

test

Actual result:
--
Program terminated with signal 11, Segmentation fault.
#0  _zval_ptr_dtor (zval_ptr=0x7fffd1a0)
at /data/src/build/php-5.2.0/Zend/zend_execute_API.c:412
412 (*zval_ptr)->refcount--;
(gdb) where
#0  _zval_ptr_dtor (zval_ptr=0x7fffd1a0)
at /data/src/build/php-5.2.0/Zend/zend_execute_API.c:412
#1  0x78abd1c8 in zend_do_fcall_common_helper_SPEC (
execute_data=0x7fffd438)
at /data/src/build/php-5.2.0/Zend/zend_execute.h:149
#2  0x78aac2dc in execute (op_array=0x7fffe660)
at /data/src/build/php-5.2.0/Zend/zend_vm_execute.h:92
#3  0x78a8e1a8 in zend_execute_scripts (type=5034360,
retval=, file_count=2024194208)
at /data/src/build/php-5.2.0/Zend/zend.c:1097
#4  0x78a49fc4 in php_execute_script (primary_file=0x0)
at /data/src/build/php-5.2.0/main/main.c:1758
#5  0x78b18d98 in php_handler (r=0x0)
at /data/src/build/php-5.2.0/sapi/apache2handler/sapi_apache2.c:592
#6  0x000100049e00 in ap_run_handler ()
#7  0x00010004abf0 in ap_invoke_handler ()
#8  0x0001000a6314 in ap_process_request ()
#9  0x0001000a1158 in ap_process_http_connection ()
#10 0x000100056710 in ap_run_process_connection ()
#11 0x000100056d8c in ap_process_connection ()
#12 0x0001000d9358 in child_main ()
#13 0x0001000d9674 in make_child ()
#14 0x0001000d9b68 in perform_idle_server_maintenance ()
#15 0x0001000da5ac in ap_mpm_run ()
#16 0x000100024c28 in main ()


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

#39417 [NEW]: Handling of 'new-blocklevel-tags' inconsistent

[konstantin dot ryabitsev at mcgill dot ca]

From: konstantin dot ryabitsev at mcgill dot ca
Operating system: Linux
PHP version:  5.2.0
PHP Bug Type: Unknown/Other Function
Bug description:  Handling of 'new-blocklevel-tags' inconsistent

Description:

I seem to get odd behaviour running the following code. Theoretically (and
confirmed by running command-line tidy utility), the output should contain
all namespace-prepended tags. On my machine, the output only contains the
 element, and none of the elements contained within.

It's really weird. If I change the names to "wps:blo", "wps:var" and
"wps:val", it works. I'm really confused at this point.

Reproduce code:
---

 
   
 
';
$config = array(
'new-blocklevel-tags' => 'wps:block,wps:var,wps:value'
);
$tidy = tidy_parse_string($contents, $config, 'utf8');
$tidy->cleanRepair();
print "{$tidy->value}\n";
?>

Expected result:














Actual result:
--










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

#39417 [Opn]: Tidy: Handling of 'new-blocklevel-tags' inconsistent

[konstantin dot ryabitsev at mcgill dot ca]

 ID:   39417
 User updated by:  konstantin dot ryabitsev at mcgill dot ca
-Summary:  Handling of 'new-blocklevel-tags' inconsistent
 Reported By:  konstantin dot ryabitsev at mcgill dot ca
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Linux
-PHP Version:  5.2.0
+PHP Version:  5.1.6
 New Comment:

Specifying "Tidy:" in the Summary.


Previous Comments:


[2006-11-07 22:19:03] konstantin dot ryabitsev at mcgill dot ca

Description:

I seem to get odd behaviour running the following code. Theoretically
(and confirmed by running command-line tidy utility), the output should
contain all namespace-prepended tags. On my machine, the output only
contains the  element, and none of the elements contained
within.

It's really weird. If I change the names to "wps:blo", "wps:var" and
"wps:val", it works. I'm really confused at this point.

Reproduce code:
---

 
   
 
';
$config = array(
'new-blocklevel-tags' => 'wps:block,wps:var,wps:value'
);
$tidy = tidy_parse_string($contents, $config, 'utf8');
$tidy->cleanRepair();
print "{$tidy->value}\n";
?>

Expected result:














Actual result:
--














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

#39401 [Opn->Bgs]: conflicting types for utf8_mime2text

[iliaa]

 ID:   39401
 Updated by:   [EMAIL PROTECTED]
 Reported By:  wouter at widexs dot nl
-Status:   Open
+Status:   Bogus
 Bug Type: IMAP related
 Operating System: Linux
 PHP Version:  5.2.0
 New Comment:

It works just fine here as long as the fullpath to the library 
is specified ala /usr/local/imap-2006c 


Previous Comments:


[2006-11-07 19:58:52] wouter at widexs dot nl

This patch fixes my problem ...

--- php-5.2.0/configure Wed Nov  1 03:01:06 2006
+++ php-5.2.0-fix/configure Tue Nov  7 20:55:02 2006
@@ -45673,10 +45673,12 @@
 rm -f conftest*


+old_CPPFLAGS=$CPPFLAGS
+   CPPFLAGS=-I$IMAP_INC_DIR
 cat > conftest.$ac_ext <
+#include "mail.h"
 EOF
 if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
   egrep "mail_append_set" >/dev/null 2>&1; then
@@ -45690,7 +45692,8 @@
 fi
 rm -f conftest*

-
+CPPFLAGS=$old_CPPFLAGS
+
 old_CPPFLAGS=$CPPFLAGS
 CPPFLAGS=-I$IMAP_INC_DIR
 cat > conftest.$ac_ext <

to 

#include "$IMAP_INC_DIR/mail.h"

It correctly works...



[2006-11-07 18:49:33] wouter at widexs dot nl

It hasn't ...

php-5.2.0/main/php_config.h:/* #undef HAVE_NEW_MIME2TEXT */



[2006-11-07 17:09:03] [EMAIL PROTECTED]

Can you see if HAVE_NEW_MIME2TEXT is defined inside PHP's 
main.h ?



[2006-11-06 18:25:37] wouter at widexs dot nl

Yes, it does :)


grep "mail_append_set" src/c-client/mail.h

SEARCHSET *mail_append_set (SEARCHSET *set,unsigned long msgno);



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

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

php-bugs@lists.php.net

[iliaa]

 ID:   33282
 Updated by:   [EMAIL PROTECTED]
 Reported By:  devik at cdi dot cz
-Status:   Assigned
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: Linux
 PHP Version:  5CVS-2005-06-13
 Assigned To:  dmitry
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2005-09-02 08:33:04] devik at cdi dot cz

Sorry but I still see the problem. Regarding version,
I used directory name as I found nothing like 5CVS-2005-06-13
in the downloaded package.



[2005-09-02 07:42:21] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

And DO NOT invent your own style for the PHP version field!!
(Hint: PHP version string does NOT contain 'PHP' in it..)





[2005-06-09 15:33:27] devik at cdi dot cz

Description:

This is variation on #15025. But I accept the bug is feature and I show
other bug it triggers.

Basic problem is that when you take ref of array item then the item
will turn into reference (which will survive even array copy). I don't
see it as too big problem as long as I can get rid of the reference.
"unset" does the trick as expected:
$r =& $A[0]; 
unset($r); - $A[0] is not reference any more

But something like:
$r =& $othervar;

doesn't kill reference - you see zval with is_ref=1 and refcount=1.

It prevents you from writing handy code:
$c = &$c[$i] when traversing complex structures.

Reproduce code:
---



Expected result:

I expect $a without references.

Actual result:
--
$a[0] is reference with refcount(1).





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

#39401 [Opn]: conflicting types for utf8_mime2text

[wouter at widexs dot nl]

 ID:   39401
 User updated by:  wouter at widexs dot nl
 Reported By:  wouter at widexs dot nl
 Status:   Open
 Bug Type: IMAP related
 Operating System: Linux
 PHP Version:  5.2.0
 New Comment:

This patch fixes my problem ...

--- php-5.2.0/configure Wed Nov  1 03:01:06 2006
+++ php-5.2.0-fix/configure Tue Nov  7 20:55:02 2006
@@ -45673,10 +45673,12 @@
 rm -f conftest*


+old_CPPFLAGS=$CPPFLAGS
+   CPPFLAGS=-I$IMAP_INC_DIR
 cat > conftest.$ac_ext <
+#include "mail.h"
 EOF
 if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
   egrep "mail_append_set" >/dev/null 2>&1; then
@@ -45690,7 +45692,8 @@
 fi
 rm -f conftest*

-
+CPPFLAGS=$old_CPPFLAGS
+
 old_CPPFLAGS=$CPPFLAGS
 CPPFLAGS=-I$IMAP_INC_DIR
 cat > conftest.$ac_ext <

to 

#include "$IMAP_INC_DIR/mail.h"

It correctly works...



[2006-11-07 18:49:33] wouter at widexs dot nl

It hasn't ...

php-5.2.0/main/php_config.h:/* #undef HAVE_NEW_MIME2TEXT */



[2006-11-07 17:09:03] [EMAIL PROTECTED]

Can you see if HAVE_NEW_MIME2TEXT is defined inside PHP's 
main.h ?



[2006-11-06 18:25:37] wouter at widexs dot nl

Yes, it does :)


grep "mail_append_set" src/c-client/mail.h

SEARCHSET *mail_append_set (SEARCHSET *set,unsigned long msgno);



[2006-11-06 17:01:26] [EMAIL PROTECTED]

Does your imap's mail.h header contain the mail_append_set() 
function?



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

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

#39416 [NEW]: Milliseconds in date()

[pascal at tweakers dot net]

From: pascal at tweakers dot net
Operating system: Fedora 4
PHP version:  5.2.0
PHP Bug Type: Feature/Change Request
Bug description:  Milliseconds in date() 

Description:

I'm missing the option for milliseconds in the date()-function and others.
Especially while generating unique identifiers for files it's very handy.
Is it possible to integrate this option to the date()-method?

Expected result:

2006-11-07 20:24:40:992 or someting like that?


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

#39401 [Opn]: conflicting types for utf8_mime2text

[wouter at widexs dot nl]

 ID:   39401
 User updated by:  wouter at widexs dot nl
 Reported By:  wouter at widexs dot nl
 Status:   Open
 Bug Type: IMAP related
 Operating System: Linux
 PHP Version:  5.2.0
 New Comment:

CHECKING FOR HAVE_NEW_MIME2TEXT
configure:45679: ../imap-2006c1/c-client/mail.h: No such file or
directory

This file exists though...

If I change configure from :

#include <$IMAP_INC_DIR/mail.h>

to 

#include "$IMAP_INC_DIR/mail.h"

It correctly works...


Previous Comments:


[2006-11-07 18:49:33] wouter at widexs dot nl

It hasn't ...

php-5.2.0/main/php_config.h:/* #undef HAVE_NEW_MIME2TEXT */



[2006-11-07 17:09:03] [EMAIL PROTECTED]

Can you see if HAVE_NEW_MIME2TEXT is defined inside PHP's 
main.h ?



[2006-11-06 18:25:37] wouter at widexs dot nl

Yes, it does :)


grep "mail_append_set" src/c-client/mail.h

SEARCHSET *mail_append_set (SEARCHSET *set,unsigned long msgno);



[2006-11-06 17:01:26] [EMAIL PROTECTED]

Does your imap's mail.h header contain the mail_append_set() 
function?



[2006-11-06 15:23:14] wouter at widexs dot nl

Description:

I get an error when trying to build PHP 5.2.0 with imap c-client 2006c1
(ftp://ftp.cac.washington.edu/mail/imap-2006c1.tar.Z) :

/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79:
conflicting types for `utf8_mime2text'
/opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548:
previous declaration of `utf8_mime2text'

Which is correct, because:

* PHP 5.2.0 : long utf8_mime2text(SIZEDTEXT *src, SIZEDTEXT *dst);
* imap c-client 2006c1 : long utf8_mime2text (SIZEDTEXT *src,SIZEDTEXT
*dst,long flags);

Haven't tested with previous versions of PHP, but I assume the same
will happen.

IMAP c-client 2004g gives no problem.

This could be seen as a DUP of #37948 and #38941, but it is still
present in 5.2.0 ...

Actual result:
--
/bin/sh /opt/install/widexs_apache_2006_017/php-5.2.0/libtool --silent
--preserve-dup-deps --mode=compile gcc  -Iext/imap/
-I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/
-DPHP_ATOM_INC -I/opt/install/widexs_apache_2006_017/php-5.2.0/include
-I/opt/install/widexs_apache_2006_017/php-5.2.0/main
-I/opt/install/widexs_apache_2006_017/php-5.2.0
-I/usr/local/include/libxml2 -I/usr/local/ssl/include
-I/usr/local/include
-I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/date/lib
-I/usr/include/freetype2
-I/opt/install/widexs_apache_2006_017/imap-2006c1/c-client
-I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/oniguruma
-I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl
-I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl/mbfl
-I/usr/local/mysql/include/mysql -I/usr/local/pgsql/include
-I/opt/install/widexs_apache_2006_017/php-5.2.0/TSRM
-I/opt/install/widexs_apache_2006_017/php-5.2.0/Zend-I/usr/include
-g -O2  -c
/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c -o
ext/imap/php_imap.lo
/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79:
conflicting types for `utf8_mime2text'
/opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548:
previous declaration of `utf8_mime2text'





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

php-bugs@lists.php.net

[dmitry]

 ID:   33282
 Updated by:   [EMAIL PROTECTED]
 Reported By:  devik at cdi dot cz
-Status:   Open
+Status:   Assigned
 Bug Type: Feature/Change Request
 Operating System: Linux
 PHP Version:  5CVS-2005-06-13
-Assigned To:  
+Assigned To:  dmitry


Previous Comments:


[2005-09-02 08:33:04] devik at cdi dot cz

Sorry but I still see the problem. Regarding version,
I used directory name as I found nothing like 5CVS-2005-06-13
in the downloaded package.



[2005-09-02 07:42:21] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

And DO NOT invent your own style for the PHP version field!!
(Hint: PHP version string does NOT contain 'PHP' in it..)





[2005-06-09 15:33:27] devik at cdi dot cz

Description:

This is variation on #15025. But I accept the bug is feature and I show
other bug it triggers.

Basic problem is that when you take ref of array item then the item
will turn into reference (which will survive even array copy). I don't
see it as too big problem as long as I can get rid of the reference.
"unset" does the trick as expected:
$r =& $A[0]; 
unset($r); - $A[0] is not reference any more

But something like:
$r =& $othervar;

doesn't kill reference - you see zval with is_ref=1 and refcount=1.

It prevents you from writing handy code:
$c = &$c[$i] when traversing complex structures.

Reproduce code:
---



Expected result:

I expect $a without references.

Actual result:
--
$a[0] is reference with refcount(1).





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

#38536 [Com]: Returning an array of values instead of an object

[marcus at corp dot grupos dot com dot br]

 ID:   38536
 Comment by:   marcus at corp dot grupos dot com dot br
 Reported By:  sabrina at corp dot grupos dot com dot br
 Status:   Assigned
 Bug Type: SOAP related
 Operating System: FreeBSD 6.1
 PHP Version:  PHP_5_2 cvs
 Assigned To:  dmitry
 New Comment:

More info...

-- soap client php --
SOAP_1_1, 'exceptions'=>true, 'trace'=>1,
'encoding'=>'ISO-8859-1',
'location'=>'http://corp.grupos.com.br:1028');
$SOAPObject = new SoapClient('session.wsdl', $arr);
var_dump($SOAPObject->__soapCall('getClientInfoFromDomain',
array('sabrina.corp.grupos.com.br')));
?>
--

Soap server reply:

http://intranet.grupos.com.br/~marcus/soaptest/soapserver.output

WSDL:

http://intranet.grupos.com.br/~marcus/soaptest/session.wsdl

Actual result:

http://intranet.grupos.com.br/~marcus/soaptest/actual.result

Expected result:

http://intranet.grupos.com.br/~marcus/soaptest/expected.result


Previous Comments:


[2006-11-07 14:06:51] sabrina at corp dot grupos dot com dot br

reopen



[2006-09-01 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2006-08-24 08:06:57] [EMAIL PROTECTED]

We still need a short reproduce script without private services and
fatal errors.



[2006-08-22 14:43:55] sabrina at corp dot grupos dot com dot br

unfortunately, you cannot execute this code as it is, because the
webservice in question is private and cannot be accessed externarly or
without authentication.

the line:
$return = $SOAPObject->__soapCall('getClientInfoFromDomain',
'sabrina.corp.grupos.com.br');
is incorrect, and should be:
$return = $SOAPObject->__soapCall('getClientInfoFromDomain',
array('sabrina.corp.grupos.com.br'));

but other than that, you could either try to access a webservice that
returns an array of objects or read the
the result dumps of this script for versions 5.1.4 and 5.1.5 
(you can check these files 
http://intranet.grupos.com.br/~sabrina/phpbug/phpreply515.html
http://intranet.grupos.com.br/~sabrina/phpbug/phpreply514.html
) and see that there is a big difference between both responses.

thank you for your replies.



[2006-08-22 13:51:31] [EMAIL PROTECTED]


Notice: Undefined variable: newIp in /tmp/1.php on line 4

Warning: SoapClient::__soapCall() expects parameter 2 to be array,
string given in /tmp/1.php on line 14

Fatal error: SoapClient::__soapCall(): Invalid parameters in /tmp/1.php
on line 14




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

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

#39401 [Fbk->Opn]: conflicting types for utf8_mime2text

[wouter at widexs dot nl]

 ID:   39401
 User updated by:  wouter at widexs dot nl
 Reported By:  wouter at widexs dot nl
-Status:   Feedback
+Status:   Open
 Bug Type: IMAP related
 Operating System: Linux
 PHP Version:  5.2.0
 New Comment:

It hasn't ...

php-5.2.0/main/php_config.h:/* #undef HAVE_NEW_MIME2TEXT */


Previous Comments:


[2006-11-07 17:09:03] [EMAIL PROTECTED]

Can you see if HAVE_NEW_MIME2TEXT is defined inside PHP's 
main.h ?



[2006-11-06 18:25:37] wouter at widexs dot nl

Yes, it does :)


grep "mail_append_set" src/c-client/mail.h

SEARCHSET *mail_append_set (SEARCHSET *set,unsigned long msgno);



[2006-11-06 17:01:26] [EMAIL PROTECTED]

Does your imap's mail.h header contain the mail_append_set() 
function?



[2006-11-06 15:23:14] wouter at widexs dot nl

Description:

I get an error when trying to build PHP 5.2.0 with imap c-client 2006c1
(ftp://ftp.cac.washington.edu/mail/imap-2006c1.tar.Z) :

/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79:
conflicting types for `utf8_mime2text'
/opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548:
previous declaration of `utf8_mime2text'

Which is correct, because:

* PHP 5.2.0 : long utf8_mime2text(SIZEDTEXT *src, SIZEDTEXT *dst);
* imap c-client 2006c1 : long utf8_mime2text (SIZEDTEXT *src,SIZEDTEXT
*dst,long flags);

Haven't tested with previous versions of PHP, but I assume the same
will happen.

IMAP c-client 2004g gives no problem.

This could be seen as a DUP of #37948 and #38941, but it is still
present in 5.2.0 ...

Actual result:
--
/bin/sh /opt/install/widexs_apache_2006_017/php-5.2.0/libtool --silent
--preserve-dup-deps --mode=compile gcc  -Iext/imap/
-I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/
-DPHP_ATOM_INC -I/opt/install/widexs_apache_2006_017/php-5.2.0/include
-I/opt/install/widexs_apache_2006_017/php-5.2.0/main
-I/opt/install/widexs_apache_2006_017/php-5.2.0
-I/usr/local/include/libxml2 -I/usr/local/ssl/include
-I/usr/local/include
-I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/date/lib
-I/usr/include/freetype2
-I/opt/install/widexs_apache_2006_017/imap-2006c1/c-client
-I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/oniguruma
-I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl
-I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl/mbfl
-I/usr/local/mysql/include/mysql -I/usr/local/pgsql/include
-I/opt/install/widexs_apache_2006_017/php-5.2.0/TSRM
-I/opt/install/widexs_apache_2006_017/php-5.2.0/Zend-I/usr/include
-g -O2  -c
/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c -o
ext/imap/php_imap.lo
/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79:
conflicting types for `utf8_mime2text'
/opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548:
previous declaration of `utf8_mime2text'





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

#39413 [Asn->Csd]: "bugfix" in Zend/zend_execute.c breaks PEAR install

[iliaa]

 ID:   39413
 Updated by:   [EMAIL PROTECTED]
 Reported By:  need dot coffee at gmail dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Class/Object related
 Operating System: *
 PHP Version:  4CVS-2006-11-06 (snap)
 Assigned To:  iliaa
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2006-11-07 11:26:34] need dot coffee at gmail dot com

Description:

First, I know this isn't the place for a PEAR bug; it 
doesn't
appear to be a PEAR bug...

Trying to install php4-STABLE-200611061330 fails at PEAR
installation time with "Fatal error: Call to a member 
function on a non-object in [,,,]/pear/PEAR/Installer/Role/
Common.php on line 90."

The pear code hasn't changed since I was able to last 
install; however PHP code has.  If I revert the change 
recently made in Zend/zend_compile.c, it installs fine:

--- Zend/zend_compile.c~Sun Oct 15 14:32:37 2006
+++ Zend/zend_compile.c Mon Nov  6 21:21:41 2006
@@ -1164,7 +1164,7 @@
 
if (zend_hash_find(&ce->parent->function_table, ce-
>parent->name, ce->parent->name_length+1, (void **) 
&function)==SUCCESS) {
/* inherit parent's constructor */
-   zend_hash_update(&ce->function_table, ce-
>parent->name, ce->parent->name_length+1, function, sizeof
(zend_function), NULL);
+   zend_hash_update(&ce->function_table, ce->name, 
ce->name_length+1, function, sizeof(zend_function), NULL);
function_add_ref(function);
}
}


Reproduce code:
---
Download a recent snap and try to run 'make install'.






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

#39398 [Opn->Csd]: No cast of logic type and silence

[iliaa]

 ID:   39398
 Updated by:   [EMAIL PROTECTED]
 Reported By:  develar at gmail dot com
-Status:   Open
+Status:   Closed
 Bug Type: PDO related
 Operating System: Debian 3
 PHP Version:  5.2.0
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2006-11-06 11:59:31] develar at gmail dot com

var_dump($Db->query('SELECT * FROM test')->fetchAll());



[2006-11-06 11:56:04] develar at gmail dot com

Description:

PDO does not cast a variable with boolean type in bindValue, does not
do execute and is silent.

I should cast manually - (int).

Reproduce code:
---
CREATE TABLE `test` (
  `test` tinyint(1) NOT NULL default '0'
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

$Db = new PDO('mysql:host=localhost;dbname=test', 'root', '');
$Db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$Db->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);

$boolean = 1;
$Pdo = $Db->prepare('INSERT INTO test VALUES (:boolean)');
$Pdo->bindValue(':boolean', isset($boolean), PDO::PARAM_INT);
$Pdo->execute();

Expected result:

array(1) { [0]=> array(1) { ["test"]=> string(1) "1" } }

Actual result:
--
array(0) { }





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

#39193 [Asn->Bgs]: unset($_SESSION[$key]) not saving session after reload

[iliaa]

 ID:   39193
 Updated by:   [EMAIL PROTECTED]
 Reported By:  gearb0x at eml dot cc
-Status:   Assigned
+Status:   Bogus
 Bug Type: Session related
 Operating System: Linux FC4
 PHP Version:  5.1.6
 Assigned To:  iliaa
 New Comment:

I've tried to replicate the described problem however the 
code appears to work properly.
I've made 3 scripts:

A:
session_start();
$_SESSION['A'] = 1;
$_SESSION['B'] = 'afdsf';

B:
session_start();
foreach($_SESSION as $key=>$value)
{
unset($_SESSION[$key]);
}

C:
session_start();
var_dump($_SESSION, session_id());


The code shows that the unset loop is in fact successful in 
clearing out & saving session data.


Previous Comments:


[2006-10-21 03:43:27] john dot cecere at sun dot com

I ran into this today with PHP 5.1.6. I spent most of the afternoon
trying to figure out why my vars were coming back after a header()
call. 

One might suggest that this isn't a bug and that this behavior is
described in the docs (the session_unregister page for example). I
would disagree with this. This behavior is very quirky and completely
counter-intuitive. It would be much better for unset to behave in a way
that you would expect, i.e. to unset a variable (or element of a
variable) so that it stays unset, regardless of whether that variable
happens to be $_SESSION or not.

John



[2006-10-19 15:40:04] gearb0x at eml dot cc

It doesnt clear it, all variables stay intact as they were when the
session started. It clears it in the current execution of the script,
but the next time the page loads all the variables are back as they
were before they were unset call

If i make any changes to session variables AFTER ive tried to unset one
they are not saved in the session on the next page load

Its as if the session doesnt save, even forcing the save with
session_write_close does not work



[2006-10-19 07:47:04] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

>This should clear the session. 
But it does ... instead?



[2006-10-19 04:19:11] gearb0x at eml dot cc

replacing unset($_SESSION[$key]) with session_unregister($key) has the
desired effect -- which your not suposed to use according to all docs.



[2006-10-19 04:01:21] gearb0x at eml dot cc

Description:

For some reason unseting session variables is stopping php from saving
any session variables. The code below should clear the session but it
isnt, this code worked fine on 5.1.2 on a freeBSD box. Also ive noticed
that if i make any changes to the session variables (ie: adding new
ones) they dont get saved in the session either

Reproduce code:
---
$value)
{
unset($_SESSION[$key]);
}

?>

Expected result:

This should clear the session. Also, any other changes made to the
session arent saved either (ie: creating more session variables






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

#39199 [Opn]: Cannot load Lob data with more than 4000 bytes on ORACLE 10

[jarismar_silva at adplabs dot com dot br]

 ID:   39199
 User updated by:  jarismar_silva at adplabs dot com dot br
 Reported By:  jarismar_silva at adplabs dot com dot br
 Status:   Open
 Bug Type: PDO related
 Operating System: SuSE, WinXP
 PHP Version:  5.2.0
 Assigned To:  wez
 New Comment:

Previously (when close the bug) I have tested on Slackware 11 with
Oracle Instant Client 10.2 and I stop getting this bug. The same on
another box running Kubuntu and Oracle Instant Client 10.2. But I got
the bug on a Suse server and many XP machines used on development.


Previous Comments:


[2006-11-07 17:11:38] diegotremper at gmail dot com

I obtained in the same error on Windows XP SP2



[2006-11-07 17:05:46] jarismar_silva at adplabs dot com dot br

I'm reopening this bug. I have found that this bug still occurs with
Oracle Client 10.2 and SuSE Enterprise Server v.9 Patch Lvl 3 / WinXP.



[2006-10-23 12:17:04] jarismar_silva at adplabs dot com dot br

I'm closing this bug, as updating to new Oracle instant client seems to
solve the problem.



[2006-10-23 12:10:12] jarismar_silva at adplabs dot com dot rb

I got this bug when working with Oracle instant client 10.2.0.1.
Upgrading to 10.2.0.2 solved the problem.



[2006-10-19 14:59:33] jarismar_silva at adplabs dot com dot br

jarismar_silva at adplabs.com.br



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

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

#39199 [Com]: Cannot load Lob data with more than 4000 bytes on ORACLE 10

[diegotremper at gmail dot com]

 ID:   39199
 Comment by:   diegotremper at gmail dot com
 Reported By:  jarismar_silva at adplabs dot com dot br
 Status:   Open
 Bug Type: PDO related
 Operating System: SuSE, WinXP
 PHP Version:  5.2.0
 Assigned To:  wez
 New Comment:

I obtained in the same error on Windows XP SP2


Previous Comments:


[2006-11-07 17:05:46] jarismar_silva at adplabs dot com dot br

I'm reopening this bug. I have found that this bug still occurs with
Oracle Client 10.2 and SuSE Enterprise Server v.9 Patch Lvl 3 / WinXP.



[2006-10-23 12:17:04] jarismar_silva at adplabs dot com dot br

I'm closing this bug, as updating to new Oracle instant client seems to
solve the problem.



[2006-10-23 12:10:12] jarismar_silva at adplabs dot com dot rb

I got this bug when working with Oracle instant client 10.2.0.1.
Upgrading to 10.2.0.2 solved the problem.



[2006-10-19 14:59:33] jarismar_silva at adplabs dot com dot br

jarismar_silva at adplabs.com.br



[2006-10-19 14:50:44] jarismar_silva at adplabs dot com dot br

Description:

Trying to read a CLOB field with has more than 4000 bytes result on
empty stream.

Reproduce code:
---
:1521/;charset=UTF-8';
$sUserName = '';
$sPassword = 'prepare("insert into test_clob (id, data) values
(:id, EMPTY_CLOB())");
  $iID = 1;
  $oStmt->bindParam(':id', $iID);
  if ($oStmt->execute()) {
$oStmt = $oPDO->prepare("update test_clob set data=:value where
id=1");
$sData = '<4000 bytes or more>';
$oStmt->bindParam(':value', $sData);
if ($oStmt->execute() === false) {
  throw new Exception('Error on update clob');
}
  } else {
throw new Exception('Error on insert EMPTY_CLOB');
  }

  $oStmt = $oPDO->prepare("select data from test_clob where id =
:id");
  $oStmt->bindParam('id', $iID);
  $oStmt->execute();
  $oResult = $oStmt->fetch();
  echo 'Read '.strlen(stream_get_contents($oResult['DATA'])).'
characters ';

} catch (Exception $oE) {
  echo '';print_r($oStmt->errorInfo());echo "\n";
  echo $oException->getMessage()."\n";
}
$oPDO = null;

Expected result:

Read N characters (N >0)

Actual result:
--
Read 0 characters





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

#39401 [Opn->Fbk]: conflicting types for utf8_mime2text

[iliaa]

 ID:   39401
 Updated by:   [EMAIL PROTECTED]
 Reported By:  wouter at widexs dot nl
-Status:   Open
+Status:   Feedback
 Bug Type: IMAP related
 Operating System: Linux
 PHP Version:  5.2.0
 New Comment:

Can you see if HAVE_NEW_MIME2TEXT is defined inside PHP's 
main.h ?


Previous Comments:


[2006-11-06 18:25:37] wouter at widexs dot nl

Yes, it does :)


grep "mail_append_set" src/c-client/mail.h

SEARCHSET *mail_append_set (SEARCHSET *set,unsigned long msgno);



[2006-11-06 17:01:26] [EMAIL PROTECTED]

Does your imap's mail.h header contain the mail_append_set() 
function?



[2006-11-06 15:23:14] wouter at widexs dot nl

Description:

I get an error when trying to build PHP 5.2.0 with imap c-client 2006c1
(ftp://ftp.cac.washington.edu/mail/imap-2006c1.tar.Z) :

/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79:
conflicting types for `utf8_mime2text'
/opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548:
previous declaration of `utf8_mime2text'

Which is correct, because:

* PHP 5.2.0 : long utf8_mime2text(SIZEDTEXT *src, SIZEDTEXT *dst);
* imap c-client 2006c1 : long utf8_mime2text (SIZEDTEXT *src,SIZEDTEXT
*dst,long flags);

Haven't tested with previous versions of PHP, but I assume the same
will happen.

IMAP c-client 2004g gives no problem.

This could be seen as a DUP of #37948 and #38941, but it is still
present in 5.2.0 ...

Actual result:
--
/bin/sh /opt/install/widexs_apache_2006_017/php-5.2.0/libtool --silent
--preserve-dup-deps --mode=compile gcc  -Iext/imap/
-I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/
-DPHP_ATOM_INC -I/opt/install/widexs_apache_2006_017/php-5.2.0/include
-I/opt/install/widexs_apache_2006_017/php-5.2.0/main
-I/opt/install/widexs_apache_2006_017/php-5.2.0
-I/usr/local/include/libxml2 -I/usr/local/ssl/include
-I/usr/local/include
-I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/date/lib
-I/usr/include/freetype2
-I/opt/install/widexs_apache_2006_017/imap-2006c1/c-client
-I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/oniguruma
-I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl
-I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl/mbfl
-I/usr/local/mysql/include/mysql -I/usr/local/pgsql/include
-I/opt/install/widexs_apache_2006_017/php-5.2.0/TSRM
-I/opt/install/widexs_apache_2006_017/php-5.2.0/Zend-I/usr/include
-g -O2  -c
/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c -o
ext/imap/php_imap.lo
/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79:
conflicting types for `utf8_mime2text'
/opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548:
previous declaration of `utf8_mime2text'





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

#39199 [Csd->Opn]: Cannot load Lob data with more than 4000 bytes on ORACLE 10

[jarismar_silva at adplabs dot com dot br]

 ID:   39199
 User updated by:  jarismar_silva at adplabs dot com dot br
 Reported By:  jarismar_silva at adplabs dot com dot br
-Status:   Closed
+Status:   Open
 Bug Type: PDO related
-Operating System: Linux
+Operating System: SuSE, WinXP
-PHP Version:  5.2.0RC5
+PHP Version:  5.2.0
 Assigned To:  wez
 New Comment:

I'm reopening this bug. I have found that this bug still occurs with
Oracle Client 10.2 and SuSE Enterprise Server v.9 Patch Lvl 3 / WinXP.


Previous Comments:


[2006-10-23 12:17:04] jarismar_silva at adplabs dot com dot br

I'm closing this bug, as updating to new Oracle instant client seems to
solve the problem.



[2006-10-23 12:10:12] jarismar_silva at adplabs dot com dot rb

I got this bug when working with Oracle instant client 10.2.0.1.
Upgrading to 10.2.0.2 solved the problem.



[2006-10-19 14:59:33] jarismar_silva at adplabs dot com dot br

jarismar_silva at adplabs.com.br



[2006-10-19 14:50:44] jarismar_silva at adplabs dot com dot br

Description:

Trying to read a CLOB field with has more than 4000 bytes result on
empty stream.

Reproduce code:
---
:1521/;charset=UTF-8';
$sUserName = '';
$sPassword = 'prepare("insert into test_clob (id, data) values
(:id, EMPTY_CLOB())");
  $iID = 1;
  $oStmt->bindParam(':id', $iID);
  if ($oStmt->execute()) {
$oStmt = $oPDO->prepare("update test_clob set data=:value where
id=1");
$sData = '<4000 bytes or more>';
$oStmt->bindParam(':value', $sData);
if ($oStmt->execute() === false) {
  throw new Exception('Error on update clob');
}
  } else {
throw new Exception('Error on insert EMPTY_CLOB');
  }

  $oStmt = $oPDO->prepare("select data from test_clob where id =
:id");
  $oStmt->bindParam('id', $iID);
  $oStmt->execute();
  $oResult = $oStmt->fetch();
  echo 'Read '.strlen(stream_get_contents($oResult['DATA'])).'
characters ';

} catch (Exception $oE) {
  echo '';print_r($oStmt->errorInfo());echo "\n";
  echo $oException->getMessage()."\n";
}
$oPDO = null;

Expected result:

Read N characters (N >0)

Actual result:
--
Read 0 characters





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

#39415 [Opn]: C ompilation failure on preg_match_all()

[jordi at telematictraining dot com]

 ID:   39415
 User updated by:  jordi at telematictraining dot com
 Reported By:  jordi at telematictraining dot com
 Status:   Open
 Bug Type: Compile Failure
 Operating System: Debian GNU/Linux Stable
 PHP Version:  5.2.0
 New Comment:

The content of $pattern was line-altered (line breaks where they
shouldn't), so here's the correct one:

$pattern="/((field):(codigo_doa|titulo_obra|titulo_alternativo|num_serie|ejemplar_serie|ejemplares_obra|nombre_tecnica|materiales_soporte|medidas_diametro|lista_artistas|medidas_peso|medidas_resolucion|epoca_corriente|medidas_minutaje|color|sonido_canales|numero_normalizado|valor|fecha_creacion|medidas_longitud|es_firmado|exactitud_fecha|tipo_obra|tipologia_objeto|tipo_tecnica|unidades_medidas|unidades_peso|tipo_formato|nombre_formato_imagen|arquitectura|hay_sonido|sonido_nombre_formato|sonido_muestreo|sonido_amplitud|sonido_idioma_original|pais_publicacion))|((barcode):((\_[ABC]){0,1}(\((\d+)\)){0,1}(\{(codigo_doa|titulo_obra|titulo_alternativo|num_serie|ejemplar_serie|ejemplares_obra|nombre_tecnica|materiales_soporte|medidas_diametro|lista_artistas|medidas_peso|medidas_resolucion|epoca_corriente|medidas_minutaje|color|sonido_canales|numero_normalizado|valor|fecha_creacion|medidas_longitud|es_firmado|exactitud_fecha|tipo_obra|tipologia_objeto|tipo_tecnica|unidades_medidas|u!
 nidades_pe
so|tipo_formato|nombre_formato_imagen|arquitectura|hay_sonido|sonido_nombre_formato|sonido_muestreo|sonido_amplitud|sonido_idioma_original|pais_publicacion)\}){1,45}))/"


Previous Comments:


[2006-11-07 16:45:40] jordi at telematictraining dot com

Description:

Hi there,

What we did? Update php 5.1.6 to 5.2.0.
What we wanted to happen? We expected the 5.2.0 version to behave/work
as the previous ones (5.1.2, 5.1.4 and 5.1.6).
What actualy happened? It didn't.

We have a php based app and we've been working since php version 5.1.2.
But with this new version (5.2.0) it seems to be a problem with the
preg_match_all() function.

Being the function call preg_match_all(string $pattern, string
$subject, array $coincidences), this are the values of the variables:

$pattern =
"/((field):(codigo_doa|titulo_obra|titulo_alternativo|num_serie|ejemplar_serie|ej
emplares_obra|nombre_tecnica|materiales_soporte|medidas_diametro|lista_artistas|m
edidas_peso|medidas_resolucion|epoca_corriente|medidas_minutaje|color|sonido_cana
les|numero_normalizado|valor|fecha_creacion|medidas_longitud|es_firmado|exactitud
_fecha|tipo_obra|tipologia_objeto|tipo_tecnica|unidades_medidas|unidades_peso|tip
o_formato|nombre_formato_imagen|arquitectura|hay_sonido|sonido_nombre_formato|son
ido_muestreo|sonido_amplitud|sonido_idioma_original|pais_publicacion))|((barcode)
:((\_[ABC]){0,1}(\((\d+)\)){0,1}(\{(codigo_doa|titulo_obra|titulo_alternativo|num
_serie|ejemplar_serie|ejemplares_obra|nombre_tecnica|materiales_soporte|medidas_d
iametro|lista_artistas|medidas_peso|medidas_resolucion|epoca_corriente|medidas_mi
nutaje|color|sonido_canales|numero_normalizado|valor|fecha_creacion|medidas_longi
tud|es_firmado|exactitud_fecha|tipo_obra|tipologia_objeto|tipo_tecnica|unidades_m
edidas|unidades_peso|tipo_formato|nombre_formato_imagen|arquitectura|hay_sonido|sonido_nombre_forma
to|sonido_muestreo|sonido_amplitud|sonido_idioma_original|pais_publicacion)\}){1,
45}))/";

$subject = "  Tipo de
objeto / Type of object:  field:tipologia_objeto
(field:tipo_obra)   Objeto de arte
registrado en AICOA / Work of art registered in AICOA:  field:codigo_doa   Título de la obra (Título alternativo) / Title
(Alternative title):  field:titulo_obra
(field:titulo_alternativo)   Autor / Author:  field:lista_artistas   Fecha realización / Date or period:  field:fecha_creacion (field:exactitud_fecha) 
 Escuela, corriente estilística / School,
art movement:  field:epoca_corriente 
 Datos de la serie / Serial Number: 
field:ejemplar_serie / field:ejemplares_obra --
serie: field:num_serie   Características del formato / Format
characteristics:  field:tipo_tecnica ,
resolución: field:medidas_resolucion   Técnica / Technique: field:nombre_tecnica   Materiales-Soporte / Material-Support: field:materiales_soporte   Medidas / dimensions: 
field:medidas_longitud field:unidades_medidas // Ø
field:medidas_diametro field:unidades_medidas // field:medidas_peso
field:unidades_pesoFirmado /
Signed field:es_firmado  "

The function breaks down giving this message:

Warning: preg_match_all() [function.preg-match-all]: Compilation
failed: repeated subpattern is too long at offset 1153 in
/home/.../dcombs_controller.php on line 723

Warning: preg_match_all() [function.preg-match-all]: Compilation
failed: repeated subpattern is too long at offset 1153 in
/home/.../dcombs_controller.php on line 723

We don't know if this is a bug, but we haven't seen any change related
to this on the 5.2.0 changelog. Just in case this could be a variable
size limitat

#34748 [Com]: soap: wrong encoding return

[andy at gleep dot org]

 ID:   34748
 Comment by:   andy at gleep dot org
 Reported By:  flobee at gmail dot com
 Status:   No Feedback
 Bug Type: SOAP related
 Operating System: xp/*nix
 PHP Version:  5.1.0RC1
 New Comment:

Additionally, I'm having problems with the Content-type being set like
so:
Content-Type: application/soap+xml; charset=UTF-8;
action="urn:LAS_PROVTRANS/GetListOperation"

The SOAP Server that I'm using (Remedy Mid-Tier) doesn't like that
string and thinks that the encoding is being set to 'UTF-8;
action="urn:LAS_PROVTRANS/GetListOperation" which it doesn't like at
all.

Maybe it's a matter of putting quotes around the UTF-8 piece?  I got it
to send the UTF-8 in capitals by manually editing the shared library to
see if that would fix it.


Previous Comments:


[2006-11-07 16:27:37] andy at gleep dot org

The utf-8 is hard coded in soap.c so it's not even configurable.

[EMAIL PROTECTED] soap]$ grep -n utf *.c
php_encoding.c:763: soap_error1(E_ERROR, 
"Encoding: string '%s' is not a valid utf-8 string", str);
php_encoding.c:768: soap_error1(E_ERROR,  "Encoding: string
'%s' is not a valid utf-8 string", str);
php_http.c:443:
smart_str_append_const(&soap_headers,"Content-Type:
application/soap+xml; charset=utf-8");
php_http.c:451:
smart_str_append_const(&soap_headers,"Content-Type: text/xml;
charset=utf-8\r\n");
soap.c:1444:sapi_add_header("Content-Type:
text/xml; charset=utf-8", sizeof("Content-Type: text/xml;
charset=utf-8")-1, 1);
soap.c:1460:sapi_add_header("Content-Type:
text/xml; charset=utf-8", sizeof("Content-Type: text/xml;
charset=utf-8"), 1);
soap.c:1859:sapi_add_header("Content-Type:
application/soap+xml; charset=utf-8", sizeof("Content-Type:
application/soap+xml; charset=utf-8")-1, 1);
soap.c:1861:sapi_add_header("Content-Type:
text/xml; charset=utf-8", sizeof("Content-Type: text/xml;
charset=utf-8")-1, 1);
soap.c:1988:sapi_add_header("Content-Type:
application/soap+xml; charset=utf-8", sizeof("Content-Type:
application/soap+xml; charset=utf-8")-1, 1);
soap.c:1990:sapi_add_header("Content-Type: text/xml;
charset=utf-8", sizeof("Content-Type: text/xml; charset=utf-8")-1, 1);

This is causing me major problems with 5.1.2 but it's still like that
in 5.2.0



[2006-09-13 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2006-09-05 18:24:09] even at phoniax dot no

I have the same problem in 5.1.4 on a CentOS server.

You can use this WSDL for testing: 
http://webservices.iptelefoni.no/?class=OrderManager&wsdl

The output from __getLastRequest outputs that it requests 
encoding in UTF-8.

Even when I PEAR's Soap Client (which _do_ send the correct 
encoding) the PHP 5.1.4 SoapServer returns the XML in utf8 
encoding.

Both server and client has been set the option for encoding 
to ISO-8859-1.



[2005-10-14 01:00:04] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2005-10-06 15:30:36] [EMAIL PROTECTED]

And where can I find the a.wsdl ?



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

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

#39415 [NEW]: C ompilation failure on preg_match_all()

[jordi at telematictraining dot com]

From: jordi at telematictraining dot com
Operating system: Debian GNU/Linux Stable
PHP version:  5.2.0
PHP Bug Type: Compile Failure
Bug description:  C ompilation failure on preg_match_all()

Description:

Hi there,

What we did? Update php 5.1.6 to 5.2.0.
What we wanted to happen? We expected the 5.2.0 version to behave/work as
the previous ones (5.1.2, 5.1.4 and 5.1.6).
What actualy happened? It didn't.

We have a php based app and we've been working since php version 5.1.2.
But with this new version (5.2.0) it seems to be a problem with the
preg_match_all() function.

Being the function call preg_match_all(string $pattern, string $subject,
array $coincidences), this are the values of the variables:

$pattern =
"/((field):(codigo_doa|titulo_obra|titulo_alternativo|num_serie|ejemplar_serie|ej
emplares_obra|nombre_tecnica|materiales_soporte|medidas_diametro|lista_artistas|m
edidas_peso|medidas_resolucion|epoca_corriente|medidas_minutaje|color|sonido_cana
les|numero_normalizado|valor|fecha_creacion|medidas_longitud|es_firmado|exactitud
_fecha|tipo_obra|tipologia_objeto|tipo_tecnica|unidades_medidas|unidades_peso|tip
o_formato|nombre_formato_imagen|arquitectura|hay_sonido|sonido_nombre_formato|son
ido_muestreo|sonido_amplitud|sonido_idioma_original|pais_publicacion))|((barcode)
:((\_[ABC]){0,1}(\((\d+)\)){0,1}(\{(codigo_doa|titulo_obra|titulo_alternativo|num
_serie|ejemplar_serie|ejemplares_obra|nombre_tecnica|materiales_soporte|medidas_d
iametro|lista_artistas|medidas_peso|medidas_resolucion|epoca_corriente|medidas_mi
nutaje|color|sonido_canales|numero_normalizado|valor|fecha_creacion|medidas_longi
tud|es_firmado|exactitud_fecha|tipo_obra|tipologia_objeto|tipo_tecnica|unidades_m
edidas|unidades_peso|tipo_formato|nombre_formato_imagen|arquitectura|hay_sonido|sonido_nombre_forma
to|sonido_muestreo|sonido_amplitud|sonido_idioma_original|pais_publicacion)\}){1,
45}))/";

$subject = "  Tipo de
objeto / Type of object:  field:tipologia_objeto
(field:tipo_obra)   Objeto de arte
registrado en AICOA / Work of art registered in AICOA:  field:codigo_doa   Título de la obra (Título alternativo) / Title
(Alternative title):  field:titulo_obra
(field:titulo_alternativo)   Autor /
Author:  field:lista_artistas   Fecha realización / Date or period:  field:fecha_creacion (field:exactitud_fecha)  
Escuela, corriente estilística / School, art
movement:  field:epoca_corriente  
Datos de la serie / Serial Number:  field:ejemplar_serie / field:ejemplares_obra -- serie:
field:num_serie   Características
del formato / Format characteristics:  field:tipo_tecnica , resolución:
field:medidas_resolucion   Técnica /
Technique: field:nombre_tecnica   Materiales-Soporte / Material-Support: field:materiales_soporte   Medidas / dimensions: 
field:medidas_longitud field:unidades_medidas // Ø field:medidas_diametro
field:unidades_medidas // field:medidas_peso field:unidades_peso 
  Firmado / Signed field:es_firmado  "

The function breaks down giving this message:

Warning: preg_match_all() [function.preg-match-all]: Compilation failed:
repeated subpattern is too long at offset 1153 in
/home/.../dcombs_controller.php on line 723

Warning: preg_match_all() [function.preg-match-all]: Compilation failed:
repeated subpattern is too long at offset 1153 in
/home/.../dcombs_controller.php on line 723

We don't know if this is a bug, but we haven't seen any change related to
this on the 5.2.0 changelog. Just in case this could be a variable size
limitation (of 1024?), the $pattern is 1158 characters long and the
$subject is 1738 charachers.


Reproduce code:
---
See description.

Configure line: ./configure --prefix=/usr/local
--with-config-file-path=/usr/local/etc --with-apxs2=/usr/bin/apxs2
--with-mod_charset --with-openssl --with-kerberos --with-zlib
--enable-bcmath --with-bz2 --enable-calendar --with-curl
--with-curlwrappers --with-gd --with-ttf --enable-gd-native-ttf
--with-gettext --with-mcrypt --with-mysql --with-mysqli --with-snmp
--enable-wddx-with-xmlrpc --with-xsl --enable-sysvmsg --enable-sysvsem
--enable-sysvshm --with-freetype-dir --with-xml --with-libxml
--with-expat-dir --with-xmlrpc --enable-soap --enable-mbstring
--enable-mbstr-enc-trans --with-pgsql --with-tidy

Other configure options are removing --with-tidy.


Expected result:

The the preg_match_all() to work as it did on all 5.x php versions until
the date (except for 5.2.0).

Actual result:
--
Warning: preg_match_all() [function.preg-match-all]: Compilation failed:
repeated subpattern is too long at offset 1153 in
/home/.../dcombs_controller.php on line 723

Warning: preg_match_all() [function.preg-match-all]: Compilation failed:
repeated subpattern is too long at offset 1153 in
/home/.../dcombs_controller.php on line 723

-- 
Edit bug report at http://bugs.php.net/?id=39415&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39415&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http

#34748 [Com]: soap: wrong encoding return

[andy at gleep dot org]

 ID:   34748
 Comment by:   andy at gleep dot org
 Reported By:  flobee at gmail dot com
 Status:   No Feedback
 Bug Type: SOAP related
 Operating System: xp/*nix
 PHP Version:  5.1.0RC1
 New Comment:

The utf-8 is hard coded in soap.c so it's not even configurable.

[EMAIL PROTECTED] soap]$ grep -n utf *.c
php_encoding.c:763: soap_error1(E_ERROR, 
"Encoding: string '%s' is not a valid utf-8 string", str);
php_encoding.c:768: soap_error1(E_ERROR,  "Encoding: string
'%s' is not a valid utf-8 string", str);
php_http.c:443:
smart_str_append_const(&soap_headers,"Content-Type:
application/soap+xml; charset=utf-8");
php_http.c:451:
smart_str_append_const(&soap_headers,"Content-Type: text/xml;
charset=utf-8\r\n");
soap.c:1444:sapi_add_header("Content-Type:
text/xml; charset=utf-8", sizeof("Content-Type: text/xml;
charset=utf-8")-1, 1);
soap.c:1460:sapi_add_header("Content-Type:
text/xml; charset=utf-8", sizeof("Content-Type: text/xml;
charset=utf-8"), 1);
soap.c:1859:sapi_add_header("Content-Type:
application/soap+xml; charset=utf-8", sizeof("Content-Type:
application/soap+xml; charset=utf-8")-1, 1);
soap.c:1861:sapi_add_header("Content-Type:
text/xml; charset=utf-8", sizeof("Content-Type: text/xml;
charset=utf-8")-1, 1);
soap.c:1988:sapi_add_header("Content-Type:
application/soap+xml; charset=utf-8", sizeof("Content-Type:
application/soap+xml; charset=utf-8")-1, 1);
soap.c:1990:sapi_add_header("Content-Type: text/xml;
charset=utf-8", sizeof("Content-Type: text/xml; charset=utf-8")-1, 1);

This is causing me major problems with 5.1.2 but it's still like that
in 5.2.0


Previous Comments:


[2006-09-13 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2006-09-05 18:24:09] even at phoniax dot no

I have the same problem in 5.1.4 on a CentOS server.

You can use this WSDL for testing: 
http://webservices.iptelefoni.no/?class=OrderManager&wsdl

The output from __getLastRequest outputs that it requests 
encoding in UTF-8.

Even when I PEAR's Soap Client (which _do_ send the correct 
encoding) the PHP 5.1.4 SoapServer returns the XML in utf8 
encoding.

Both server and client has been set the option for encoding 
to ISO-8859-1.



[2005-10-14 01:00:04] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2005-10-06 15:30:36] [EMAIL PROTECTED]

And where can I find the a.wsdl ?



[2005-10-06 15:22:06] flobee at gmail dot com

[server]
theServerClass {
 function __construct() { }
 function set($in) {
  return array('code'=>'€€€');
 }
}
$server = new SoapServer('a.wsdl',array('encoding'=>'ISO-8859-1'));
$server->setClass('theServerClass');
$server->handle();

[client]
$cli = new SoapClient('a.wsdl',
array('encoding'=>'ISO-8859-1','soap_version'=> SOAP_1_2, 'trace'=>
1));
$result = $cli->set('somthing');
print_r($cli->__getLastResponse());

...
xml-Response:  
but IS ISO-8859-1

set encoding to utf-8 the "€" will throw a SoapFault.



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

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

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

[s dot s at terra dot com dot br]

 ID:   39384
 Comment by:   s dot s at terra dot com dot br
 Reported By:  cw264701 at ohiou dot edu
 Status:   Open
 Bug Type: Class/Object related
 Operating System: Ubuntu Linux
 PHP Version:  5.2.0
 New Comment:

OK. You are right about the documentation, reading it again I got you
point and it induce to unset values of the object when the __sleep()
method is called.

>From documentation:
"*It can clean up the object* and is supposed to return an array with
the names of all variables of that object that should be serialized."

May this bug can be related to the documentation than the serialization
or object architecture.

About change the serialization paradigm some problems that can get you
into trouble serializing objects as "C" are: resources and references
to other objects.

Think that your object hold a connection with database, when you
serialize it this connection *should* be represented in some way or
stored as a "C pointer". But when you unserialize, in other request to
your httpd server, this resource *should* be restored and if its stored
as a "C pointer" I think it will cause a segfault when you try to access
this connection again, due to a read try on a memory segment that will
have another informations thats not the database connection reference
anymore or its owned by other process.

Same for object references. Where you have other problems such as
recursion and/or cyclic references.

I don't really known how to store the reference "state" and I think
storing it can lead to problems too. Think in a opened file in read or
write mode. If the parser are able to store its "state" and restore it,
the pre-requisite is that this file *should* exist and maybe unmodified
due to internal file seek pointer. In the database case you need to get
special care with user and password to database or it can lead to a
security issue if you try to save something like the Pear DSN to
represent the database connection.


Previous Comments:


[2006-11-06 15:27:22] cw264701 at ohiou dot edu

Yes, I understand that I need not set the "table" attribute to null. 
This was a bad example; sorry.

My complaint isn't about a specific case of using serialize() and the
magic __sleep() function.  I am complaining that the whole concept is
flawed.  The PHP documentation is encouraging users to define this
__sleep() function and, thus, modify their objects before they are
serialized.  This is kind of silly, because, when we serialize() an
object, that exact object is not being serialized, *itself*, but a
*serialized representation* of that object is being formed (and stored
as a string).  The intent of the __sleep() function is good: to allow
some control over what is actually stored for a serialized version of
an object.  The problem is, it can have *side effects*.

This really becomes a problem when you are working with a class that
you didn't write.  For example, I am using ezpdo.  I carelessly (which
should be okay in this case) serialize()'d one of my ezpdo-mapped
objects before I was finished using it; things blew up.  It shouldn't
be "wrong" for me to do something like this:
  $_SESSION['purchase'] = serialize($myPurchaseObject);
  $smarty->assign('purchase', $myPurchaseObject);
There, I attempt to store away my object in the session, just before I
pass it off to my template engine for view rendering.  Perhaps this
technique would be considered bad practice (to a PHP guru/developer),
but that shouldn't leave me in the dark with some broken code.  When I
use a class, I want to program to its *interface*, not an
implementation; I shouldn't have to care whether or not it happens to
define a __sleep() function, and therefore cannot be used after it has
been passed to a call to serialize().

I understand the value of __sleep(), but I think the whole
serialization library/interface needs re-thinking.  I suggest one of
three solutions:
 - When an object, O, is serialize()'d, PHP could create an exact copy
of that object (a "shallow copy", I believe), let's say C.  PHP would
then call __sleep() for the new object, C, and serialize that instance
of the class.  This technique seems slightly risky, though, because we
have to depend on the class' __sleep() function to not directly modify
any of its referenced objects, but rather rely on those references to
use their own __sleep() functions to do any cleaning up; the class
shouldn't directly modify its references, but who knows...
 - Call an object's __wakeup() method after a serialized representation
has been formed but before returning from the serialize() function. 
This method might be wasteful in many cases (where the object was never
again used after serialization), but better safe than sorry.  Perhaps
the __wakeup() function could be called on the object only if an
attempt is made to "use it" after the call to serialize().
 - The quick-n-dirty solution would be 

#39414 [Opn->Csd]: Syntax error while compiling with Sun Workshop Complier 5

[johannes]

 ID:   39414
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bintz at stsci dot edu
-Status:   Open
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: Solaris 2.8
 PHP Version:  5.2.0
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


Previous Comments:


[2006-11-07 15:10:40] bintz at stsci dot edu

Description:

The Sun Workshop version 5.0 compiler returns a syntax error on
ext/spl/spl_iterators.c line 1484 of the 5.2.0 source release:

return;// NULL

Removing the comment allows the compile to finish successfully.  This
has already been fixed in CVS, but still exists in the stable release
available on the main site.






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

#39414 [NEW]: Syntax error while compiling with Sun Workshop Complier 5

[bintz at stsci dot edu]

From: bintz at stsci dot edu
Operating system: Solaris 2.8
PHP version:  5.2.0
PHP Bug Type: Compile Failure
Bug description:  Syntax error while compiling with Sun Workshop Complier 5

Description:

The Sun Workshop version 5.0 compiler returns a syntax error on
ext/spl/spl_iterators.c line 1484 of the 5.2.0 source release:

return;// NULL

Removing the comment allows the compile to finish successfully.  This has
already been fixed in CVS, but still exists in the stable release
available on the main site.


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

#38536 [Opn->Asn]: Returning an array of values instead of an object

[dmitry]

 ID:   38536
 Updated by:   [EMAIL PROTECTED]
 Reported By:  sabrina at corp dot grupos dot com dot br
-Status:   Open
+Status:   Assigned
 Bug Type: SOAP related
 Operating System: FreeBSD 6.1
 PHP Version:  PHP_5_2 cvs
-Assigned To:  
+Assigned To:  dmitry


Previous Comments:


[2006-11-07 14:06:51] sabrina at corp dot grupos dot com dot br

reopen



[2006-09-01 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2006-08-24 08:06:57] [EMAIL PROTECTED]

We still need a short reproduce script without private services and
fatal errors.



[2006-08-22 14:43:55] sabrina at corp dot grupos dot com dot br

unfortunately, you cannot execute this code as it is, because the
webservice in question is private and cannot be accessed externarly or
without authentication.

the line:
$return = $SOAPObject->__soapCall('getClientInfoFromDomain',
'sabrina.corp.grupos.com.br');
is incorrect, and should be:
$return = $SOAPObject->__soapCall('getClientInfoFromDomain',
array('sabrina.corp.grupos.com.br'));

but other than that, you could either try to access a webservice that
returns an array of objects or read the
the result dumps of this script for versions 5.1.4 and 5.1.5 
(you can check these files 
http://intranet.grupos.com.br/~sabrina/phpbug/phpreply515.html
http://intranet.grupos.com.br/~sabrina/phpbug/phpreply514.html
) and see that there is a big difference between both responses.

thank you for your replies.



[2006-08-22 13:51:31] [EMAIL PROTECTED]


Notice: Undefined variable: newIp in /tmp/1.php on line 4

Warning: SoapClient::__soapCall() expects parameter 2 to be array,
string given in /tmp/1.php on line 14

Fatal error: SoapClient::__soapCall(): Invalid parameters in /tmp/1.php
on line 14




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

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

#39349 [Opn->Fbk]: Core dump on preg_replace

[edink]

 ID:   39349
 Updated by:   [EMAIL PROTECTED]
 Reported By:  nikolas dot hagelstein at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Netbsd 3.0.1
 PHP Version:  5.2.0
 New Comment:

You probably run out of stack.

You can try increasing your stack size and trying again on the command
line with:

uname -s 16384

for example. If that's what your problem is you can compile an external
PCRE that will not use stack but heap (and be slower in the process).
You can do that by compiling PCRE using --disable-stack-for-recursion
option.



Previous Comments:


[2006-11-03 13:03:32] nikolas dot hagelstein at gmail dot com

I was able to narrow down the problem to the following it seems to be
size/overflow related:


This Coredumps but if i reduce the string by one char (ie the 'r') it
stops coredumping.



[2006-11-02 21:14:29] nikolas dot hagelstein at gmail dot com

Description:

Passing large text to the beyond mentioned regexp makes php core dump

Reproduce code:
---
$out=preg_replace("/\{(?:[^{}]|\{(?:[^{}]|\{(?:[^{}]|\{[^{}]*\})*\})*\})*\}/","",$out);

Where $out isof
http://en.wikipedia.org/w/query.php?what=content&titles=moon

Probably related to some libc issues.








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

#39412 [Csd]: base64_decode does not return FALSE on failure

[phpbugs at staznosti dot sk]

 ID:   39412
 User updated by:  phpbugs at staznosti dot sk
 Reported By:  phpbugs at staznosti dot sk
 Status:   Closed
 Bug Type: *URL Functions
 Operating System: Linux
 PHP Version:  4.4.4
 New Comment:

I think this should get fixed in 4.x branch, too, as many people don't
want (you can guess why - incompatiblity 4.x/5.x is the thing) or are
not able to switch.


Previous Comments:


[2006-11-07 14:20:21] [EMAIL PROTECTED]

Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php

Will not get fixed in 4.4, but already fixed in 5.2.

php -r 'var_dump(base64_decode("This is short string!", 
true));'
bool(false)



[2006-11-07 10:01:35] phpbugs at staznosti dot sk

Description:

base64_decode does not return FALSE on failure, return garbled (binary)
text instead

Reproduce code:
---
$string="This is short string!";

$test=base64_decode($string);

if ($test===FALSE) echo 'text is not base64 encoded';
else echo $test;

Expected result:

FALSE should be returned

Actual result:
--
garbled text / binary string





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

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

[bjori]

 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.4.4
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip




Previous Comments:


[2006-11-04 16:15:33] sanjib dot biswas at ieee dot org

n/a



[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

#39380 [Opn->Asn]: php crashes in preg_match

[edink]

 ID:   39380
 Updated by:   [EMAIL PROTECTED]
 Reported By:  corinl at gmx dot de
-Status:   Open
+Status:   Assigned
 Bug Type: Scripting Engine problem
 Operating System: linux debian
 PHP Version:  5.2.0
-Assigned To:  
+Assigned To:  andrei


Previous Comments:


[2006-11-04 17:14:01] corinl at gmx dot de

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 this bug report at http://bugs.php.net/?id=39380&edit=1

#39385 [Opn->Csd]: International friendly mktime alternative

[bjori]

 ID:   39385
 Updated by:   [EMAIL PROTECTED]
 Reported By:  thehub at lofty dot net dot au
-Status:   Open
+Status:   Closed
 Bug Type: *Languages/Translation
 Operating System: any
 PHP Version:  4.4.4
 New Comment:

Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php

Have a look at the DateTime object in 5.2.0
(will not be fixed in PHP4).


Previous Comments:


[2006-11-04 21:00:55] thehub at lofty dot net dot au

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 this bug report at http://bugs.php.net/?id=39385&edit=1

#39387 [Opn->Asn]: preg_match/replace segfaults on certain user data.

[bjori]

 ID:   39387
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at vicaya dot com
-Status:   Open
+Status:   Assigned
 Bug Type: PCRE related
 Operating System: Linux/amd64
 PHP Version:  5.2.0
-Assigned To:  
+Assigned To:  andrei


Previous Comments:


[2006-11-05 00:49:43] php at vicaya dot com

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 this bug report at http://bugs.php.net/?id=39387&edit=1

#39394 [Opn->Asn]: Make failed with openssl compilation option

[bjori]

 ID:   39394
 Updated by:   [EMAIL PROTECTED]
 Reported By:  david dot bourgeois at gmail dot com
-Status:   Open
+Status:   Assigned
 Bug Type: Compile Failure
 Operating System: Red Hat 7.2
 PHP Version:  5.2.0
-Assigned To:  
+Assigned To:  pajoye


Previous Comments:


[2006-11-06 14:20:03] sysadmin at rollerscapes dot net

Update OpenSSL, its noted in the Manuel you always must use the latest
version!



[2006-11-06 08:32:57] david dot bourgeois at gmail dot com

Description:

Hi,

I have a pb with compil of php 5.2.0 (previous versions of PHP5 work
fine with the same compilation options).

When I compile php 5.2.0 without openssl option, there is no problem.

openssl version : 0.9.6m
Compilation of PHP as a module with Apache 2.2.3


Reproduce code:
---
You can see the configure options here :

http://www.dlnet-inter.fr/compil-failed.txt

Actual result:
--
ext/openssl/.libs/openssl.o: In function
`php_openssl_generate_private_key':
/home/src/php-5.2.0/ext/openssl/openssl.c:2063: undefined reference to
`DSA_get_default_method'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Erreur 1





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

#39396 [Opn->Asn]: stream_set_blocking crashes

[bjori]

 ID:   39396
 Updated by:   [EMAIL PROTECTED]
 Reported By:  maurice at iceblog dot de
-Status:   Open
+Status:   Assigned
 Bug Type: Streams related
 Operating System: Windows XP
 PHP Version:  5.2.0
-Assigned To:  
+Assigned To:  pollita


Previous Comments:


[2006-11-06 16:19:29] maurice at iceblog dot de

stream_socket_client should at least return FALSE or an error if you
just use STREAM_CLIENT_ASYNC_CONNECT without STREAM_CLIENT_CONNECT.



[2006-11-06 10:33:33] maurice at iceblog dot de

Description:

When you use stream_socket_client with asynchronous connect
(STREAM_CLIENT_ASYNC_CONNECT), but do not specify STREAM_CLIENT_CONNECT
then stream_set_blocking will crash PHP on Windows XP.

The documentation does NOT tell you to use
STREAM_CLIENT_ASYNC_CONNECT | STREAM_CLIENT_CONNECT.

I think STREAM_CLIENT_ASYNC_CONNECT should implicate
STREAM_CLIENT_CONNECT.

-- Possibility 1 to fix implication -

#define STREAM_XPORT_CONNECT 2 
#define STREAM_XPORT_CONNECT_ASYNC   18  // instead of 16

#define PHP_STREAM_CLIENT_CONNECT4
#define PHP_STREAM_CLIENT_ASYNC_CONNECT  6  // instead of 2
 
-- Possibility 2 to fix "implication" ---

Patch for 5.2.0 source (not CVS).

--- transports.c2006-01-01 13:50:18.0 +0100
+++ transports-maurice.c2006-11-06 11:18:49.0 +0100
@@ -136,7 +136,7 @@
if ((flags & STREAM_XPORT_SERVER) == 0) {
/* client */
 
-   if (flags & STREAM_XPORT_CONNECT) {
+   if (flags & STREAM_XPORT_CONNECT || flags &
STREAM_XPORT_CONNECT_ASYNC) {
if (-1 == php_stream_xport_connect(stream, 
name, namelen,
flags & 
STREAM_XPORT_CONNECT_ASYNC ? 1 : 0,
timeout, &error_text, 
error_code TSRMLS_CC)) { 

-

There are other (somehow) related bugs:
http://bugs.php.net/bug.php?id=30386
http://bugs.php.net/bug.php?id=28245





Reproduce code:
---
\n";

} else {

var_dump(stream_set_blocking($fp, false));

fclose($fp);

}

?>


Expected result:

If you do not specify STREAM_CLIENT_CONNECT in stream_socket_client the
socket never ever gets connected. Thus, stream_set_blocking should
return FALSE and throw an E_WARNING.
However, as this is a stream function and the stream is still
considered "valid", TRUE might also be all right.

Under Debian Linux (Sarge, Kernel 2.6.8) stream_set_blocking returns
TRUE (which I think is misleading).


Actual result:
--
Crashes under Windows XP; returns TRUE on Linux.





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

#39400 [Opn->Asn]: More differences beetween functions and the mbstring versions

[bjori]

 ID:   39400
 Updated by:   [EMAIL PROTECTED]
 Reported By:  christoph at ziegenberg dot de
-Status:   Open
+Status:   Assigned
 Bug Type: mbstring related
 Operating System: Win XP
 PHP Version:  5.2.0
-Assigned To:  
+Assigned To:  hirokawa
 New Comment:

Assigned to maintainer


Previous Comments:


[2006-11-06 15:47:54] christoph at ziegenberg dot de

Point "different behaviour between a function and the case-insensitive
version" isn't right, I meant the difference between stripos() and
strripos() (which behave equal in the mbstring version).



[2006-11-06 13:21:54] christoph at ziegenberg dot de

Description:

I posted a bug for the wrong behaviour of mb_strstr() compared to
strstr() before - this has been fixed, but also the other functions
behave different.

Here a code to see more differences: 

- different behaviours between functions and the mbstring versions,
- different error messages and 
- different behaviour between a function and the case-insensitive
version

Reproduce code:
---
');
stripos('', ',', 0);
mb_stripos('', ',', 0);

print('stripos (offest > length):');
stripos('1', ',', 3);
mb_stripos('1', ',', 3);

print('strripos (empty haystack):');

strripos('', ',', 0);
mb_strripos('', ',', 0);

print('strripos (offest > length):');
strripos('1', ',', 3);
mb_strripos('1', ',', 3);

print('stristr (empty haystack):');
stristr('', ',');
mb_stristr('', ',');

print('strrichr (empty haystack):');
strrchr('', ',');
mb_strrchr('', ',');
?>

Expected result:

stripos (empty haystack):

stripos (offest > length):

[same error message, dunno which is the better one - they mean the
same, but it would be better to get the same text. or no error as in
strripos(), see below.]

strripos (empty haystack):

strripos (offest > length):

[same as for stripos() - strripos() returns no error here]

stristr (empty haystack):

strrichr (empty haystack):

Actual result:
--
stripos (empty haystack):

Warning: mb_stripos() [function.mb-stripos]: Empty haystack in
W:\www\mb_functions.php on line 4

stripos (offest > length):

Warning: stripos() [function.stripos]: Offset not contained in string.
in W:\www\mb_functions.php on line 7

Warning: mb_stripos() [function.mb-stripos]: Offset is out of range in
W:\www\mb_functions.php on line 8

strripos (empty haystack):

Warning: mb_strripos() [function.mb-strripos]: Empty haystack in
W:\www\mb_functions.php on line 13

strripos (offest > length):

Warning: mb_strripos() [function.mb-strripos]: Offset is out of range
in W:\www\mb_functions.php on line 17

stristr (empty haystack):

Warning: mb_stristr() [function.mb-stristr]: Empty haystack in
W:\www\mb_functions.php on line 21

strrichr (empty haystack):

Warning: mb_strrchr() [function.mb-strrchr]: Empty haystack in
W:\www\mb_functions.php on line 25





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

#39404 [Opn->Asn]: Support "entity" as substitute_character setting

[bjori]

 ID:  39404
 Updated by:  [EMAIL PROTECTED]
 Reported By: martin dot t dot kutschker at blackbox dot net
-Status:  Open
+Status:  Assigned
-Bug Type:mbstring related
+Bug Type:Feature/Change Request
 PHP Version: 5.2.0
-Assigned To: 
+Assigned To: hirokawa
 New Comment:

Reclassified as feature request & assigned to maintainer.


Previous Comments:


[2006-11-06 17:09:37] martin dot t dot kutschker at blackbox dot net

Fix spelling of "entity" in the summary.



[2006-11-06 16:56:19] martin dot t dot kutschker at blackbox dot net

Description:

It would be great if the charset conversion could also output SGML/HTML
entites for missing characters in the output charset. The option "long"
is not very HTML-friendly. But with "entity" any Unicode aware browser
could deal with the missing charater.

eg
mbstring.substitute_character=long => U+3000
mbstring.substitute_character=entity => 　







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

#39408 [Opn->Bgs]: the Implements keyword

[bjori]

 ID:   39408
 Updated by:   [EMAIL PROTECTED]
 Reported By:  allen dot arbeau at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Class/Object related
 Operating System: Windows 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.

Make sure your webserver is running php5.
Regarding Dreamweaver highlighting, file a bug report to 
them.


Previous Comments:


[2006-11-06 22:57:11] allen dot arbeau at gmail dot com

Description:

I am using PHP 5.2.0, Dreamweaver 8 and IE 7. I receive an error on the
webpage pointing to my TextBox class (line 5) when I attempt to use the
keyword "implements" in that class.

Reproduce code:
---
(The line numbers are for reference only and are not actually in the
class.)

--Element.php
1 
-



--TextBox.php
1 
-





Expected result:

I expect the application to recognize the keyword "implements" as a
valid keyword. In the case of Dreamweaver it should color code the word
"interface" as a keyword but it does not which suggests it does not
recognize "implements" as a valid keyword such as "extends" or "class".

Actual result:
--
I get the error: 

"Parse error: syntax error, unexpected T_STRING, expecting T_VARIABLE
in subscribers_kiosk/baseclass/TextBox.php on line 5"

on the webpage when I try to include the "TextBox.php" page into any
other php page.






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

#39407 [Asn->Csd]: Swapped Upload and Session Directory

[jmertic]

 ID:   39407
 Updated by:   [EMAIL PROTECTED]
 Reported By:  eoghan at loggedin dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: IIS related
 Operating System: XP SP2
 PHP Version:  5.2.0
 Assigned To:  jmertic
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2006-11-06 21:40:45] eoghan at loggedin dot com

Description:

When you run the windows installer and choose IIS4+ CGI, it seems to
swap the values for the session directory and the uploads directory in
the php.ini file when it's created.

In php.ini it has

upload_tmp_dir="C:\DOCUME~1\Eoghan\LOCALS~1\Temp\php\session"
session.save_path="C:\DOCUME~1\Eoghan\LOCALS~1\Temp\php\upload"

and I think they're probably meant to be swapped i.e.

upload_tmp_dir="C:\DOCUME~1\Eoghan\LOCALS~1\Temp\php\upload"
session.save_path="C:\DOCUME~1\Eoghan\LOCALS~1\Temp\php\session"

Not a biggie, probably wouldn't really stop things functioning in most
cases, but just thought you might want to know.

Eoghan.






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

#39410 [Asn->Csd]: Installation on CGI mode fails

[jmertic]

 ID:   39410
 Updated by:   [EMAIL PROTECTED]
 Reported By:  gschizas at gmail dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: IIS related
 Operating System: Windows 2003
 PHP Version:  5.2.0
 Assigned To:  jmertic
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2006-11-07 08:07:18] gschizas at gmail dot com

Description:

While installing (with the installer) in CGI Mode (Windows 2003 SP1,
IIS6), I get an error message at the end of the installation (There is
a problem with this Windows Installer Package)

Reproduce code:
---
Event Viewer shows this:

Product: PHP 5.2.0 -- Error 1721. There is a problem with this Windows
Installer package. A program required for this install to complete
could not be run. Contact your support personnel or package vendor.
Action: iisextVBS, location: C:\Program Files\PHP\, command:
"C:\WINDOWS\system32\iisext.vbs" /AddFile "C:\Program
Files\PHP\php-cgi.exe" 


I found this again as Bug #26185, for PHP 4.2.1, but obviously it
reared its ugly head again (#26185 is closed, but the behavior
persists).

Expected result:

Installation not producing any error messages, and registering PHP in
"Web Service Extensions"

Actually this is probably a problem with the fact iisext.vbs requires
more parameters in Windows 2003. So instead of
"C:\WINDOWS\system32\iisext.vbs" /AddFile "C:\Program
Files\PHP\php-cgi.exe",
you should type
"C:\WINDOWS\system32\iisext.vbs" /AddFile "C:\Program
Files\PHP\php-cgi.exe" 1 PHP 1 "PHP: Hypertext Processor"

Use iisext.vbs /? to see the meaning of the parameters.

The installer needs to be fixed.

Actual result:
--
Installation produced the error message, PHP was not registered, but
all other things seemed to go well.





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

#39412 [Opn->Csd]: base64_decode does not return FALSE on failure

[bjori]

 ID:   39412
 Updated by:   [EMAIL PROTECTED]
 Reported By:  phpbugs at staznosti dot sk
-Status:   Open
+Status:   Closed
 Bug Type: *URL Functions
 Operating System: Linux
 PHP Version:  4.4.4
 New Comment:

Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php

Will not get fixed in 4.4, but already fixed in 5.2.

php -r 'var_dump(base64_decode("This is short string!", 
true));'
bool(false)


Previous Comments:


[2006-11-07 10:01:35] phpbugs at staznosti dot sk

Description:

base64_decode does not return FALSE on failure, return garbled (binary)
text instead

Reproduce code:
---
$string="This is short string!";

$test=base64_decode($string);

if ($test===FALSE) echo 'text is not base64 encoded';
else echo $test;

Expected result:

FALSE should be returned

Actual result:
--
garbled text / binary string





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

#39344 [Opn->Asn]: Unnecessary calls to OnModify callback routine for an extension INI directive

[edink]

 ID:   39344
 Updated by:   [EMAIL PROTECTED]
 Reported By:  wharmby at uk dot ibm dot com
-Status:   Open
+Status:   Assigned
 Bug Type: Scripting Engine problem
 Operating System: Windows XP
 PHP Version:  5CVS-2006-11-02 (snap)
-Assigned To:  
+Assigned To:  dmitry


Previous Comments:


[2006-11-03 09:03:38] wharmby at uk dot ibm dot com

Correcting version; behaviour was observed in V5 not V4



[2006-11-02 11:10:56] wharmby at uk dot ibm dot com

Description:

Unnecessary calls to OnModify callback routine for an
extension INI directives in ZTS enabled builds.

Please note the problem reported here only applies to ZTS 
enabled builds.

I have tried the supplied testcase on the latest snap-shot 
build for Windows (Nov 2, 2006 09:30 GMT)and the problem 
persists. phpinfo() shows "PHP Version => 5.2.1-dev".

Problem also persists in latest checked in version of file 
in CVS.

If I define a OnMOdify callback routine for an extension INI
directive the routine is called multiple times during
startup even though the directive is not being continually
modified. I expected one call as a result of modification to
the directive in php.ini but instead I got 3 calls.

I spotted this behaviour reviewing the engine code whilst 
reading Sara Golemon's book "Extending and Embedding PHP" 
and include a slightly modified version of sample code
from her book to illustrate the unnecessary calls.

The first problem is that in a ZTS enabled build 
zend_ini_refresh_caches() is called twice for each new 
thread. The method zend_new_thread_end_handler() calls it 
directly as follows: 

static void zend_new_thread_end_handler(THREAD_T thread_id TSRMLS_DC)
{
zend_copy_ini_directives(TSRMLS_C);
zend_ini_refresh_caches(ZEND_INI_STAGE_STARTUP TSRMLS_CC);
}

However, zend_copy_ini_directives() itself also calls
zend_ini_refresh_caches() so we end up calling any OnModifty callback
routines twice for each new thread.

I believe that: 
   (1) the call in zend_copy_ini_directives() can safely be
   removed, and 
   (2) the call in zend_new_thread_end_handler() should
   really be conditional on the success of the copy 
   operation, otherwise we could attempt to iterate
   over a non-existent hash and die. 

This will reduce the number of calls to 2 on ZTS emabled builds but any
OnModifycallback routine will still be called twice on the startup
thread in ZTS enabled builds; once by zend_register_ini_entries()
during MINIT processing when an extension registers its INI directives
and again on ZTS
builds during zend_post_startup() processing, i.e 

 zend_post_startup() -> zend_new_thread_end_handler()  -> 
 zend_ini_refresh_caches()

Whilst the call to the OnModify callback routine from
zend_register_ini_entries() is required for non-ZTS builds 
to work correctly I can see no need for a call from 
zend_ini_refresh_caches() during zend_post-startup 
processing. I believe this can easily be resolved by 
modifying zend_post_startup() to call 
  zend_copy_ini_directives() 
instead of 
  zend_new_thread_end_handler()

My patch for zend.c is here: http://pastebin.ca/234196
and for zend_ini.c here: http://pastebin.ca/234200 


Reproduce code:
---
Reproduce code is here: http://pastebin.ca/234201

I tested by adding the following to php.ini:

sample4.greeting="Hello Andy"

or via command line as:

-dsample4.greeting="Hello Andy"

Expected result:

When running using CLI on Windows, i.e a ZTS enabled build, I 
expected to see 1 call to my extensions "OnModify" callback 
routine for each thread attached; so in this simple case I expected to
see just the 1 call as follows:

>> sample 4: thread 0xfbc minit
sample 4: thread 0xfbc greeting modified..new value is Hello Andy
<< sample 4: thread 0xfbc minit
Hello Andy


Actual result:
--
The OnModify call back routine is in fact called 3 times; once
during MINIT processing and twice further. These last 2 are during the
call to zend_new_thread-end_handler().

>> sample 4: thread 0x16f8 minit
sample 4: thread 0x16f8 greeting modified..new value is Hello Andy
<< sample 4: thread 0x16f8 minit
sample 4: thread 0x16f8 greeting modified..new value is Hello Andy
sample 4: thread 0x16f8 greeting modified..new value is Hello Andy
Hello Andy








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

#39390 [Opn->Bgs]: I have the DLLS in the correct folder and all of them are there but it says its

[edink]

 ID:   39390
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ryanbestofthewest at hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Dynamic loading
 Operating System: Windows XP
 PHP Version:  5.2.0
 New Comment:

You have most likely mixed up two PHP installs. Try with a clean
install, PHP has no support in loading modules.


Previous Comments:


[2006-11-05 20:39:51] ryanbestofthewest at hotmail dot com

Description:

Hi, i have Apache/2.0.59 (Win32) & PHP/5.2.0. I keep getting dynamic
library errors i have the directory set right and i checked for the
dlls there all there. 




PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\
ext\php_exif.dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\
ext\php_ifx.dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\
ext\php_oci8.dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\
ext\php_exif.dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\
ext\php_ifx.dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  Module 'mysql' already loaded in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\
ext\php_oci8.dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\
ext\php_pdo_oci.dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\
ext\php_pdo_oci8.dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\
ext\php_pspell.dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\
ext\php_sybase_ct.dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\
ext\php_ibm_db2.dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\
ext\php_imagick.dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\
ext\php_ingres.dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\
ext\php_netools.dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\
ext\php_oracle.dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\
ext\php_svn.dll' - The specified module could not be found.
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 'C:\Program
Files\PHP\
ext\php_yaz.dll' - The specified procedure could not be found.
 in Unknown on line 0
Cannot find module (IP-MIB): At line 0 in (none)
Cannot find module (IF-MIB): At line 0 in (none)
Cannot find module (TCP-MIB): At line 0 in (none)
Cannot find module (UDP-MIB): At line 0 in (none)
Cannot find module (SNMPv2-MIB): At line 0 in (none)
Cannot find module (SNMPv2-SMI): At line 0 in (none)
Cannot find module (UCD-SNMP-MIB): At line 0 in (none)
Cannot find module (UCD-DEMO-MIB): At line 0 in (none)
Cannot find module (SNMP-TARGET-MIB): At line 0 in (none)
Cannot find module (SNMP-VIEW-BASED-ACM-MIB): At line 0 in (none)
Cannot find module (SNMP-COMMUNITY-MIB): At line 0 in (none)
Cannot find module (UCD-DLMOD-MIB): At line 0 in (none)
Cannot find module (SNMP-FRAMEWORK-MIB): At line 0 in (none)
Cannot find module (SNMP-MPD-MIB): At line 0 in (none)
Cannot find module (SNMP-USER-BASED-SM-MIB): At line 0 in (none)
Cannot find module (SNMP-NOTIFICATION-MIB): At line 0 in (none)
Cannot find module (SNMPv2-TM): At line 0 in (none)
PHP Notice:  Constant XML_ELEMENT_NODE already defined in Unknown on
line 0
PHP Notice:  Constant XML_ATTRIBUTE_NODE already defined in Unknown on
line 0
PHP Notice:  Constant XML_TEXT_NODE already defined in Unknown on line
0
PHP Notice:  Constant XML_CDATA_SECTION_NODE already defined in Unknown
on line
0
PHP Notice:  Constant XML_ENTITY_REF_NODE already defined in Unknown on
line 0
PHP Notice:  Constant XML_ENTITY_NODE already defi

#39413 [Opn->Asn]: "bugfix" in Zend/zend_execute.c breaks PEAR install

[bjori]

 ID:   39413
 Updated by:   [EMAIL PROTECTED]
 Reported By:  need dot coffee at gmail dot com
-Status:   Open
+Status:   Assigned
-Bug Type: Unknown/Other Function
+Bug Type: Class/Object related
-Operating System: Solaris 8/SPARC64
+Operating System: *
 PHP Version:  4CVS-2006-11-06 (snap)
-Assigned To:  
+Assigned To:  iliaa


Previous Comments:


[2006-11-07 11:26:34] need dot coffee at gmail dot com

Description:

First, I know this isn't the place for a PEAR bug; it 
doesn't
appear to be a PEAR bug...

Trying to install php4-STABLE-200611061330 fails at PEAR
installation time with "Fatal error: Call to a member 
function on a non-object in [,,,]/pear/PEAR/Installer/Role/
Common.php on line 90."

The pear code hasn't changed since I was able to last 
install; however PHP code has.  If I revert the change 
recently made in Zend/zend_compile.c, it installs fine:

--- Zend/zend_compile.c~Sun Oct 15 14:32:37 2006
+++ Zend/zend_compile.c Mon Nov  6 21:21:41 2006
@@ -1164,7 +1164,7 @@
 
if (zend_hash_find(&ce->parent->function_table, ce-
>parent->name, ce->parent->name_length+1, (void **) 
&function)==SUCCESS) {
/* inherit parent's constructor */
-   zend_hash_update(&ce->function_table, ce-
>parent->name, ce->parent->name_length+1, function, sizeof
(zend_function), NULL);
+   zend_hash_update(&ce->function_table, ce->name, 
ce->name_length+1, function, sizeof(zend_function), NULL);
function_add_ref(function);
}
}


Reproduce code:
---
Download a recent snap and try to run 'make install'.






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

#39407 [Opn->Asn]: Swapped Upload and Session Directory

[edink]

 ID:   39407
 Updated by:   [EMAIL PROTECTED]
 Reported By:  eoghan at loggedin dot com
-Status:   Open
+Status:   Assigned
 Bug Type: IIS related
 Operating System: XP SP2
 PHP Version:  5.2.0
-Assigned To:  
+Assigned To:  jmertic


Previous Comments:


[2006-11-06 21:40:45] eoghan at loggedin dot com

Description:

When you run the windows installer and choose IIS4+ CGI, it seems to
swap the values for the session directory and the uploads directory in
the php.ini file when it's created.

In php.ini it has

upload_tmp_dir="C:\DOCUME~1\Eoghan\LOCALS~1\Temp\php\session"
session.save_path="C:\DOCUME~1\Eoghan\LOCALS~1\Temp\php\upload"

and I think they're probably meant to be swapped i.e.

upload_tmp_dir="C:\DOCUME~1\Eoghan\LOCALS~1\Temp\php\upload"
session.save_path="C:\DOCUME~1\Eoghan\LOCALS~1\Temp\php\session"

Not a biggie, probably wouldn't really stop things functioning in most
cases, but just thought you might want to know.

Eoghan.






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

#39410 [Opn->Asn]: Installation on CGI mode fails

[edink]

 ID:   39410
 Updated by:   [EMAIL PROTECTED]
 Reported By:  gschizas at gmail dot com
-Status:   Open
+Status:   Assigned
 Bug Type: IIS related
 Operating System: Windows 2003
 PHP Version:  5.2.0
-Assigned To:  
+Assigned To:  jmertic


Previous Comments:


[2006-11-07 08:07:18] gschizas at gmail dot com

Description:

While installing (with the installer) in CGI Mode (Windows 2003 SP1,
IIS6), I get an error message at the end of the installation (There is
a problem with this Windows Installer Package)

Reproduce code:
---
Event Viewer shows this:

Product: PHP 5.2.0 -- Error 1721. There is a problem with this Windows
Installer package. A program required for this install to complete
could not be run. Contact your support personnel or package vendor.
Action: iisextVBS, location: C:\Program Files\PHP\, command:
"C:\WINDOWS\system32\iisext.vbs" /AddFile "C:\Program
Files\PHP\php-cgi.exe" 


I found this again as Bug #26185, for PHP 4.2.1, but obviously it
reared its ugly head again (#26185 is closed, but the behavior
persists).

Expected result:

Installation not producing any error messages, and registering PHP in
"Web Service Extensions"

Actually this is probably a problem with the fact iisext.vbs requires
more parameters in Windows 2003. So instead of
"C:\WINDOWS\system32\iisext.vbs" /AddFile "C:\Program
Files\PHP\php-cgi.exe",
you should type
"C:\WINDOWS\system32\iisext.vbs" /AddFile "C:\Program
Files\PHP\php-cgi.exe" 1 PHP 1 "PHP: Hypertext Processor"

Use iisext.vbs /? to see the meaning of the parameters.

The installer needs to be fixed.

Actual result:
--
Installation produced the error message, PHP was not registered, but
all other things seemed to go well.





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

#39411 [Opn->Bgs]: php (cgi) binary is not produced when compiling with apxs2 configured

[edink]

 ID:   39411
 Updated by:   [EMAIL PROTECTED]
 Reported By:  thp3 at sigproc dot de
-Status:   Open
+Status:   Bogus
 Bug Type: *Compile Issues
 Operating System: Linux 2.6.8
 PHP Version:  5.2.0
 New Comment:

Please don't submit the same bug twice. You can only compile CLI + any
other sapi.


Previous Comments:


[2006-11-07 09:08:57] thp3 at sigproc dot de

Description:

Re-issueing of Bug #30682 (php (cgi) binary does not compile with apxs2
configured).

When having the "--with-apxs" option enabled, the CGI executable is not
generated during compilation, though this is implied by the naming of
the configure options and the current documentation in file INSTALL.

Rationale: though it might be trivial for the php developers to know
that the CGI executable is only one of the SAPI modules and that only
one SAPI module (+ cli) can be compiled at a time, for the average user
it is just puzzling not to find the CGI executable after use of a rather
unsuspicious configure command.

Please either 
a) adjust the naming of configure options (e.g. have an explicit option
for the target, i.e. --build-sapi={cgi|apache|...}), or
b) leave a small note in the documentation about the issue, preferably
in INSTALL or at the top of the "configure --help" text. (Something
like: "Note that enabling --with-apxs and alike will cease the CGI
executable from being built.")







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

#38536 [NoF->Opn]: Returning an array of values instead of an object

[sabrina at corp dot grupos dot com dot br]

 ID:   38536
 User updated by:  sabrina at corp dot grupos dot com dot br
 Reported By:  sabrina at corp dot grupos dot com dot br
-Status:   No Feedback
+Status:   Open
 Bug Type: SOAP related
 Operating System: FreeBSD 6.1
-PHP Version:  5.1.5
+PHP Version:  PHP_5_2 cvs
 New Comment:

reopen


Previous Comments:


[2006-09-01 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2006-08-24 08:06:57] [EMAIL PROTECTED]

We still need a short reproduce script without private services and
fatal errors.



[2006-08-22 14:43:55] sabrina at corp dot grupos dot com dot br

unfortunately, you cannot execute this code as it is, because the
webservice in question is private and cannot be accessed externarly or
without authentication.

the line:
$return = $SOAPObject->__soapCall('getClientInfoFromDomain',
'sabrina.corp.grupos.com.br');
is incorrect, and should be:
$return = $SOAPObject->__soapCall('getClientInfoFromDomain',
array('sabrina.corp.grupos.com.br'));

but other than that, you could either try to access a webservice that
returns an array of objects or read the
the result dumps of this script for versions 5.1.4 and 5.1.5 
(you can check these files 
http://intranet.grupos.com.br/~sabrina/phpbug/phpreply515.html
http://intranet.grupos.com.br/~sabrina/phpbug/phpreply514.html
) and see that there is a big difference between both responses.

thank you for your replies.



[2006-08-22 13:51:31] [EMAIL PROTECTED]


Notice: Undefined variable: newIp in /tmp/1.php on line 4

Warning: SoapClient::__soapCall() expects parameter 2 to be array,
string given in /tmp/1.php on line 14

Fatal error: SoapClient::__soapCall(): Invalid parameters in /tmp/1.php
on line 14




[2006-08-22 13:11:53] sabrina at corp dot grupos dot com dot br

 SOAP_1_1, 'trace' => false,
'exceptions' => true, 'encoding' => 'ISO-8859-1', 'location' => $newIp
);
try {
$SOAPObject = new
SoapClient('http://enturma.com.br/wsdl/session.wsdl', $proxyParams);
} catch (SoapFault $e) {
throw new ESoapException($e->faultcode, $e->faultstring, 'initSOAP',
$this->componentName, false);
}

$return = $SOAPObject->__soapCall('getClientInfoFromDomain',
'sabrina.corp.grupos.com.br');

var_dump($return);

/** Var_dump for 5.1.5 can be seen here:
http://intranet.grupos.com.br/~sabrina/phpbug/phpreply515.html
Var_dump for 5.1.4 can be seen here:
http://intranet.grupos.com.br/~sabrina/phpbug/phpreply514.html

**/
?>



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

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

#39406 [Opn->Bgs]: Wrong namespaces in SOAP request

[mail at martin-probst dot com]

 ID:   39406
 User updated by:  mail at martin-probst dot com
 Reported By:  mail at martin-probst dot com
-Status:   Open
+Status:   Bogus
 Bug Type: SOAP related
 Operating System: MacOS
 PHP Version:  5.2.0
 New Comment:

Turns out this is (most likely) not a problem with the PHP 
SOAP implementation, sorry to bother you.


Previous Comments:


[2006-11-06 20:19:03] mail at martin-probst dot com

Btw.: Bug #36547 seems related
And: http://de3.php.net/manual/en/ref.soap.php#69173 seems to 
refer to the same bug, providing a really weird and dirty 
work-around.



[2006-11-06 20:03:36] mail at martin-probst dot com

Description:

I'm trying to access a web service using a .wsdl file, literal 
style. The wsdl defines two schemata with different namespaces 
where the first one refers to the latter. The message 
parameter in the SOAP envelope gets the wrong namespace.

Reproduce code:
---
The wsdl contains two schemata:

http://www.w3.org/2001/XMLSchema";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl";
xmlns:xi0="http://targetNS"; xmlns:xi1="http://otherNS";
targetNamespace="http://targetNS";>
  http://otherNS"/>
  
  ...

http://www.w3.org/2001/XMLSchema";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl";
xmlns:xi0="http://targetNS"; xmlns:xi1="http://otherNS";
xmlns="http://otherNS"; targetNamespace="http://otherNS";>
   

  
  ...


The calling PHP code:
$res = $soap->EmployeeBasicDataByEmployeeQueryResponse_In(
array("EmployeeBasicDataSelectionByEmployee" => array("EmployeeID"
=> 10;
echo $soap->__getLastRequest() . "\n";

I also tried classmaps and various array combinations. If you add
another array level (EmployeeBasicDataByEmployeeQuery) the above gives
an error (object hasn't 'EmployeeBasicDataSelectionByEmployee'
property).

Expected result:

http://schemas.xmlsoap.org/
soap/envelope/"
  xmlns:ns1="http://targetNS";
  xmlns:ns2="http://otherNS";>
  

  
10
  

  


Actual result:
--
http://schemas.xmlsoap.org/
soap/envelope/"
  xmlns:ns1="http://my/namespace/somewhere";>
  

  
10
  

  






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

#39376 [Csd]: Unable to load Chinese characters from oci8

[automap at gmail dot com]

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

for other users' convenient, there are some important thing should be
attention as below:
1.the oracle instant client environmental parameter('path' in windows)
should be set before other existed oracle path(if you want to use the
former oracle path later)
2.mabye you should download the msvcr71.dll and copy it to the
directory where oralce instant client files lie
3.you should restart your system after setting the path parameters


Previous Comments:


[2006-11-06 13:43:41] automap at gmail dot com

problem resolved!
oci_connect() function should take the fourth parameter, which
indicates the characterset, for example:
 oci_connect( $username, $password ,$db, 'ZHS16GBK');
Thanks to all



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

Thanks to [EMAIL PROTECTED] 
the problem "Unable to load dynamic library " was resolved.
but a new one occured:
when I fetch data from remote oracle db, I get the Chinese data in '?',
while the Eglish and numeric characterset is still ok.
I have thought that it's due to the parameter 'xLNS_LANG',but I have
changed many possible configure to the xLNS_LANG or NLS_LANG , NO
effect.
Why?



[2006-11-05 15:28:12] jhtpeter at gmail dot com

I get the same problem.
My environment is: Windows 2003, Oracle9i Server, PHP 5.2
I installed oracle instant client and set these env variables:
PATH=C:\instantclient;...
TNS_ADMIN=C:\instantclient
LD_LIBRARY_PATH=C:\instantclient

and also edit registry as BUG#39096 instructions:
rename NLS_LANG TO xLNS_LANG

At last, apache logs report:
unable to load php_oci8.dll

It seem to if Oracle Server installed, PHP cannot use instant client as
the same machine?



[2006-11-04 18:42:36] crescentfreshpot at yahoo dot com

You need oracle instant client installed. See bug #39360



[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

#39413 [NEW]: "bugfix" in Zend/zend_execute.c breaks PEAR install

[need dot coffee at gmail dot com]

From: need dot coffee at gmail dot com
Operating system: Solaris 8/SPARC64
PHP version:  4CVS-2006-11-06 (snap)
PHP Bug Type: Unknown/Other Function
Bug description:  "bugfix" in Zend/zend_execute.c breaks PEAR install

Description:

First, I know this isn't the place for a PEAR bug; it 
doesn't
appear to be a PEAR bug...

Trying to install php4-STABLE-200611061330 fails at PEAR
installation time with "Fatal error: Call to a member 
function on a non-object in [,,,]/pear/PEAR/Installer/Role/
Common.php on line 90."

The pear code hasn't changed since I was able to last 
install; however PHP code has.  If I revert the change 
recently made in Zend/zend_compile.c, it installs fine:

--- Zend/zend_compile.c~Sun Oct 15 14:32:37 2006
+++ Zend/zend_compile.c Mon Nov  6 21:21:41 2006
@@ -1164,7 +1164,7 @@
 
if (zend_hash_find(&ce->parent->function_table, ce-
>parent->name, ce->parent->name_length+1, (void **) 
&function)==SUCCESS) {
/* inherit parent's constructor */
-   zend_hash_update(&ce->function_table, ce-
>parent->name, ce->parent->name_length+1, function, sizeof
(zend_function), NULL);
+   zend_hash_update(&ce->function_table, ce->name, 
ce->name_length+1, function, sizeof(zend_function), NULL);
function_add_ref(function);
}
}


Reproduce code:
---
Download a recent snap and try to run 'make install'.


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

#39412 [NEW]: base64_decode does not return FALSE on failure

[phpbugs at staznosti dot sk]

From: phpbugs at staznosti dot sk
Operating system: Linux
PHP version:  4.4.4
PHP Bug Type: *URL Functions
Bug description:  base64_decode does not return FALSE on failure

Description:

base64_decode does not return FALSE on failure, return garbled (binary)
text instead

Reproduce code:
---
$string="This is short string!";

$test=base64_decode($string);

if ($test===FALSE) echo 'text is not base64 encoded';
else echo $test;

Expected result:

FALSE should be returned

Actual result:
--
garbled text / binary string

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

#39411 [NEW]: php (cgi) binary is not produced when compiling with apxs2 configured

[thp3 at sigproc dot de]

From: thp3 at sigproc dot de
Operating system: Linux 2.6.8
PHP version:  5.2.0
PHP Bug Type: *Compile Issues
Bug description:  php (cgi) binary is not produced when compiling with apxs2 
configured

Description:

Re-issueing of Bug #30682 (php (cgi) binary does not compile with apxs2
configured).

When having the "--with-apxs" option enabled, the CGI executable is not
generated during compilation, though this is implied by the naming of the
configure options and the current documentation in file INSTALL.

Rationale: though it might be trivial for the php developers to know that
the CGI executable is only one of the SAPI modules and that only one SAPI
module (+ cli) can be compiled at a time, for the average user it is just
puzzling not to find the CGI executable after use of a rather unsuspicious
configure command.

Please either 
a) adjust the naming of configure options (e.g. have an explicit option
for the target, i.e. --build-sapi={cgi|apache|...}), or
b) leave a small note in the documentation about the issue, preferably in
INSTALL or at the top of the "configure --help" text. (Something like:
"Note that enabling --with-apxs and alike will cease the CGI executable
from being built.")



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