#43813 [Opn]: Argentinian summer time off?

2008-01-10 Thread john at jcoppens dot com
 ID:   43813
 User updated by:  john at jcoppens dot com
 Reported By:  john at jcoppens dot com
 Status:   Open
 Bug Type: Date/time related
 Operating System: Linux
 PHP Version:  5.2.5
 New Comment:

Re-reading, this might cause confusion:

> The system time is set to GMT,

I meant the hardware time is set to GMT. The system time is set to
local, of course.

John


Previous Comments:


[2008-01-11 05:13:57] john at jcoppens dot com

Description:

When printing (using strftime) the local time, this is one hour off, as
if the new summer time is not taken into account:

It is now 03:02, and the time reported is 02:02.

This is happening only in PHP. The system time is set to GMT, and the
'date' command reports correctly. TCL is also reporting the date
correctly and an offset of -0200. PHP reports -0300.

I wonder if PHP is administering the timezones separately from the
operating system (I already updated the system locale to the new savings
time).
I tried setlocale("LC_TIME", "es_AR") and "ar_AR" (which is probably
incorrect)

What do I have to do to correct this?

Thanks
John


Reproduce code:
---
Just print the date, using strftime, in the argentinian time zone. 


Expected result:

Time should, at this moment, be GMT-2, not GMT-3 (which is normal in
winter)


Actual result:
--
GMT-3





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


#43813 [NEW]: Argentinian summer time off?

2008-01-10 Thread john at jcoppens dot com
From: john at jcoppens dot com
Operating system: Linux
PHP version:  5.2.5
PHP Bug Type: Date/time related
Bug description:  Argentinian summer time off?

Description:

When printing (using strftime) the local time, this is one hour off, as if
the new summer time is not taken into account:

It is now 03:02, and the time reported is 02:02.

This is happening only in PHP. The system time is set to GMT, and the
'date' command reports correctly. TCL is also reporting the date correctly
and an offset of -0200. PHP reports -0300.

I wonder if PHP is administering the timezones separately from the
operating system (I already updated the system locale to the new savings
time).
I tried setlocale("LC_TIME", "es_AR") and "ar_AR" (which is probably
incorrect)

What do I have to do to correct this?

Thanks
John


Reproduce code:
---
Just print the date, using strftime, in the argentinian time zone. 


Expected result:

Time should, at this moment, be GMT-2, not GMT-3 (which is normal in
winter)


Actual result:
--
GMT-3

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


#43812 [NEW]: 'password' parameter in my.cnf not honored even with mysqli_options()

2008-01-10 Thread graced at wingsnw dot com
From: graced at wingsnw dot com
Operating system: Debian lenny/sid
PHP version:  5.2.5
PHP Bug Type: MySQLi related
Bug description:  'password' parameter in my.cnf not honored even with 
mysqli_options()

Description:

my.cnf files allow the username/password/hostname and other connection
information to be stored for later use.

The Mysqli extension accepts a username from the file (overriding the
default of the current login username) but not a password, thus it attempts
to connect with no password even when a password is specified.  The mysql
command line client, when pointed at the file using
--defaults-extra-file=path/to/file.cnf, successfully connects.

Reproduce code:
---
my.cnf contents:
[client]
host = localhost
user = "username"
password = "topsecret"

PHP script:
options(MYSQLI_READ_DEFAULT_FILE, "my.cnf");
$DB->options(MYSQLI_READ_DEFAULT_GROUP, "client");
$DB->real_connect();



Expected result:

A successful database connection.

Actual result:
--
Warning: mysqli::real_connect(): (28000/1045): Access denied for user
'wadmin'@'localhost' (using password: NO) in /home/.../- on line 6


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


#43811 [NEW]: Line Continuation Characters inside string are being removed

2008-01-10 Thread steve1011 at att dot net
From: steve1011 at att dot net
Operating system: Windows 2003 server
PHP version:  5.2.5
PHP Bug Type: Scripting Engine problem
Bug description:  Line Continuation Characters inside string are being removed

Description:

If a string contains backslash newline, in any form of input or string
building, those characters are removed as if the parser is processing a
script line. All other languages that I know of only remove the line
continuation if it occurs outside of a string definition and leaves the
inside of strings alone (other than normal escape sequences of double
quoted strings). php even strips the backslash newline from text submitted
through a web form and referenced as $_REQUEST['varname'].

Line continuation characters effected are:

backslash newline
backslash carriage return
backslash equal sign
backslash 0x10

There may be more. I haven't completed testing yet, but will update this
bug report if I find more.

Reproduce code:
---
I've tried test strings (letter e, backslash, newline, letter e) like:

"e\\\ne" becomes "ee"
'e\'."\n".'e' becomes 'ee'
'e\'.0x0a.'e' becomes 'ee'
"e\\\x0ae" becomes "ee"

you get the idea.

If I [sic] escape the string like this:

"e\x0a\x0ae" I get the expected [e, backslash, newline, e] string.



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


#43809 [Opn]: strtok() should return FALSE if needle wasnt found

2008-01-10 Thread felipe
 ID:   43809
 Updated by:   [EMAIL PROTECTED]
 Reported By:  admin at ifyouwantblood dot de
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Any
 PHP Version:  5.2.5
 New Comment:

Looks fine to me. My try:

Index: string.c
===
RCS file: /repository/php-src/ext/standard/string.c,v
retrieving revision 1.445.2.14.2.69.2.8
diff -u -r1.445.2.14.2.69.2.8 string.c
--- string.c31 Dec 2007 07:17:15 -  1.445.2.14.2.69.2.8
+++ string.c11 Jan 2008 00:00:34 -
@@ -1264,7 +1264,7 @@
}
}
 
-   if (p - BG(strtok_last)) {
+   if ((skipped || BG(strtok_len) != strlen(BG(strtok_last))) && p
- BG(strtok_last)) {
 return_token:
RETVAL_STRINGL(BG(strtok_last) + skipped, (p -
BG(strtok_last)) - skipped, 1);
BG(strtok_last) = p + 1;



Previous Comments:


[2008-01-10 19:06:45] admin at ifyouwantblood dot de

Description:

In PHP 4.1 strtok() has been changed to return FALSE if a repeated
token wasnt found in the haystack string. It should also return FALSE if
needle wasnt found at first place.

Reproduce code:
---


Expected result:

bool(false)

Actual result:
--
string(9) "something"





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


#43810 [NEW]: PDO ODBC windows-1250 data transfer

2008-01-10 Thread aszmyd at gmail dot com
From: aszmyd at gmail dot com
Operating system: MS Win XP 32
PHP version:  5.2.5
PHP Bug Type: PDO related
Bug description:  PDO ODBC windows-1250 data transfer

Description:

Problem with long text transfer in code page windows-1250 (polish
characters). 
When text is longer then 256 characters some unexpected characters appear
at the end of it. 
Text without polish characters is OK.
Text with polish characters after 256 character is also OK.
Data are retrieved from Progress 10.1A data base through ODBC driver.
Transfering data to MS Excel gives perfect results.

Reproduce code:
---
$dsn = "odbc:DSN=soja;PWD=xyz";
$dbh = new PDO($dsn);
$sql = 'SELECT
certyfikaty.nr_certyfikatu,
certyfikaty.zakres,
firmy.nazwa_firmy
FROM PUB.certyfikaty, PUB.firmy
WHERE  certyfikaty.id_firmy = firmy.id_firmy;

$stmt = $dbh->prepare($sql);
$stmt->execute();
$stmt->bindColumn(1, $nr_certyfikatu, PDO::PARAM_STR, 16);
$stmt->bindColumn(2, $zakres, PDO::PARAM_STR, 512);
$stmt->bindColumn(3, $nazwa_firmy, PDO::PARAM_STR, 64);

while ($row = $stmt->fetch(PDO::FETCH_BOUND)){
   echo "".$nr_certyfikatu."";
   echo "".$nazwa_firmy."";
   echo "".$zakres."";
   echo "";}
$dbh = null;

Expected result:

echo "".$zakres.""
Handel zagraniczny i krajowy surowcami, energią, towarami
przemysłowymi. Świadczenie usług w zakresie projektowania
oraz realizacji inwestycji przemysłowych i publicznych. Obrót z
zagranicą towarami, technologiami i usługami o znaczeniu
strategicznym dla bezpieczeństwa Państwa.

Actual result:
--
echo "".$zakres.""
Handel zagraniczny i krajowy surowcami, energią, towarami
przemysłowymi. Świadczenie usług w zakresie projektowania
oraz realizacji inwestycji przemysłowych i publicznych. Obrót z
zagranicą towarami, technologiami i usługami o znaczeniu
strategicznym dla nym dla bezpieczeństwa ŹĆŃ[27
Państwa.

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


#43809 [NEW]: strtok() should return FALSE if needle wasnt found

2008-01-10 Thread admin at ifyouwantblood dot de
From: admin at ifyouwantblood dot de
Operating system: Any
PHP version:  5.2.5
PHP Bug Type: Feature/Change Request
Bug description:  strtok() should return FALSE if needle wasnt found

Description:

In PHP 4.1 strtok() has been changed to return FALSE if a repeated token
wasnt found in the haystack string. It should also return FALSE if needle
wasnt found at first place.

Reproduce code:
---


Expected result:

bool(false)

Actual result:
--
string(9) "something"

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


#43808 [NEW]: date_create never fails (even when it should)

2008-01-10 Thread martin dot contento at gmail dot com
From: martin dot contento at gmail dot com
Operating system: linux
PHP version:  5.2.5
PHP Bug Type: Date/time related
Bug description:  date_create never fails (even when it should)

Description:

As "karsten" already mentioned
(http://de.php.net/manual/en/function.date-create.php#77871) date_create()
never returns FALSE like it is supposed to, even when it is handed complete
garbage. It seems to be something like "if the string starts with a letter,
treat it as a timezone -> this is not a timezone *dies*)

edit:
also, this bug might be related: http://bugs.php.net/bug.php?id=40340

Reproduce code:
---


Expected result:

nothing (i would expect date_create() to handle the error in the timezone
function and return FALSE)

Actual result:
--
Warning: date_create(): Failed to parse time string (asdfasdf) at position
0 (a): The timezone could not be found in the database in
/home/mcontento/datetimebug.php on line 3

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


#43807 [NEW]: array_rand doesn't return keys in random order

2008-01-10 Thread martin dot kober at wu-wien dot ac dot at
From: martin dot kober at wu-wien dot ac dot at
Operating system: Linux 2.6
PHP version:  5.2.5
PHP Bug Type: Arrays related
Bug description:  array_rand doesn't return keys in random order

Description:

The keys that array_rand returns are uniformly distributed, but their
order is not:

Counting the 0, 1 and 2 of the sample code output, I consistently get some
distribution like this:

Overall count (this is fine):
  0   1   2 
649 694 657 

Count per position (this is wrong):
  0   1   2 
[0] 500 181 319 
[1] 149 513 338 
0 is way too often in [0] (same for 1 in [1]), there must be some problem
with the algorithm. 

Adding a shuffle() is a workaround, but this is a potential trap for users
depending on an even distribution.

There are some similar bugs in the DB, but they are all very old and seem
to be Windows-related.

Reproduce code:
---
for ($i = 1; $i <= 1000; $i++) {
echo implode(" ", array_rand(array(1,2,3), 2)), "\n";
}



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


#41350 [Com]: Error in my_thread_global_end()

2008-01-10 Thread amoo_miki at yahoo dot com
 ID:   41350
 Comment by:   amoo_miki at yahoo dot com
 Reported By:  graham at directhostinguk dot com
 Status:   No Feedback
 Bug Type: MySQL related
 Operating System: Windows 2003
 PHP Version:  5.2.3
 New Comment:

This is caused by windows security:

to be sure:
1) Check if the drive where PHP is installed is an NTFS partition.
2) If yes, "Read & Execute" for "Everyone" for the "ext" folder.

php -v at the command-line should not show you the error anymore.


Previous Comments:


[2008-01-07 12:14:01] jaco at jump dot co dot za

I was able to reproduce this on a very basic instalation:

Apache 2.2.4
PHP 5.2.5
Windows 2003 Server
NO Database installed



This executes 100%, and gives no errors, but as soon as I stop apache,
it gives me the message in the apache error log

Error in my_thread_global_end(): 1 threads didn't exit

So it seems to me more of a sockets problem than a mysql problem.

When I run the same script in CLI, I get no error.



[2008-01-04 21:44:17] jaco at jump dot co dot za

I am having the same and more problems. 

I am running:

Apache 2.2.6
MySQL 5.0.45
PHP 5.2.5
Windows Server 2003 R2 Standard SP2

2 x Quad Core Xeon
4Gb RAM

IIS Installed for SMTP, FTP and WWW on port 443 for a single .NET
Webservice access (NO PHP connectors installed for IIS). But I am sure
this is not IIS related, becuase it still happens even with IIS stopped



Whenever apache tries to recycle threads I get:

** Apache Error Log **

[Fri Jan 04 22:37:38 2008] [notice] Child 324: All worker threads have
exited.
Error in my_thread_global_end(): 1 threads didn't exit
exiting because it reached MaxRequestsPerChild. Signaling the parent to
restart a new child process.
[Fri Jan 04 22:37:42 2008] [notice] Parent: Received restart signal --
Restarting the server.



Note the time difference between the first log and the last log

This then causes my Apache to crash and restart.

Then I tried to download the latest snapshot of PHP, installed it, but
then Apache woould not start at all, just gives me a starting status,
but does not het out of it.

My problem is also that there is hundreds of php files running and our
site is very active, and I have NO idea what is causing this problem.
The PHP error log is clean, but the following also shows up AFTER apache
crashes.

080104 11:24:26 [Warning] Aborted connection 16865 to db: ''
user: '*' host: 'localhost' (Got an error reading communication
packets)

But I am sure that this is just caused by apache that have crashed and
the already open calls to the database that was not terminated by the
php script.


These messages apears in the event log after the crash:

Faulting application httpd.exe, version 2.2.6.0, faulting module
libapr-1.dll, version 1.2.11.0, fault address 0x79a0.

Faulting application httpd.exe, version 2.2.6.0, faulting module
php5ts.dll, version 5.2.5.5, fault address 0xacb9.

We are using both mysql and mysqli connectors and I have tried to
download the ones from the mysql site and again apache refused to start.


This is quite serious for us at the moment, becuase its in a live
enviroment and the dev servers never had this problem. 

Hope we can find a solution soon.



[2008-01-04 18:28:12] jcmelcher at gmail dot com

This worked for me... IIS 6.0 with PHP 5.2.5 on Win2K3 SP2

If you download the latest PHP - MySQL connector files direct from
MySQL
this problem goes away:-

http://dev.mysql.com/downloads/connector/php/



[2008-01-04 14:30:55] benjamin dot azan at gmail dot com

I could not find the new version of mysql connector but I changed the
PHP mode from CGI/fastCGI to  Apache 2.0 Handler and it fixed the
problem.



[2008-01-04 11:54:05] benjamin dot azan at gmail dot com

The mySQL bug http://bugs.mysql.com/bug.php?id=25621 says :

" MySQL 5.0.54BK on WinXP localhost does not exhibit the error. "

and the PHP 5.2.5 show Client API version   5.0.45

So I think the next version of PHP should contain this new version of
the MySQL connector.

I'm gonna try to upgrade the mySQL connector on a 5.2.5 PHP version to
see if it fixs the bug



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

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


#38111 [Com]: PHP crashes IIS worker process and application pool

2008-01-10 Thread chrisr at rho-technology dot com
 ID:   38111
 Comment by:   chrisr at rho-technology dot com
 Reported By:  svendavidh at hotmail dot com
 Status:   No Feedback
 Bug Type: IIS related
 Operating System: Windows Server 2003 Std. Ed. R2
 PHP Version:  5.1.4
 New Comment:

Same issues:
OS: Windows Server 2003 Web Edition sp1
PHP: 5.1.4

All apps are in the default pool


Previous Comments:


[2007-11-13 10:35:33] ready725 at gmail dot com

This bug occurred for me as well.
PHP 5.2.5, Installed as ISAPI, IIS 7.0, Windows Vista Ultimate.

It happens about 10 minutes after loading a PHP script, then crash
every half to 1 hour after that.

Can be reproduced by restarting the server, or running a PHP script and
waiting for a few minutes.

*There might be side-effects to this as well (possibly a memory leak,
because after receiving that error, I cannot run other applications
without closing some; not comfirmed).



[2007-10-30 16:03:26] huet_bartels at hotmail dot com

I have the same issue.  
I am using PHP/5.2.3 on IIS6 with plesk installed.

The application pool just crashes every 1/2 to 1 hour.



[2007-07-15 13:35:15] zeon77 at gmail dot com

The moodle_cron service causes the problem to me...



[2007-07-11 18:11:59] zeon77 at gmail dot com

Same with PHP 5.2.3, w2k3 r2 x86, iis6.
PHP installed as ISAPI extension.
Applications using PHP are running in a separate App pool.
Error occurs in every half an hour



[2007-07-07 11:06:35] mitch at mitchellgeere dot com

I am running Windows Vista Ultimate with PHP 5.2, MySql, IIS 7.0. I am
evaluating php, so far asp.net is holding my favour.



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

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


#43568 [Opn->Csd]: mysqli statement stmt->bind_param doesn't work when called by call_user_func

2008-01-10 Thread johannes
 ID:   43568
 Updated by:   [EMAIL PROTECTED]
 Reported By:  gabriel at oxeva dot fr
-Status:   Open
+Status:   Closed
 Bug Type: MySQLi related
 Operating System: Linux 2.6
 PHP Version:  5.3CVS-2007-12-11 (snap)
 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.

As Ulf (uw) said above: mysqli_stmt_bind_param() expects the parameters
to be references.It worked (more or less) by accident in previous
versions. But Dmitry now added a Warning so it won't fail silently; with
a current snapshot you'll get a error like "Warning: Parameter 1 to
mysqli_stmt::bind_param() expected to be a reference, value give in
...". see eyitsjunk at gmail dot com's comment to see how you can set
the references right.


Previous Comments:


[2008-01-05 15:54:31] gabriel at oxeva dot fr

It's been a long time I haven't seen dynamic variables ($$var) in PHP
code. I consider that such language constructs are what make PHP code
sometime very unreadable, and creates very hard-to-find bugs. Nice
workaround though :-)

And you're right, the binding scenario is totally illogical and
inflexible. I think the normal scenario is creating the variables (or an
array of constant variables such as "array('abc', '3, 'test')", and then
binding these with the prepared statement, but not like in the
bind_param doc example which does a binding with auto-created variables,
then assigns them some data. Besides, using undefined variables in a
function call causes PHP  to throw a Notice in E_ALL error mode, doesn't
it? (Maybe it's different with references, but undocumented)

Note this is not the first time I see some very strange PHP behavior
when using references (PHP-like pointers), not to mention how hard it is
to do debugging with them.

Or maybe I'm completely wrong in the way I write my own PHP code
logic?

Anyway, I'm a bit out of this bug report's context. We still have a bug
in the way call_user_func_array returns functions passing variables by
reference.



[2008-01-05 07:47:28] heyitsjunk at gmail dot com

Gabriel you don't need to use eval() to solve this issue.. I'll try to
explain by making your first example work the way you're thinking.  I
changed some variable names for convenience but it's the same example.

$my = new mysqli('localhost', 'test', 'test', 'testdb');

$stmt = $my->prepare('INSERT INTO `car` (`brand`, `brand_id`,
`car_type`) VALUES (?, ?, ?)');

$params = array('sss', 'GMC', 1, 'SUV');

//Okay I'll assume that the above is what I have to work with.
$types = $params[0];
unset($param[0]);
$i = 0;
foreach ($params as $param) {
   $bind_name = 'bind' . $i;
   $$bind_name = $param;
   $bind_names[] = &$$bind_name;
}
$bind_params[] = $types;
$bind_params[] = array_merge($bind_params, $bind_names)
//Added code ends here.

$return = call_user_func_array(array($stmt, 'bind_param'),
$bind_params);

var_dump($return);

$stmt->execute();

echo $stmt->errno, ':', $stmt->error;

So now you got yourself a working code.  With the same method of
binding, you can make yourself the ultimate lazy query function that
handles this situation:
$params = array('sss', 'GMC', 1, 'SUV');

query('INSERT INTO `car` (`brand`, `brand_id`,
`car_type`) VALUES (?, ?, ?)', $params);

or this is my preference but it doesn't handle BLOB types:

query('INSERT INTO `car` (`brand`, `brand_id`,
`car_type`) VALUES (?, ?, ?)', $brand, $brand_id, $car_type);

Anyways my point is I do agree with this logic though the doc
explanation "call_user_func_array" is MISLEADING.  I couldn't figure it
out until I saw uw.php.net's examples.  The whole binding scenario is
pretty tough and inflexible.  Still needs to be looked over by an expert
=)



[2008-01-04 18:00:37] [EMAIL PROTECTED]

I suggest that we leave the bug status as is for the moment. From what
I know some PHP hackers are already discussing the case and Johannes
(Schlüter) will take care that it does not get forgotten.

Your comment on the example in the documentation is welcome. I agree
with you that, for example, a code comment might be help beginners
understand the example better.

The manual example works because PHP implicitly creates a variable for
you whenever you start to use one. There's no need in PHP to sort of
declare a variable before you use it. So, on the one hand it might make
sense to change the example like this:

$bind_param = null;
mysqli_stmt_bind_param(..., &$bind_param)

... on the other hand, there's no need for the assignment operation.
Its a PHP feature that you can start using variables ad-hoc and PHP does
all the magic 

#43750 [Opn->Csd]: stristr modifies strings

2008-01-10 Thread tony2001
 ID:   43750
 Updated by:   [EMAIL PROTECTED]
 Reported By:  samuel at slbdata dot se
-Status:   Open
+Status:   Closed
-Bug Type: Scripting Engine problem
+Bug Type: Strings related
 Operating System: Ubuntu 7.10
 PHP Version:  6CVS-2008-01-04 (snap)
 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:


[2008-01-08 14:25:43] samuel at slbdata dot se

It works correctly with your patch.

Thank you!



[2008-01-08 11:37:54] [EMAIL PROTECTED]

Index: string.c
===
RCS file: /repository/php-src/ext/standard/string.c,v
retrieving revision 1.659
diff -u -u -r1.659 string.c
--- string.c31 Dec 2007 07:12:16 -  1.659
+++ string.c8 Jan 2008 11:33:56 -
@@ -2526,6 +2526,9 @@
return;
}
 
+   SEPARATE_ZVAL(haystack);
+   SEPARATE_ZVAL(needle);
+
if (Z_TYPE_PP(haystack) != IS_UNICODE && Z_TYPE_PP(haystack) !=
IS_STRING) {
convert_to_text_ex(haystack);
}




[2008-01-04 16:12:35] samuel at slbdata dot se

Description:

stristr converts it's parameters to lower case (non-ASCII characters
are not changed though). This happens with php6.0-200801022130 and
php6.0-200801041530 and the locale set to sv_SE.UTF-8

This might be a regression of bug #3890


Reproduce code:
---
http://bugs.php.net/?id=43750&edit=1


#42401 [Com]: php5ts crash on double free

2008-01-10 Thread ambition at ambitiondesign dot com dot au
 ID:   42401
 Comment by:   ambition at ambitiondesign dot com dot au
 Reported By:  reprovol at microsoft dot com
 Status:   No Feedback
 Bug Type: Reproducible crash
 Operating System: Windows Vista/LH Server
 PHP Version:  5.2.3
 New Comment:

To reproduce, run any PHP code using the IIS ISAPI extension, then stop
and start the IIS app pool. An error message dialog will appear, and
information will be added to the Microsoft Windows Application Event
Log.


Previous Comments:


[2007-08-31 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".



[2007-08-23 19:29:12] [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.



[2007-08-23 19:23:22] reprovol at microsoft dot com

Description:

Crash Bucket: 421917130  
  
szAppName w3wp.exe 
szAppVer 7.0.6001.16510 
szModName StackHash_80ba 
szModVer 6.0.6001.16510 
Offset 000a773f 
Exception Code c374 
Application Stamp 462598ef 
Module Stamp 4625a0ae 
0:014> !heap
**
**
*  HEAP ERROR DETECTED   *
**
**

Details:

Error address: 02ebc1d8
Heap handle: 0085
Error type heap_failure_block_not_busy (8)
Stack trace:
77ad01f8: ntdll!RtlFreeHeap+0x0060
75f22a89: kernel32!HeapFree+0x0014
76659fbb: msvcrt!free+0x00cd
025a9cfe: php5ts+0x00099cfe
77ac631c: ntdll!zzz_AsmCodeRange_End
77ab42bd: ntdll!LdrpUnloadDll+0x03d4
77aafeff: ntdll!LdrUnloadDll+0x0046
75eb2563: kernel32!FreeLibrary+0x0076
748ecaa0: isapi!ISAPI_DLL::Unload+0x0038


0:014> lmvmphp5ts 
startendmodule name
0251 029e7000   php5ts   T (no symbols)   
Loaded symbol image file: php5ts.dll
Image path: php5ts.dll
Image name: php5ts.dll
Timestamp:Thu May 31 06:37:03 2007 (465ECF7F)
CheckSum: 
ImageSize:004D7000
File version: 5.2.3.3
Product version:  5.2.3.0
File flags:   0 (Mask 3F)
File OS:  4 Unknown Win32
File type:2.0 Dll
File date:.
Translations: .04b0 .04e0 0409.04b0 0409.04e0

Sorry 
0:014> u 025a9cfe 
php5ts+0x99cfe:
025a9cfe ??  ???

Actual result:
--
77ad01f8: ntdll!RtlFreeHeap+0x0060
75f22a89: kernel32!HeapFree+0x0014
76659fbb: msvcrt!free+0x00cd
025a9cfe: php5ts+0x00099cfe
77ac631c: ntdll!zzz_AsmCodeRange_End
77ab42bd: ntdll!LdrpUnloadDll+0x03d4
77aafeff: ntdll!LdrUnloadDll+0x0046
75eb2563: kernel32!FreeLibrary+0x0076
748ecaa0: isapi!ISAPI_DLL::Unload+0x0038





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


#43806 [Opn->Bgs]: Unexpected result using 'foreach'

2008-01-10 Thread derick
 ID:   43806
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pepalegre at terra dot es
-Status:   Open
+Status:   Bogus
 Bug Type: Arrays related
 Operating System: openSUSE 10.3
 PHP Version:  5.2.5
 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 has also been submitted a few times too)


Previous Comments:


[2008-01-10 11:25:25] pepalegre at terra dot es

Description:

If I declare a reference variable (&$value) and use it in a 'foreach'
and then I reuse it in the same loop like a normal variable ($value), I
have an unexpected result, array is modified!
Note that using another variable in the second 'foreach' the result is
Ok.


Reproduce code:
---



Expected result:

Array
(
[0] => 1
[1] => 2
[2] => 3
)
Array
(
[0] => 1
[1] => 2
[2] => 3
)


Actual result:
--
Array
(
[0] => 1
[1] => 2
[2] => 3
)
Array
(
[0] => 1
[1] => 2
[2] => 2
)






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


#43806 [NEW]: Unexpected result using 'foreach'

2008-01-10 Thread pepalegre at terra dot es
From: pepalegre at terra dot es
Operating system: openSUSE 10.3 
PHP version:  5.2.5
PHP Bug Type: Arrays related
Bug description:  Unexpected result using 'foreach'

Description:

If I declare a reference variable (&$value) and use it in a 'foreach' and
then I reuse it in the same loop like a normal variable ($value), I have an
unexpected result, array is modified!
Note that using another variable in the second 'foreach' the result is
Ok.


Reproduce code:
---



Expected result:

Array
(
[0] => 1
[1] => 2
[2] => 3
)
Array
(
[0] => 1
[1] => 2
[2] => 3
)


Actual result:
--
Array
(
[0] => 1
[1] => 2
[2] => 3
)
Array
(
[0] => 1
[1] => 2
[2] => 2
)


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


#43804 [NEW]: XSLTProcessor fails to recognise dynamically created tags

2008-01-10 Thread [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  5.2.5
PHP Bug Type: DOM XML related
Bug description:  XSLTProcessor fails to recognise dynamically created  
tags

Description:

I've got a piece of code where I needed to dynamically create some xsl
commands in my xsl stylesheet using the DOM api, but when I pass the
DOMDocument to XSLTProcessor, it fails to recognise these commands.

However, if the DOMDocument is exported to a string and then
www.dictioloaded into a different DOMDocument, the result is correct.  The
function normalizeDocument() does not seem to have any effect.

The test files may be located at:
http://www.assessments.com.au/xsl_bug/

Reproduce code:
---
http://www.assessments.com.au/xsl_bug/test.phps

Expected result:

http://schemas.microsoft.com/office/infopath/2003/myXSD/2007-11-27T05:06:00";>This
text should appear!


Actual result:
--
http://schemas.microsoft.com/office/infopath/2003/myXSD/2007-11-27T05:06:00";>http://www.w3.org/1999/XSL/Transform";
select="my:test">

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


#43804 [Opn->Bgs]: XSLTProcessor fails to recognise dynamically created tags

2008-01-10 Thread chregu
 ID:   43804
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: DOM XML related
 Operating System: Linux
 PHP Version:  5.2.5
 New Comment:

You have to use createElementNS instead of createElement for adding 
namespaced Elements via DOM 


Previous Comments:


[2008-01-10 08:52:10] [EMAIL PROTECTED]

Description:

I've got a piece of code where I needed to dynamically create some xsl
commands in my xsl stylesheet using the DOM api, but when I pass the
DOMDocument to XSLTProcessor, it fails to recognise these commands.

However, if the DOMDocument is exported to a string and then
www.dictioloaded into a different DOMDocument, the result is correct. 
The function normalizeDocument() does not seem to have any effect.

The test files may be located at:
http://www.assessments.com.au/xsl_bug/

Reproduce code:
---
http://www.assessments.com.au/xsl_bug/test.phps

Expected result:

http://schemas.microsoft.com/office/infopath/2003/myXSD/2007-11-27T05:06:00";>This
text should appear!


Actual result:
--
http://schemas.microsoft.com/office/infopath/2003/myXSD/2007-11-27T05:06:00";>http://www.w3.org/1999/XSL/Transform";
select="my:test">





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