#32425 [Bgs->Csd]: mktime() - Out of range problem

2005-03-28 Thread dsacchet at kikamedical dot com
 ID:   32425
 User updated by:  dsacchet at kikamedical dot com
 Reported By:  dsacchet at kikamedical dot com
-Status:   Bogus
+Status:   Closed
 Bug Type: Date/time related
 Operating System: Linux 2.4.27
 PHP Version:  4.3.10
 New Comment:

As a conclusion, the problem come either from the version
of glibc or version of gcc ... Upgrade of those software
solved the problems.

Thanks for your help


Previous Comments:


[2005-03-25 12:58:31] dsacchet at kikamedical dot com

Hello,

I just upgraded GLIBC/GCC (both comes together) so to
glibc 2.3.4 and gcc 3.4.3 and everything is ok now.

Thanks for your diagnosis and help.

Best regards

Denis Sacchet



[2005-03-24 18:53:17] [EMAIL PROTECTED]

.



[2005-03-24 18:53:08] [EMAIL PROTECTED]

This is anyhow just problem with your system -> bogus.




[2005-03-24 18:14:10] dsacchet at kikamedical dot com

It will be difficult to upgrade the gcc version because this
version is not stable onto gentoo. Do you want me to make
some test with C program. I have good notion of C programming
so if you tell me make a program like that, compile and
execute, I can do that (do you use the C mktime into the
php source ?)



[2005-03-24 18:04:53] [EMAIL PROTECTED]

Can you try upgrading your GCC to 3.4.3 ?




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

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


#30934 [Com]: Special keyword 'self' inherited in child classes

2005-03-28 Thread aknaub at 3st dot de
 ID:   30934
 Comment by:   aknaub at 3st dot de
 Reported By:  jbs at fromru dot com
 Status:   Feedback
 Bug Type: Class/Object related
 Operating System: Windows XP Pro SP1
 PHP Version:  5.0.2
 Assigned To:  andi
 New Comment:

I reproduced the bug with snapshot php5-200503282030, 
compiled as cli on Mac OS X 10.3.8.


Previous Comments:


[2005-03-27 01:18:39] mongole at tuivelsminne dot at

I reproduced the bug with snapshot php5-200503262330, compiled as
mod_php in apache-1.3.33 on FC 3.



[2005-03-25 01:21:31] [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





[2005-02-28 21:21:44] [EMAIL PROTECTED]

What's the verdict?




[2005-01-17 13:47:32] Jason at amp-design dot net

What is also most annoying is this doesn't just affect constants, it
affects anything that can be static, that is constants, class members,
and methods. This looks like a rather design descision that PHP people
did (I guess initially it seemed good from a speed POV).



[2005-01-17 13:33:40] Jason at amp-design dot net

I agree, this is damn annoying. 

However, I'm sure the PHP team will come back saying "Sorry this is not
a bug, it's an undocumented feature". I think this because I remember
reading somewhere the ZE2 deals with constants on compile time, and
therefore any references to self inside a class will point to the the
class name that the reference to self points to. Ideally, if a class is
extended, methods should be checked to see if the parent references
self, and this should then check if the item inside self is referenced
in the current class, or the parent class and adapt accordingly.

It would be so nice if this can be fixed, but I have a nasty felling
people have to live with this :(



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/30934

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


#32469 [Fbk->Opn]: With serial ports, fread is using the fwrite buffer

2005-03-28 Thread mccaskey at stanford dot edu
 ID:   32469
 User updated by:  mccaskey at stanford dot edu
 Reported By:  mccaskey at stanford dot edu
-Status:   Feedback
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: Windows XP
 PHP Version:  5.0.3
 New Comment:

Tried it. No difference.


Previous Comments:


[2005-03-29 00:40:59] [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





[2005-03-28 03:56:10] mccaskey at stanford dot edu

Description:

(1) Open a COM port as a serial input using fopen. Read using fread or
fgets. No data appears until 8K bytes have been read. There is an 8K
buffer on writes, but there shouldn't be one on reads. (Should there?)
Are reads somehow using the write buffer? Sure enough:

(2) Again, open a COM port as a serial input using fopen. This time,
write some characters using fwrite. Now fread 8K of serial data. At the
head of that stream appears the data you had written with fwrite. Oops.

[Several people have reported an inability to get fgets to read COM
data, saying they tried and fgets just never sees any input. I assume
this was their problem. But others have reported using fgets on COM
successfully. Something specific to OS/PHP versions?] 

Reproduce code:
---
(1) 
$serial_port = fopen("COM4", "r+");
echo(fread($serial_port, 8192));

(2)
$serial_port = fopen("COM4", "r+");
fwrite($serial_port, "MP");
echo(fread($serial_port, 8192));

Expected result:

(1) & (2)
serial data starting with the first byte that came in on the serial
line


Actual result:
--
(1) Nothing until 8K of data has been read in.

(2) After enough serial data to fill the buffer, first the data written
("MP" in this example), then the data that came in on the serial line.





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


#32422 [Opn]: Access Violation on calling PEAR Date::before

2005-03-28 Thread rob at wildlime dot com
 ID:   32422
 User updated by:  rob at wildlime dot com
 Reported By:  rob at wildlime dot com
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows XP SP2
 PHP Version:  4.3.10
 New Comment:

Here's another stack trace, using the MS debugger to get access to the
symbol names

ntdll!RtlpCoalesceFreeBlocks+0x21
ntdll!RtlFreeHeap+0x2e9
msvcrt!free+0xc3
msvcrt!__crtsetenv+0x193
msvcrt!_putenv_lk+0x42
msvcrt!_putenv+0x20
WARNING: Stack unwind information not available. Following frames may
be wrong.
php4ts!php_get_inf+0xf6e

Error details from the debugger:
(268.ddc): Access violation - code c005 (!!! second chance !!!)
eax=0418 ebx=0083 ecx=7ffda000 edx=00830608 esi=0082fd68
edi=00830180
eip=7c910c27 esp=0108d978 ebp=0108d984 iopl=0 nv up ei ng nz na
po cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=
efl=0287
ntdll!RtlpCoalesceFreeBlocks+0x21:
7c910c27 f6460501 testbyte ptr [esi+0x5],0x1 
ds:0023:0082fd6d=??

(NB still using php 4.3.10)


Previous Comments:


[2005-03-29 02:05:42] rob at wildlime dot com

Installed php 4.3.11 RC1 (windows) to c:\php, but PEAR wont't install. 
The error on running go-pear.bat, accepting the defaults, is: "failed to
write c:\php\pear\data\PEAR\.tmppackage.dtd" 

There is plenty of disk space and I'm using an admin account.



[2005-03-23 08:20:48] [EMAIL PROTECTED]

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





[2005-03-23 05:06:20] rob at wildlime dot com

having said that, it's just borked in php4ts.zend_strndup



[2005-03-23 05:01:09] rob at wildlime dot com

I *think* the fault is happening in function php4ts.virtual_getcwd_ex



[2005-03-23 04:07:10] rob at wildlime dot com

Description:

Experiencing an intermittent (once every 5-10 requests) access
violation.

btw, I have posted this to the PHP bug list rather than the PEAR one as
it is a crash, not just a script error.

Here's the info I can glean from the debugger.  I'm afraid I don't have
the debug builds.

Windows XP pro SP2
Apache/1.3.33 (Win32)
PHP/4.3.10

stack trace:
7C910C27 C:\WINDOWS\system32\ntdll.dll
7C910D5C C:\WINDOWS\system32\ntdll.dll
77C2C2DE C:\WINDOWS\system32\msvcrt.dll
77C39AE9 C:\WINDOWS\system32\msvcrt.dll
77C35F5D C:\WINDOWS\system32\msvcrt.dll
77C35FEC C:\WINDOWS\system32\msvcrt.dll
10047D4E c:\php4\php4ts.dll

or sometimes:
77C46137 C:\WINDOWS\system32\msvcrt.dll
100CA6AE c:\php4\php4ts.dll
60002E50 c:\php4\php4apache.dll
6000186F c:\php4\php4apache.dll

dll base addresses:
0x6000 php4apache.dll
0x1000 php4ts.dll

Reproduce code:
---
before($now);
?>

Expected result:

nothing - no output, so blank browser window

Actual result:
--
Access violation every 5-10 requests. 





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


#32429 [Ver]: method_exists() always return TRUE if __call method exists

2005-03-28 Thread pasha dot zubkov at gmail dot com
 ID:   32429
 User updated by:  pasha dot zubkov at gmail dot com
 Reported By:  pasha dot zubkov at gmail dot com
 Status:   Verified
 Bug Type: Zend Engine 2 problem
 Operating System: Linux 2.6.11-grsec
-PHP Version:  5CVS-2005-03-23 (dev)
+PHP Version:  5CVS-2005-03-29 (dev)
 New Comment:

Any solution for this bag?


Previous Comments:


[2005-03-24 14:20:44] pasha dot zubkov at gmail dot com

I checkout HEAD from cvs. Problem not solved.



[2005-03-24 00:27:55] [EMAIL PROTECTED]

Confirmed with HEAD only.



[2005-03-23 23:58:44] [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





[2005-03-23 14:43:34] pasha dot zubkov at gmail dot com

Description:

See example. I can't use `if (method_exists()) {}` because it always
return TRUE

Reproduce code:
---
test();
}
}

public function __call($name, $args) {
throw new Exception('Call to undefined method
'.get_class($this).'::'.$name.'()');
}
}

try {
$test = new TestClass;
} catch (Exception $e) {
exit($e->getMessage());
}

?>

Expected result:

bool(false)

Actual result:
--
bool(true) Call to undefined method TestClass::test()





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


#32461 [Fbk->Opn]: MySQL Extension Segmentation Fault

2005-03-28 Thread nofulfillment at numbinside dot net
 ID:   32461
 User updated by:  nofulfillment at numbinside dot net
 Reported By:  nofulfillment at numbinside dot net
-Status:   Feedback
+Status:   Open
 Bug Type: MySQL related
 Operating System: GNU/Linux (Slackware 10.1)
 PHP Version:  5.0.3
 New Comment:

Installed, up and running. I'll try to remember to force the error to
occur sometime tomorrow and report then.


Previous Comments:


[2005-03-29 00:43:34] [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





[2005-03-26 05:10:33] nofulfillment at numbinside dot net

Description:

I'm working with phpMyAdmin (irrelivent, but aids in understanding),
and I had the MYSQL_SOCKET file configured wrong. PHP's MySQL extension
was creating a Segmentation fault in that it was trying to read a
non-existant file. 

My configure line, I do not believe to be relavent, but I have included
it anyways. (Along with some other details from phpinfo())
System:Linux NcFTestServer-Linux 2.4.29-grsec #7 SMP Thu
Feb 3 18:41:23 PST 2005 i686
Build Date:Dec 23 2004 15:48:45
Configure Command: './configure' '--prefix=/usr' '--disable-static'
'--with-apxs=/usr/sbin/apxs' '--sysconfdir=/etc'
'--enable-discard-path' '--with-config-file-path=/etc/apache'
'--enable-safe-mode' '--with-openssl' '--with-mhash' '--enable-bcmath'
'--with-bz2' '--with-pic' '--enable-calendar' '--enable-ctype'
'--with-gdbm' '--with-db3' '--enable-dbase' '--enable-ftp'
'--with-iconv' '--with-exif' '--with-gd' '--enable-gd-native-ttf'
'--with-jpeg-dir=/usr' '--with-png' '--with-gmp' '--with-mysql'
'--with-gettext=shared,/usr' '--with-expat-dir=/usr' '--with-xml'
'--enable-wddx' '--with-mm=/usr' '--enable-trans-sid' '--enable-shmop'
'--enable-sockets' '--with-regex=php' '--enable-sysvsem'
'--enable-sysvshm' '--enable-yp' '--enable-memory-limit'
'--with-tsrm-pthreads' '--enable-shared' '--disable-debug'
'--with-zlib=/usr'

Using php.ini-recommended, although this does NOT change why it's
failing (tried falling back to -dist, but had the same problem). 

GDB backtrace is mostly irrelievent, and it was NOT built with
debugging symbols. 

I believe that this can be solved by checking to see if the file
exists.

Reproduce code:
---
Try connecting to MySQL using a non-existant local socket file. (i.e.,
/tmp/non-exist.sock)

Expected result:

When trying to run phpMyAdmin, I was expecting to see the login page.

Actual result:
--
Output from Bash trying to WGET it to see what happens:

[EMAIL PROTECTED]:/# wget http://server/phpMyAdmin_folder/index.php
--11:35:05--  http://server/phpMyAdmin_folder/index.php
Resolving server... done.
Connecting to server[i.p.v.4]:80... connected.
HTTP request sent, awaiting response...
11:35:06 ERROR -1: No data received.





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


#32478 [Opn->Bgs]: Execution functions do not work.

2005-03-28 Thread RJackson at InfoSharkz dot com
 ID:   32478
 User updated by:  RJackson at InfoSharkz dot com
 Reported By:  RJackson at InfoSharkz dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: Windows XP
 PHP Version:  5.0.3
 New Comment:

Found the issue.


Previous Comments:


[2005-03-29 02:45:02] RJackson at InfoSharkz dot com

Description:

The execution functions like passthru, exec, and system do not work on
PHP 5.0.3 to execute a program. No error message is returned. The
functions however work with PHP 4.3.10 with the same code and same
program.

The following is changed in my PHP.ini file:
extension_dir=C:\Program Files\PHP5
extension=php_mysql.dll
extension=php_gd2.dll
extension=php_curl.dll
error_log = error.txt
post_max_size = 20M
include_path = ".;m:\IS"
default_socket_timeout = 10

Reproduce code:
---


Expected result:

The script should copy the file file.jpg to t-file.jpg in the same
directory using Imagemagick.

Actual result:
--
The file is not copied.





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


#32465 [Bgs]: Compile fails on undefined symbol "res_nmkquery"

2005-03-28 Thread bkoenig at cs dot tu-berlin dot de
 ID:   32465
 User updated by:  bkoenig at cs dot tu-berlin dot de
 Reported By:  bkoenig at cs dot tu-berlin dot de
 Status:   Bogus
 Bug Type: Compile Failure
 Operating System: FreeBSD 5.3-RELEASE
 PHP Version:  5.0.3
 New Comment:

Yes, of course they are aliases in the header file.

Is there a way to exactly tell where the necessary header files are
located or a switch to avoid using these functions without removing
libbind? This would solve the problem in my case without using ugly
workarounds.

Regards Björn


Previous Comments:


[2005-03-29 00:42:30] [EMAIL PROTECTED]

As you're obviously just assuming, bogus. (I don't see any errors
here..) And it's perfectly okay to check for the funcs like that:
They're aliased in a header file.




[2005-03-27 03:35:34] bkoenig at cs dot tu-berlin dot de

Description:

Isn't it just wrong that the configure script of PHP detects

checking for res_nmkquery in -lbind... no
checking for __res_nmkquery in -lbind... yes

but PHP uses res_nmkquery nevertheless?

This affects res_ninit, res_nmkquery, res_nsend and res_nclose  in
ext/standard/dns.c and the compilation will fail definitely.

Regards Björn







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


#31137 [Asn->Csd]: stream_filter_remove() segfaults when stream is already closed

2005-03-28 Thread pollita
 ID:   31137
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tony2001 at phpclub dot net
-Status:   Assigned
+Status:   Closed
 Bug Type: Filesystem function related
 Operating System: *
 PHP Version:  5CVS-2004-12-16
 Assigned To:  pollita
 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.

Thanks for keeping me honest Jani


Previous Comments:


[2005-03-29 01:11:03] [EMAIL PROTECTED]

Assigning to correct developer. (And Sara: this is still broken in HEAD
:)




[2004-12-16 22:17:00] tony2001 at phpclub dot net

Description:

Segfault when trying to remove stream filter *after* closing the stream
itself.
Wez, please, look into this, I don't have much time to debug it myself
ATM.

Reproduce code:
---


Expected result:

.

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x08141ef2 in _php_stream_filter_flush (filter=0x82c54bc, finish=1) at
/home/dev/php-src/main/streams/filter.c:418
418 if (!filter->chain || !filter->chain->stream) {
(gdb) bt
#0  0x08141ef2 in _php_stream_filter_flush (filter=0x82c54bc, finish=1)
at /home/dev/php-src/main/streams/filter.c:418
#1  0x081213c5 in zif_stream_filter_remove (ht=1,
return_value=0x82b2bfc, this_ptr=0x0, return_value_used=0)
at /home/dev/php-src/ext/standard/streamsfuncs.c:1143
#2  0x0818fb03 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffd3c0) at zend_vm_execute.h:155
#3  0x08192531 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xbfffd3c0) at zend_vm_execute.h:1514
#4  0x0818f81b in execute (op_array=0x82c0814) at zend_vm_execute.h:58
#5  0x0816cba7 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/dev/php-src/Zend/zend.c:1062
#6  0x0812ce37 in php_execute_script (primary_file=0xb7d0) at
/home/dev/php-src/main/main.c:1639
#7  0x081dcb25 in main (argc=2, argv=0xb864) at
/home/dev/php-src/sapi/cli/php_cli.c:943
#8  0x420157a4 in __libc_start_main () from /lib/tls/libc.so.6





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


#32478 [NEW]: Execution functions do not work.

2005-03-28 Thread RJackson at InfoSharkz dot com
From: RJackson at InfoSharkz dot com
Operating system: Windows XP
PHP version:  5.0.3
PHP Bug Type: Unknown/Other Function
Bug description:  Execution functions do not work.

Description:

The execution functions like passthru, exec, and system do not work on PHP
5.0.3 to execute a program. No error message is returned. The functions
however work with PHP 4.3.10 with the same code and same program.

The following is changed in my PHP.ini file:
extension_dir=C:\Program Files\PHP5
extension=php_mysql.dll
extension=php_gd2.dll
extension=php_curl.dll
error_log = error.txt
post_max_size = 20M
include_path = ".;m:\IS"
default_socket_timeout = 10

Reproduce code:
---


Expected result:

The script should copy the file file.jpg to t-file.jpg in the same
directory using Imagemagick.

Actual result:
--
The file is not copied.

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


#32422 [Fbk->Opn]: Access Violation on calling PEAR Date::before

2005-03-28 Thread rob at wildlime dot com
 ID:   32422
 User updated by:  rob at wildlime dot com
 Reported By:  rob at wildlime dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows XP SP2
 PHP Version:  4.3.10
 New Comment:

Installed php 4.3.11 RC1 (windows) to c:\php, but PEAR wont't install. 
The error on running go-pear.bat, accepting the defaults, is: "failed to
write c:\php\pear\data\PEAR\.tmppackage.dtd" 

There is plenty of disk space and I'm using an admin account.


Previous Comments:


[2005-03-23 08:20:48] [EMAIL PROTECTED]

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





[2005-03-23 05:06:20] rob at wildlime dot com

having said that, it's just borked in php4ts.zend_strndup



[2005-03-23 05:01:09] rob at wildlime dot com

I *think* the fault is happening in function php4ts.virtual_getcwd_ex



[2005-03-23 04:07:10] rob at wildlime dot com

Description:

Experiencing an intermittent (once every 5-10 requests) access
violation.

btw, I have posted this to the PHP bug list rather than the PEAR one as
it is a crash, not just a script error.

Here's the info I can glean from the debugger.  I'm afraid I don't have
the debug builds.

Windows XP pro SP2
Apache/1.3.33 (Win32)
PHP/4.3.10

stack trace:
7C910C27 C:\WINDOWS\system32\ntdll.dll
7C910D5C C:\WINDOWS\system32\ntdll.dll
77C2C2DE C:\WINDOWS\system32\msvcrt.dll
77C39AE9 C:\WINDOWS\system32\msvcrt.dll
77C35F5D C:\WINDOWS\system32\msvcrt.dll
77C35FEC C:\WINDOWS\system32\msvcrt.dll
10047D4E c:\php4\php4ts.dll

or sometimes:
77C46137 C:\WINDOWS\system32\msvcrt.dll
100CA6AE c:\php4\php4ts.dll
60002E50 c:\php4\php4apache.dll
6000186F c:\php4\php4apache.dll

dll base addresses:
0x6000 php4apache.dll
0x1000 php4ts.dll

Reproduce code:
---
before($now);
?>

Expected result:

nothing - no output, so blank browser window

Actual result:
--
Access violation every 5-10 requests. 





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


#32475 [Fbk->Opn]: Memory Leak

2005-03-28 Thread lacey at lacey dot cc
 ID:   32475
 User updated by:  lacey at lacey dot cc
 Reported By:  lacey at lacey dot cc
-Status:   Feedback
+Status:   Open
 Bug Type: IIS related
 Operating System: Windows XP
 PHP Version:  5CVS-2005-03-29
 New Comment:

Yes.  Of course I will download those and do more testing.  I'll let
you know if I find out anything further.  But I've already given you
the exact subroutine.  It's the call to TSRMLS_FETCH() which calls
ts_resource_ex in trsm.c

ts_resouce_ex allocates the memory, and ts_free_thread somehow doesn't
free it all.  The memory keeps growing with the implementation of each
thread until the Server crashes.  I'd assume that's where you need to
look.  Or am I missing something here?

Jakub has explained the same scenario in this report as well.

http://bugs.php.net/bug.php?id=23331

Thanks.


Previous Comments:


[2005-03-29 01:19:04] [EMAIL PROTECTED]

Get these packages: 

http://snaps.php.net/win32/php5-win32-latest.zip
http://snaps.php.net/win32/php5-dbgpack-win32-latest.zip

And try provide some useful information about the crash.




[2005-03-28 20:17:13] lacey at lacey dot cc

BTW:  I've seen this Bug Reort:

http://bugs.php.net/bug.php?id=23331

But it's 2 years old and it's marked as Bogus.



[2005-03-28 17:29:32] lacey at lacey dot cc

Description:

Memory Leak using the php5isapi.dll under IIS.  When TSRMLS_FETCH() is
called from HTTPExtensionProc, ts_free_thread leaves a Memory Leak of
approximately 100K for every call.  When TSRMLS_FETCH() isn't called,
there's no leak.  This leak will crash a Server under light loads
within a few hours.






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


#30377 [Asn]: Problem with php_check_syntax()

2005-03-28 Thread sniper
 ID:   30377
 Updated by:   [EMAIL PROTECTED]
 Reported By:  guth at fiifo dot u-psud dot fr
 Status:   Assigned
 Bug Type: Filesystem function related
 Operating System: *
 PHP Version:  5CVS-2005-03-29
-Assigned To:  wez
+Assigned To:  iliaa
 New Comment:

Propably same as bug #31918



Previous Comments:


[2004-10-11 07:52:33] [EMAIL PROTECTED]

Wez, I saw this before too, seems streams related.



[2004-10-09 22:39:13] guth at fiifo dot u-psud dot fr

Description:

I get an error when i use php_check_syntax() with an invalid PHP file.

Reproduce code:
---


in test2.php



Expected result:

bool(false)

Actual result:
--
bool(false)

/usr/src/php5-STABLE-200410091830/main/streams/streams.c(375) : Stream
of type 'STDIO' 0x831c7ec (path:test2.php) was not closed

The following diff seems to correct the problem :

[EMAIL PROTECTED] php5-STABLE-200410091830]$ diff main/main.c2
main/main.c
1751a1752,1753
>   zend_destroy_file_handle(file TSRMLS_CC);
>






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


#31918 [Asn]: unlink($file) permission denied, when php_check_syntax($file) fails

2005-03-28 Thread sniper
 ID:   31918
 Updated by:   [EMAIL PROTECTED]
 Reported By:  du at bestwaytech dot com
 Status:   Assigned
 Bug Type: Filesystem function related
 Operating System: *
 PHP Version:  5.*
 Assigned To:  iliaa
 New Comment:

See also bug #30377



Previous Comments:


[2005-03-22 21:38:31] [EMAIL PROTECTED]

This happens because of this, found in main/main.c:1746-1755

zend_try {
  op_array = zend_compile_file(file, ZEND_INCLUDE...
  zend_destroy_file_handle(file TSRMLS_CC);
...
} zend_end_try

The zend_destroy_file_handle() is never called if there are any parse
errors in the file as zend_compile_file() throw a zend_bailout(). 

Assigned to Ilia.





[2005-02-10 20:11:01] du at bestwaytech dot com

Description:

In order to load custom functions I write them to temporary file, check
syntax and load only if syntax correct. When syntax validates,
everything is fine. When syntax is incorrect, I am unable to delete the
created temporary file.

Reproduce code:
---
$function = '';
$file = tempnam("c:", "scr");
$handle = fopen($file, "w+");
fwrite($handle, $function);
if (!php_check_syntax($file)) {
echo "syntax error - ";
} else {
echo "syntax ok - ";
}
if (fclose($handle)) {
echo "closed - ";
} else {
echo "not closed - ";
}
if (unlink($file)) {
echo "deleted";
} else {
echo "not deleted";
}

Expected result:

syntax error - closed - deleted

Actual result:
--
syntax error - closed -
Warning: Unknown: Permission denied in Unknown on line 0
not deleted





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


#32472 [Opn->Bgs]: DOMDocument::createElement changes property value

2005-03-28 Thread sniper
 ID:   32472
 Updated by:   [EMAIL PROTECTED]
 Reported By:  c dot d at earthlink dot net
-Status:   Open
+Status:   Bogus
 Bug Type: DOM XML related
 Operating System: Mac OS X 10.3.8
 PHP Version:  5.0.3
 New Comment:

Sorry but we don't support any binary releases except for the win32
ones.



Previous Comments:


[2005-03-29 01:17:34] c dot d at earthlink dot net

I'm using the Entropy 5.0.3 rev. 4 release. I'm sorry, but I just don't
know enough about building it myself. Pretty much any time I have for
programming I have to devote to php.

However, apparently 5.0.4 is emminent (according to php.internals). So
I'll report the results with that release when it becomes available
from the Entropy site.



[2005-03-28 13:22:08] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-03-28 13:12:16] c dot d at earthlink dot net

Description:

I'm using libxml2 2.6.17.

In the following code, the call to createElement() changes the value of
the private property $rootTag to null.

Reproduce code:
---
preserveWhiteSpace = FALSE;
$this->formatOutput = FALSE;

if ($rootTag) {
$this->rootTag = $rootTag;
}
else {
$this->rootTag = 'table';
}

if ($rowTag) {
$this->rowTag = $rowTag;
}
else {
$this->rowTag = 'row';
}

$this->appendChild($this->createElement($this->rootTag));

}

}

$modulesDOM = new bdmDOMTable('modules', 'module');

var_dump($modulesDOM);
?>

Expected result:

object(bdmDOMTable)#1 (2) { ["rootTag:private"]=>  string(7) "modules"
["rowTag:private"]=>  string(6) "module" }

Actual result:
--
object(bdmDOMTable)#1 (2) { ["rootTag:private"]=>  NULL
["rowTag:private"]=>  string(6) "module" }







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


#32475 [Opn->Fbk]: Memory Leak

2005-03-28 Thread sniper
 ID:   32475
 Updated by:   [EMAIL PROTECTED]
 Reported By:  lacey at lacey dot cc
-Status:   Open
+Status:   Feedback
 Bug Type: IIS related
 Operating System: Windows XP
 PHP Version:  5CVS-2005-03-29
 New Comment:

Get these packages: 

http://snaps.php.net/win32/php5-win32-latest.zip
http://snaps.php.net/win32/php5-dbgpack-win32-latest.zip

And try provide some useful information about the crash.



Previous Comments:


[2005-03-28 20:17:13] lacey at lacey dot cc

BTW:  I've seen this Bug Reort:

http://bugs.php.net/bug.php?id=23331

But it's 2 years old and it's marked as Bogus.



[2005-03-28 17:29:32] lacey at lacey dot cc

Description:

Memory Leak using the php5isapi.dll under IIS.  When TSRMLS_FETCH() is
called from HTTPExtensionProc, ts_free_thread leaves a Memory Leak of
approximately 100K for every call.  When TSRMLS_FETCH() isn't called,
there's no leak.  This leak will crash a Server under light loads
within a few hours.






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


#32472 [Fbk->Opn]: DOMDocument::createElement changes property value

2005-03-28 Thread c dot d at earthlink dot net
 ID:   32472
 User updated by:  c dot d at earthlink dot net
 Reported By:  c dot d at earthlink dot net
-Status:   Feedback
+Status:   Open
 Bug Type: DOM XML related
 Operating System: Mac OS X 10.3.8
 PHP Version:  5.0.3
 New Comment:

I'm using the Entropy 5.0.3 rev. 4 release. I'm sorry, but I just don't
know enough about building it myself. Pretty much any time I have for
programming I have to devote to php.

However, apparently 5.0.4 is emminent (according to php.internals). So
I'll report the results with that release when it becomes available
from the Entropy site.


Previous Comments:


[2005-03-28 13:22:08] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-03-28 13:12:16] c dot d at earthlink dot net

Description:

I'm using libxml2 2.6.17.

In the following code, the call to createElement() changes the value of
the private property $rootTag to null.

Reproduce code:
---
preserveWhiteSpace = FALSE;
$this->formatOutput = FALSE;

if ($rootTag) {
$this->rootTag = $rootTag;
}
else {
$this->rootTag = 'table';
}

if ($rowTag) {
$this->rowTag = $rowTag;
}
else {
$this->rowTag = 'row';
}

$this->appendChild($this->createElement($this->rootTag));

}

}

$modulesDOM = new bdmDOMTable('modules', 'module');

var_dump($modulesDOM);
?>

Expected result:

object(bdmDOMTable)#1 (2) { ["rootTag:private"]=>  string(7) "modules"
["rowTag:private"]=>  string(6) "module" }

Actual result:
--
object(bdmDOMTable)#1 (2) { ["rootTag:private"]=>  NULL
["rowTag:private"]=>  string(6) "module" }







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


#31137 [Opn->Asn]: stream_filter_remove() segfaults when stream is already closed

2005-03-28 Thread sniper
 ID:   31137
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tony2001 at phpclub dot net
-Status:   Open
+Status:   Assigned
 Bug Type: Filesystem function related
-Operating System: Linux
+Operating System: *
 PHP Version:  5CVS-2004-12-16
-Assigned To:  
+Assigned To:  pollita
 New Comment:

Assigning to correct developer. (And Sara: this is still broken in HEAD
:)



Previous Comments:


[2004-12-16 22:17:00] tony2001 at phpclub dot net

Description:

Segfault when trying to remove stream filter *after* closing the stream
itself.
Wez, please, look into this, I don't have much time to debug it myself
ATM.

Reproduce code:
---


Expected result:

.

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x08141ef2 in _php_stream_filter_flush (filter=0x82c54bc, finish=1) at
/home/dev/php-src/main/streams/filter.c:418
418 if (!filter->chain || !filter->chain->stream) {
(gdb) bt
#0  0x08141ef2 in _php_stream_filter_flush (filter=0x82c54bc, finish=1)
at /home/dev/php-src/main/streams/filter.c:418
#1  0x081213c5 in zif_stream_filter_remove (ht=1,
return_value=0x82b2bfc, this_ptr=0x0, return_value_used=0)
at /home/dev/php-src/ext/standard/streamsfuncs.c:1143
#2  0x0818fb03 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffd3c0) at zend_vm_execute.h:155
#3  0x08192531 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xbfffd3c0) at zend_vm_execute.h:1514
#4  0x0818f81b in execute (op_array=0x82c0814) at zend_vm_execute.h:58
#5  0x0816cba7 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/dev/php-src/Zend/zend.c:1062
#6  0x0812ce37 in php_execute_script (primary_file=0xb7d0) at
/home/dev/php-src/main/main.c:1639
#7  0x081dcb25 in main (argc=2, argv=0xb864) at
/home/dev/php-src/sapi/cli/php_cli.c:943
#8  0x420157a4 in __libc_start_main () from /lib/tls/libc.so.6





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


#31137 [Asn->Opn]: stream_filter_remove() segfaults when stream is already closed

2005-03-28 Thread sniper
 ID:   31137
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tony2001 at phpclub dot net
-Status:   Assigned
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: Linux
 PHP Version:  5CVS-2004-12-16
 Assigned To:  wez


Previous Comments:


[2004-12-16 22:17:00] tony2001 at phpclub dot net

Description:

Segfault when trying to remove stream filter *after* closing the stream
itself.
Wez, please, look into this, I don't have much time to debug it myself
ATM.

Reproduce code:
---


Expected result:

.

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x08141ef2 in _php_stream_filter_flush (filter=0x82c54bc, finish=1) at
/home/dev/php-src/main/streams/filter.c:418
418 if (!filter->chain || !filter->chain->stream) {
(gdb) bt
#0  0x08141ef2 in _php_stream_filter_flush (filter=0x82c54bc, finish=1)
at /home/dev/php-src/main/streams/filter.c:418
#1  0x081213c5 in zif_stream_filter_remove (ht=1,
return_value=0x82b2bfc, this_ptr=0x0, return_value_used=0)
at /home/dev/php-src/ext/standard/streamsfuncs.c:1143
#2  0x0818fb03 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffd3c0) at zend_vm_execute.h:155
#3  0x08192531 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xbfffd3c0) at zend_vm_execute.h:1514
#4  0x0818f81b in execute (op_array=0x82c0814) at zend_vm_execute.h:58
#5  0x0816cba7 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/dev/php-src/Zend/zend.c:1062
#6  0x0812ce37 in php_execute_script (primary_file=0xb7d0) at
/home/dev/php-src/main/main.c:1639
#7  0x081dcb25 in main (argc=2, argv=0xb864) at
/home/dev/php-src/sapi/cli/php_cli.c:943
#8  0x420157a4 in __libc_start_main () from /lib/tls/libc.so.6





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


#32237 [Fbk->NoF]: 200503081930: sun forte compiler gives a lot of warnings

2005-03-28 Thread php-bugs
 ID:   32237
 Updated by:   php-bugs@lists.php.net
 Reported By:  soloturn99 at yahoo dot com
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Compile Warning
 Operating System: solaris 8
 PHP Version:  5CVS-2005-03-08 (dev)
 New Comment:

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".


Previous Comments:


[2005-03-20 02:03:28] [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





[2005-03-09 19:27:44] soloturn99 at yahoo dot com

thanks a lot! this time it compiles.

for element.c and simplexml.c the warnings are still there. the others
i did not cross check.

but as it compiled to the end, there were some new warnings:

"/usr/local/src/php5-200503091730/ext/standard/image.c", line 554:
warning: statement not reached
"/usr/local/src/php5-200503091730/ext/standard/image.c", line 565:
warning: argument #2 is incompatible with prototype:
prototype: pointer to char :
"/usr/local/src/php5-200503091730/main/php_streams.h", line 278
argument : pointer to unsigned char
"/usr/local/src/php5-200503091730/ext/standard/image.c", line 830:
warning: assignment type mismatch:
pointer to unsigned char "=" pointer to char
"/usr/local/src/php5-200503091730/ext/standard/image.c", line 888:
warning: argument #2 is incompatible with prototype:
prototype: pointer to char :
"/usr/local/src/php5-200503091730/main/php_streams.h", line 278
argument : pointer to unsigned char
"/usr/local/src/php5-200503091730/ext/standard/image.c", line 891:
warning: argument #1 is incompatible with prototype:
prototype: pointer to const char :
"/usr/include/iso/string_iso.h", line 72
argument : pointer to unsigned char
"/usr/local/src/php5-200503091730/ext/standard/image.c", line 891:
warning: argument #1 is incompatible with prototype:
prototype: pointer to const char :
"/usr/include/iso/string_iso.h", line 72
argument : pointer to unsigned char
"/usr/local/src/php5-200503091730/ext/standard/image.c", line 897:
warning: argument #2 is incompatible with prototype:
prototype: pointer to char :
"/usr/local/src/php5-200503091730/main/php_streams.h", line 278
argument : pointer to unsigned char
"/usr/local/src/php5-200503091730/ext/standard/image.c", line 909:
warning: argument #2 is incompatible with prototype:
prototype: pointer to char :
"/usr/local/src/php5-200503091730/main/php_streams.h", line 278
argument : pointer to unsigned char
"/usr/local/src/php5-200503091730/ext/standard/html.c", line 889:
warning: argument #1 is incompatible with prototype:
prototype: pointer to const char :
"/usr/local/src/php5-200503091730/Zend/zend_alloc.h", line 85
argument : pointer to unsigned char
"/usr/local/src/php5-200503091730/ext/standard/html.c", line 910:
warning: argument #1 is incompatible with prototype:
prototype: pointer to char : "/usr/include/iso/string_iso.h",
line 73
argument : pointer to unsigned char
"/usr/local/src/php5-200503091730/ext/standard/html.c", line 947:
warning: argument #2 is incompatible with prototype:
prototype: pointer to char :
"/usr/local/src/php5-200503091730/Zend/zend_operators.h", line 132
argument : pointer to unsigned char
"/usr/local/src/php5-200503091730/ext/standard/html.c", line 948:
warning: argument #3 is incompatible with prototype:
prototype: pointer to char :
"/usr/local/src/php5-200503091730/ext/standard/php_string.h", line 130
argument : pointer to unsigned char
"/usr/local/src/php5-200503091730/ext/standard/html.c", line 948:
warning: argument #5 is incompatible with prototype:
prototype: pointer to char :
"/usr/local/src/php5-200503091730/ext/standard/php_string.h", line 130
argument : pointer to unsigned char
"/usr/local/src/php5-200503091730/ext/standard/html.c", line 965:
warning: argument #5 is incompatible with prototype:
prototype: pointer to char :
"/usr/local/src/php5-200503091730/ext/standard/php_string.h", line 130
argument : pointer to unsigned char
"/usr/local/src/php5-200503091730/ext/standard/html.c", line 990:
warning: argument #1 is incompatible with prototype:
prototype: pointer to unsigned char :
"/usr/local/src/php5-200503091730/ext/standard/html.c", line 834
argument : pointer to char
"/usr/local/src/php5-200503091730/ext/standard/html.c", line 1123:
warning: argument #2 is incompatible with prototype:
prototype: pointer to const char :
"/usr/include/iso/string_iso.h", line 66
  

#32390 [Fbk->NoF]: PHP can't compile with imap that enabled Kerberos by heimdal

2005-03-28 Thread php-bugs
 ID:   32390
 Updated by:   php-bugs@lists.php.net
 Reported By:  ptiggerdine at fastmail dot com dot au
-Status:   Feedback
+Status:   No Feedback
 Bug Type: IMAP related
 Operating System: Gentoo linux
 PHP Version:  4.3.10
 New Comment:

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".


Previous Comments:


[2005-03-21 11:02:59] [EMAIL PROTECTED]

Can you answer the question please? 




[2005-03-21 10:45:25] ptiggerdine at fastmail dot com dot au

Also, if your not going to support heimdal then my suggestion is allow
php to identify that the heimdal are there and not to try and compile
kerberos in, rather than stop the ./configure script



[2005-03-21 10:42:39] [EMAIL PROTECTED]

I'll ask again: Does the uw-imap c-client library support heimdal
implementation of kerberos?




[2005-03-21 10:35:23] ptiggerdine at fastmail dot com dot au

Can i ask why "you only support MIT only"?  Supporting heimdal would be
beneficial to php there are more project moving form MIT to heimdal.



[2005-03-21 10:22:40] [EMAIL PROTECTED]

I'm the one who this was "escaleted" to..so thanks anyway but   we
don't support any other kerberos library implementation than those that
are supported by the c-client library.




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

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


#32475 [Fbk->Opn]: Memory Leak

2005-03-28 Thread lacey at lacey dot cc
 ID:   32475
 User updated by:  lacey at lacey dot cc
 Reported By:  lacey at lacey dot cc
-Status:   Feedback
+Status:   Open
 Bug Type: IIS related
 Operating System: Windows XP
 PHP Version:  5.0.3
 New Comment:

Thanks.  I think that was the one I was using.  But I just downloaded
it and tested it and I'm getting the same symptoms.


Previous Comments:


[2005-03-29 00:40:29] [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





[2005-03-28 20:17:13] lacey at lacey dot cc

BTW:  I've seen this Bug Reort:

http://bugs.php.net/bug.php?id=23331

But it's 2 years old and it's marked as Bogus.



[2005-03-28 17:29:32] lacey at lacey dot cc

Description:

Memory Leak using the php5isapi.dll under IIS.  When TSRMLS_FETCH() is
called from HTTPExtensionProc, ts_free_thread leaves a Memory Leak of
approximately 100K for every call.  When TSRMLS_FETCH() isn't called,
there's no leak.  This leak will crash a Server under light loads
within a few hours.






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


#31177 [Ver]: Memory leak

2005-03-28 Thread sniper
 ID:   31177
 Updated by:   [EMAIL PROTECTED]
 Reported By:  guth at fiifo dot u-psud dot fr
 Status:   Verified
 Bug Type: Zend Engine 2 problem
 Operating System: *
-PHP Version:  5CVS (2005-01-10)
+PHP Version:  5CVS-2005-03-24
 New Comment:

/usr/src/php/php5/Zend/zend_vm_execute.h(370) :  Freeing 0x08FBAECC (16
bytes), script=t.php
=== Total 1 memory leaks detected ===



Previous Comments:


[2005-01-07 18:56:57] [EMAIL PROTECTED]

/usr/src/web/php/php5/Zend/zend_vm_execute.h(350) :  Freeing 0x0880A664
(16 bytes)




[2004-12-18 10:41:02] guth at fiifo dot u-psud dot fr

Description:

The following code produces a memory leak :

/usr/src/php-5.0.3RC1/Zend/zend_execute.c(3255) :  Freeing 0x0816FB6C
(16 bytes), script=/www/test3.php
=== Total 1 memory leaks detected ===

Reproduce code:
---
query());
}

}

class DbGowRecordSet {

public function __construct($resource) {

}

}


$db = new DbGow;

try {
$rs = $db->select();
}
catch(Exception $e) {
}

?>






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


#31248 [Opn->Asn]: SOAP-Client: mapping of overloaded functions fail

2005-03-28 Thread sniper
 ID:   31248
 Updated by:   [EMAIL PROTECTED]
 Reported By:  andreas dot filsinger at cargobay dot de
-Status:   Open
+Status:   Assigned
 Bug Type: SOAP related
-Operating System: independent
+Operating System: *
-PHP Version:  5.0.3
+PHP Version:  5CVS-2005-03-26
 Assigned To:  dmitry


Previous Comments:


[2005-03-26 13:30:46] andreas dot filsinger at cargobay dot de

26 Mar 2005

"latest" seems to be late enough. It has a timestamp from 23 Mar 2005
at 08:50. Anyway I check it again this version with no succes. I will
check again when CVS can make builds again.

Andreas Filsinger



[2005-03-25 01:25:13] [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





[2004-12-22 16:03:34] andreas dot filsinger at cargobay dot de

Description:

the WSDL of "Apache.AXIS for Java" implements sort of
function-overloading. If you have 3 published functions:

 int foo (int a,b);
 int foo (string a,b);
 int foo (int x);

in XML this is done by extending the Function-Names by numbers:
  
 http://$user:[EMAIL PROTECTED]/ws/services/$service",
 array( 
   "login"  => "$user", 
   "password"  => "$pwd", 
   "trace"  => 1, 
   "exceptions" => 0) );
   
$r = $client->__getFunctions();
foreach($r as $v)
echo $v . "";  


Expected result:

a) Quick Patch

make a function name mapping to

 getMap(...
 getMap1(...
 getMap2(...

so i can use getMap2(.. and be happy!

b) php 6.0.0 ;-)

 true identical function names, if this is called try to fill the
function-parameters from the first function with this name, if this
fails, take the next with this name ...
take that implemetation where filling the parameter does not fail. If
there no implementation fits: create an error. If more than one
parameter fits: create an error:



Actual result:
--
* all the overloaded functions have the parameter set of the most
top-function.





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


#32459 [Opn->Bgs]: "No input" if running PHP on secondary site

2005-03-28 Thread sniper
 ID:   32459
 Updated by:   [EMAIL PROTECTED]
 Reported By:  peter dot ordal at rochester dot edu
-Status:   Open
+Status:   Bogus
 Bug Type: IIS related
 Operating System: Windows Server 2003
 PHP Version:  5.0.3
 New Comment:

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

Thank you for your interest in PHP.

..


Previous Comments:


[2005-03-28 19:12:26] peter dot ordal at rochester dot edu

I gave CVS a try, but the problem persists.

If I use the "working" document root I get the version string
5.1.0-dev, just for confirmation.



[2005-03-25 23:33:42] [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





[2005-03-25 23:11:02] peter dot ordal at rochester dot edu

Description:

I have PHP identically configured for two Web Sites under a single
instance of IIS 6 on Windows Server 2003. In one, which has the
identifier of 1 and runs on port 80, requests to .php files return
normally. In the other, which has the identifier of 136095314 and
listens on port 81, requests to PHP error for both ISAPI and CGI, with
these messages:

When using php5isapi.dll: "No input file specified."
When using php-cgi.exe: CGI Error. The specified CGI application
misbehaved by not returning a complete set of HTTP headers.

The two Web Sites have different document roots. This does seem
important, as setting them to have the same document root fixes the
issue.
Primary: c:\inetpub\wwwroot
Secondary: c:\inetpub\sandbox

I discovered this bug by first attempting to install PHP 5.0.3 on the
secondary site. This bug is not dependent on the value of the doc_root
variable in php.ini. It can be set correctly, set incorrectly, or
unset. Other bugs suggest fixing doc_root to resolve this error, but I
am certain that the value of the doc_root variable does not impact the
error. Eventually I had no options left but to try PHP 5 on the primary
site, which worked.

Web Service Extensions have been set up to permit both php5isapi.dll
and php-cgi.exe, and the wildcard extension has been Allowed (to be
sure this was not a simple security issue).

In both Web Sites, the PHP configuration under Home Directory ->
Configuration -> Mappings is
Extension: .php
Executable: C:\php-5.0.3-Win32\php-cgi.exe %s or
C:\php-5.0.3-Win32\php5isapi.dll
Verbs: All
Script Engine: Checked
Verify File Exists: Checked

Cache ISAPI Extensions is disabled. I frequently restarted the IIS
Admin service is testing this.

For curious users, I was able to run PHP 5 without impacting PHP 4 with
the instructions attached to this bug:
http://bugs.php.net/bug.php?id=28448. This allows you to keep separate
php.ini files.

Reproduce code:
---


Expected result:

Standard PHP info dump.

Actual result:
--
"No input file specified.", or, when using php-cgi.exe: CGI Error. The
specified CGI application misbehaved by not returning a complete set of
HTTP headers.





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


#32461 [Opn->Fbk]: MySQL Extension Segmentation Fault

2005-03-28 Thread sniper
 ID:   32461
 Updated by:   [EMAIL PROTECTED]
 Reported By:  nofulfillment at numbinside dot net
-Status:   Open
+Status:   Feedback
 Bug Type: MySQL related
 Operating System: GNU/Linux (Slackware 10.1)
 PHP Version:  5.0.3
 New Comment:

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




Previous Comments:


[2005-03-26 05:10:33] nofulfillment at numbinside dot net

Description:

I'm working with phpMyAdmin (irrelivent, but aids in understanding),
and I had the MYSQL_SOCKET file configured wrong. PHP's MySQL extension
was creating a Segmentation fault in that it was trying to read a
non-existant file. 

My configure line, I do not believe to be relavent, but I have included
it anyways. (Along with some other details from phpinfo())
System:Linux NcFTestServer-Linux 2.4.29-grsec #7 SMP Thu
Feb 3 18:41:23 PST 2005 i686
Build Date:Dec 23 2004 15:48:45
Configure Command: './configure' '--prefix=/usr' '--disable-static'
'--with-apxs=/usr/sbin/apxs' '--sysconfdir=/etc'
'--enable-discard-path' '--with-config-file-path=/etc/apache'
'--enable-safe-mode' '--with-openssl' '--with-mhash' '--enable-bcmath'
'--with-bz2' '--with-pic' '--enable-calendar' '--enable-ctype'
'--with-gdbm' '--with-db3' '--enable-dbase' '--enable-ftp'
'--with-iconv' '--with-exif' '--with-gd' '--enable-gd-native-ttf'
'--with-jpeg-dir=/usr' '--with-png' '--with-gmp' '--with-mysql'
'--with-gettext=shared,/usr' '--with-expat-dir=/usr' '--with-xml'
'--enable-wddx' '--with-mm=/usr' '--enable-trans-sid' '--enable-shmop'
'--enable-sockets' '--with-regex=php' '--enable-sysvsem'
'--enable-sysvshm' '--enable-yp' '--enable-memory-limit'
'--with-tsrm-pthreads' '--enable-shared' '--disable-debug'
'--with-zlib=/usr'

Using php.ini-recommended, although this does NOT change why it's
failing (tried falling back to -dist, but had the same problem). 

GDB backtrace is mostly irrelievent, and it was NOT built with
debugging symbols. 

I believe that this can be solved by checking to see if the file
exists.

Reproduce code:
---
Try connecting to MySQL using a non-existant local socket file. (i.e.,
/tmp/non-exist.sock)

Expected result:

When trying to run phpMyAdmin, I was expecting to see the login page.

Actual result:
--
Output from Bash trying to WGET it to see what happens:

[EMAIL PROTECTED]:/# wget http://server/phpMyAdmin_folder/index.php
--11:35:05--  http://server/phpMyAdmin_folder/index.php
Resolving server... done.
Connecting to server[i.p.v.4]:80... connected.
HTTP request sent, awaiting response...
11:35:06 ERROR -1: No data received.





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


#32465 [Opn->Bgs]: Compile fails on undefined symbol "res_nmkquery"

2005-03-28 Thread sniper
 ID:   32465
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bkoenig at cs dot tu-berlin dot de
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: FreeBSD 5.3-RELEASE
 PHP Version:  5.0.3
 New Comment:

As you're obviously just assuming, bogus. (I don't see any errors
here..) And it's perfectly okay to check for the funcs like that:
They're aliased in a header file.



Previous Comments:


[2005-03-27 03:35:34] bkoenig at cs dot tu-berlin dot de

Description:

Isn't it just wrong that the configure script of PHP detects

checking for res_nmkquery in -lbind... no
checking for __res_nmkquery in -lbind... yes

but PHP uses res_nmkquery nevertheless?

This affects res_ninit, res_nmkquery, res_nsend and res_nclose  in
ext/standard/dns.c and the compilation will fail definitely.

Regards Björn







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


#32469 [Opn->Fbk]: With serial ports, fread is using the fwrite buffer

2005-03-28 Thread sniper
 ID:   32469
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mccaskey at stanford dot edu
-Status:   Open
+Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: Windows XP
 PHP Version:  5.0.3
 New Comment:

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




Previous Comments:


[2005-03-28 03:56:10] mccaskey at stanford dot edu

Description:

(1) Open a COM port as a serial input using fopen. Read using fread or
fgets. No data appears until 8K bytes have been read. There is an 8K
buffer on writes, but there shouldn't be one on reads. (Should there?)
Are reads somehow using the write buffer? Sure enough:

(2) Again, open a COM port as a serial input using fopen. This time,
write some characters using fwrite. Now fread 8K of serial data. At the
head of that stream appears the data you had written with fwrite. Oops.

[Several people have reported an inability to get fgets to read COM
data, saying they tried and fgets just never sees any input. I assume
this was their problem. But others have reported using fgets on COM
successfully. Something specific to OS/PHP versions?] 

Reproduce code:
---
(1) 
$serial_port = fopen("COM4", "r+");
echo(fread($serial_port, 8192));

(2)
$serial_port = fopen("COM4", "r+");
fwrite($serial_port, "MP");
echo(fread($serial_port, 8192));

Expected result:

(1) & (2)
serial data starting with the first byte that came in on the serial
line


Actual result:
--
(1) Nothing until 8K of data has been read in.

(2) After enough serial data to fill the buffer, first the data written
("MP" in this example), then the data that came in on the serial line.





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


#32475 [Opn->Fbk]: Memory Leak

2005-03-28 Thread sniper
 ID:   32475
 Updated by:   [EMAIL PROTECTED]
 Reported By:  lacey at lacey dot cc
-Status:   Open
+Status:   Feedback
-Bug Type: Reproducible crash
+Bug Type: IIS related
 Operating System: Windows XP
 PHP Version:  5.0.3
 New Comment:

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




Previous Comments:


[2005-03-28 20:17:13] lacey at lacey dot cc

BTW:  I've seen this Bug Reort:

http://bugs.php.net/bug.php?id=23331

But it's 2 years old and it's marked as Bogus.



[2005-03-28 17:29:32] lacey at lacey dot cc

Description:

Memory Leak using the php5isapi.dll under IIS.  When TSRMLS_FETCH() is
called from HTTPExtensionProc, ts_free_thread leaves a Memory Leak of
approximately 100K for every call.  When TSRMLS_FETCH() isn't called,
there's no leak.  This leak will crash a Server under light loads
within a few hours.






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


#32463 [Asn->Bgs]: mhash implementation of Tiger incorrect?

2005-03-28 Thread sniper
 ID:   32463
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Keamos at gmail dot com
-Status:   Assigned
+Status:   Bogus
 Bug Type: mhash related
 Operating System: Windows XP SP2
 PHP Version:  4.3.10
 Assigned To:  sas
 New Comment:

..


Previous Comments:


[2005-03-28 23:32:26] [EMAIL PROTECTED]

This isn't really a bug, it's more of a different  
implementation/interpretation of the Tiger algorithm. The  
test vectors provided on the Tiger homepage provide the  
output hash in little endian, while the testtiger  
reference implementation at the site outputs the hash in  
big endian. Both outputs are correct, I guess, it's just  
the ordering of the bytes that changes.   
  
I'll leave the bug status as is so Sascha can see it and 
give a more definitive anwser than I can, but I don't 
think it's a bug per se. 



[2005-03-26 18:03:43] [EMAIL PROTECTED]

Assigning to Sascha, the maintainer of this extension.



[2005-03-26 14:51:39] Keamos at gmail dot com

Description:

Mhash fails the Tiger test vectors found at
http://www.cs.technion.ac.il/~biham/Reports/Tiger/test-vectors-nessie-format.dat



Reproduce code:
---
Since the reproduce code is more than twenty lines, find it at
http://pastebin.ca/8273






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


#32473 [Opn->Fbk]: base64_encode cuts text - input to 2933 Characters

2005-03-28 Thread sniper
 ID:   32473
 Updated by:   [EMAIL PROTECTED]
 Reported By:  f-bischof at versanet dot de
-Status:   Open
+Status:   Feedback
 Bug Type: Apache related
 Operating System: Win XP Sp2
 PHP Version:  4.3.10
 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:


[2005-03-28 16:27:02] f-bischof at versanet dot de

Description:

I use Apache/1.3.31 (Win32) PHP/4.3.10 mod_ssl/2.8.18 OpenSSL/0.9.7d

I host a website: http://pocketwelt.dyndns.org

If someone writes a forum-article that is longer then
2933 Bytes and i try to save the input (base64_encoded)
in my database, and then reload the article, it´s
truncated after 2933 bytes. The rest deleted...

If i write the article without base64_encoding, i get 
so much characters in the databse like i want.

The Bug seems only appear if i use base64_encoding.
(also tested with PHP 5.05 with the same result...)



Reproduce code:
---
$text=base64_encode($text);

Text should be about 4 or 5 KB to see the bug !


Expected result:

Truncated Text afeter 2933 Bytes






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


#32232 [Opn->Bgs]: Bug with CGI HTTP_POST_VARS

2005-03-28 Thread sniper
 ID:   32232
 Updated by:   [EMAIL PROTECTED]
 Reported By:  crandym2003 at yahoo dot com
-Status:   Open
+Status:   Bogus
 Bug Type: CGI related
 Operating System: Windows/Unix
 PHP Version:  4.3.10
 New Comment:

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

Thank you for your interest in PHP.

..



Previous Comments:


[2005-03-28 17:43:22] crandym2003 at yahoo dot com

[EMAIL PROTECTED]:

Sorry, I've been unable to check my email for the past couple of
weeks.

Below is the complete script:

The first script is a php file used to capture user input. The second
script is a php file that is called by the POST to store data to mysql
and upload the file (using $_FILES).

If you enter text data into the TEXTAREA of the first script that
contains a trademark special character, the first hidden field is lost
through the POST (i.e., the variable is undefined going into the next
script).  To work around this problem, I've defined the hidden fields
at the end of the script just before .  I normally define hidden
fields after the  statement.  

Somehow, when using the special trademark character ™ in the body
of text in the TEXTAREA input box, causes the $_POST to ignore the
first hidden field.  When this happens, the second script fails because
it is looking for parameters set in the hidden field.

I have found this same problem before when other special characters are
entered.  At first, I couldn't figure out why a hidden field wasn't
being recognized on the following designated post page.

The problem exists on the lastest 4.3.10 and at least as far back as
4.3.4. 

I am running Internet Explorer 6.0.2900.2180 on Windows XP Professional
(Service Pack 2) with IIS.  But I've tested and found the same problem
when running under UNIX/Apache and Internet Explorer 6.0.2.2900.2180.

Hope this helps you reproduce the problem.  It has been a problem for
quite some time, but is only a problem when special characters are
entered.

Randy

+-+
 '') { 
$m = get_record_array('series', 'series_id',
$HTTP_GET_VARS['series_id']);
// clean up data
foreach($m as $key => $val) {
$m[$key] = trim(clean_entities($val));
};  
$series_id = $m['series_id'];
$series_name = $m['series_name'];
$series_briefdesc = $m['series_briefdesc'];
$series_desc = $m['series_desc'];
$series_key = $m['series_key'];
$series_photo = '../photos/series/'.$m['series_photo'];
$series_label = 'Series '.$series_name;
} else {
$series_id = '';
$series_name = '';
$series_key = '';
$series_desc = '';
$series_photo = '';
$series_label = 'New Series';
};


include('./ssi_header.php');

?>


function CheckForm(EditSeries){
if(EditSeries.series_name.value == ""){
alert("EditSeries name is a required field.");
EditSeries.series_name.focus();
return false;
}

return true
}



';
// hidden field variables defined below to workaround php bug

include('./ssi_navbar.php');

print '';
print '';
print '';
print '';
print '';
print ' '.$series_label.'';
print '';
print '';
print '';
print '';

print '';
  print '';
print '';

print '';

  print '';
print '';
print 'Name: ';
print '';
print '';

print '';
print 'Initials: ';
print '';
print '';

print '';
print 'Brief Desc: ';
print '';
print '';

print '';
print 'Full
Desc: ';
print ''.$series_desc.'';
print '';

print '';
print 'Photo: '; 
 print '';
print '';


if (is_file($series_photo)) {
$array = get_display_size($series_photo);
$width = $array[0];
$height = $array[1];

print '';
print 'Delete? ';
print ' ';
print '';
};

print ''; 
print '';
print '';
print '';

print ''; 
print '';
print '  Cancel';
print '';

print '';
print '';
print '';
print '';

// hidden items located here to overcome php bug when special
characters are entered on form
// series below is dummy value because of bug
print '';
print '';
print '';
print '';

print '';

include('./ssi_footer.php'); 

?>

+--

#32426 [Fbk->Opn]: XML catalogs are not used on Windows

2005-03-28 Thread jirka at kosek dot cz
 ID:   32426
 User updated by:  jirka at kosek dot cz
 Reported By:  jirka at kosek dot cz
-Status:   Feedback
+Status:   Open
 Bug Type: DOM XML related
 Operating System: Windows XP
 PHP Version:  5CVS-2005-03-23 (dev)
 New Comment:

I'm sorry. Correct URL is:

http://kosek.cz/temp/libxmlbug.zip


Previous Comments:


[2005-03-28 12:54:37] [EMAIL PROTECTED]

file not found on your server



[2005-03-24 09:03:22] jirka at kosek dot cz

Demo script, together with sample XML catalog and test file is located
at:

http://kosek.cz/libxmlbug.zip



[2005-03-23 23:44:27] [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 possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.





[2005-03-23 12:21:52] jirka at kosek dot cz

Description:

When XML document references external entity (such as a DTD) libxml2
can use XML catalog to redirect loading of the entity from HTTP server
to some local location.

XML catalog file should be taken from /etc/catalog or from files
specified in XML_CATALOG_FILES environment variable. This works in
Windows when libxml2 invoked from command-line (e.g. using xmllint
command). However if I use XML related functions in PHP5 under Windows,
catalog files are not taken into account. I even monitored files
accessed by Apache process and there were no attempt to locate catalog
file.

Any idea?






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


#32475 [Opn]: Memory Leak

2005-03-28 Thread lacey at lacey dot cc
 ID:   32475
 User updated by:  lacey at lacey dot cc
 Reported By:  lacey at lacey dot cc
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows XP
 PHP Version:  5.0.3
 New Comment:

BTW:  I've seen this Bug Reort:

http://bugs.php.net/bug.php?id=23331

But it's 2 years old and it's marked as Bogus.


Previous Comments:


[2005-03-28 17:29:32] lacey at lacey dot cc

Description:

Memory Leak using the php5isapi.dll under IIS.  When TSRMLS_FETCH() is
called from HTTPExtensionProc, ts_free_thread leaves a Memory Leak of
approximately 100K for every call.  When TSRMLS_FETCH() isn't called,
there's no leak.  This leak will crash a Server under light loads
within a few hours.






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


#32459 [Fbk->Opn]: "No input" if running PHP on secondary site

2005-03-28 Thread peter dot ordal at rochester dot edu
 ID:   32459
 User updated by:  peter dot ordal at rochester dot edu
 Reported By:  peter dot ordal at rochester dot edu
-Status:   Feedback
+Status:   Open
 Bug Type: IIS related
 Operating System: Windows Server 2003
 PHP Version:  5.0.3
 New Comment:

I gave CVS a try, but the problem persists.

If I use the "working" document root I get the version string
5.1.0-dev, just for confirmation.


Previous Comments:


[2005-03-25 23:33:42] [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





[2005-03-25 23:11:02] peter dot ordal at rochester dot edu

Description:

I have PHP identically configured for two Web Sites under a single
instance of IIS 6 on Windows Server 2003. In one, which has the
identifier of 1 and runs on port 80, requests to .php files return
normally. In the other, which has the identifier of 136095314 and
listens on port 81, requests to PHP error for both ISAPI and CGI, with
these messages:

When using php5isapi.dll: "No input file specified."
When using php-cgi.exe: CGI Error. The specified CGI application
misbehaved by not returning a complete set of HTTP headers.

The two Web Sites have different document roots. This does seem
important, as setting them to have the same document root fixes the
issue.
Primary: c:\inetpub\wwwroot
Secondary: c:\inetpub\sandbox

I discovered this bug by first attempting to install PHP 5.0.3 on the
secondary site. This bug is not dependent on the value of the doc_root
variable in php.ini. It can be set correctly, set incorrectly, or
unset. Other bugs suggest fixing doc_root to resolve this error, but I
am certain that the value of the doc_root variable does not impact the
error. Eventually I had no options left but to try PHP 5 on the primary
site, which worked.

Web Service Extensions have been set up to permit both php5isapi.dll
and php-cgi.exe, and the wildcard extension has been Allowed (to be
sure this was not a simple security issue).

In both Web Sites, the PHP configuration under Home Directory ->
Configuration -> Mappings is
Extension: .php
Executable: C:\php-5.0.3-Win32\php-cgi.exe %s or
C:\php-5.0.3-Win32\php5isapi.dll
Verbs: All
Script Engine: Checked
Verify File Exists: Checked

Cache ISAPI Extensions is disabled. I frequently restarted the IIS
Admin service is testing this.

For curious users, I was able to run PHP 5 without impacting PHP 4 with
the instructions attached to this bug:
http://bugs.php.net/bug.php?id=28448. This allows you to keep separate
php.ini files.

Reproduce code:
---


Expected result:

Standard PHP info dump.

Actual result:
--
"No input file specified.", or, when using php-cgi.exe: CGI Error. The
specified CGI application misbehaved by not returning a complete set of
HTTP headers.





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


#32139 [Com]: base64binary encode/decode

2005-03-28 Thread forvia at yandex dot ru
 ID:   32139
 Comment by:   forvia at yandex dot ru
 Reported By:  rtroll at yahoo-inc dot com
 Status:   Assigned
 Bug Type: SOAP related
 Operating System: *
 PHP Version:  5CVS-2005-02-28
 Assigned To:  dmitry
 New Comment:

SoapClient do not decode response which in base64Binary format...


Previous Comments:


[2005-02-28 22:04:25] rtroll at yahoo-inc dot com

Changed summary.  For some reason, summary kept the same value as my
previously submitted bug.



[2005-02-28 22:02:00] rtroll at yahoo-inc dot com

Description:

When building a SOAP client or server that uses the "base64Binary" XML
datatype, PHP is not performing the appropriate B64 encoding/decoding.

When generating a SOAP client based on a WSDL, the PHP SOAP extension
builds a collection of methods for me.  These methods take args (as
defined by the WSDL), and send them over the wire to the appropriate
service.  The extension takes care of encoding arrays as arrays,
decimals as decimals, etc.  If the item datatype is "base64Binary", the
extension does not b64 encode the value - it merely places it in the
XML.

This may be a feature, requiring client authors to read through the
WSDL to determine what datatypes are being used, in order to adequately
encode things before passing them into the autogenerated methods.  If
this is the appropriate functionality, the "time_t -> dateTime" mapping
should also be removed, providing a consistent, "PHP does no data
munging" approach to generated interfaces.

However, I'd much rather see the extension do the B64 encoding for me.
:)

Consider a service that returns an image: getImage().  It could be
implemented such that the image is transmitted in b64 - but the client
author shouldn't need to know that.

Reproduce code:
---
http://ws1.api.re2.yahoo.com/ws/soap-demo/full.wsdl";;
$SRCBUF = "1234567890abcdefghijklmnopqrstuvwxyz";

$client = new SoapClient( $WSDL, array( "trace" => true,
"exceptions" => 0,
));
function dump_xml( $title, $body )
{
$nl = preg_replace( "/\>\\n<", $body );
$clean = htmlspecialchars( $nl );
print "\n$title\n$clean\n";
}

$r = $client->echoViaBase64( array( 'src' => $SRCBUF ));
dump_xml( "Request", $client->__getLastRequest() );
dump_xml( "Response", $client->__getLastResponse() );
?>

Expected result:

The request generated by this PHP5 SOAP client contains the following
body:



1234567890abcdefghijklmnopqrstuvwxyz




Actual result:
--
The request should look something like this:



MTIzNDU2Nzg5MGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6







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


#32232 [NoF->Opn]: Bug with CGI HTTP_POST_VARS

2005-03-28 Thread crandym2003 at yahoo dot com
 ID:   32232
 User updated by:  crandym2003 at yahoo dot com
 Reported By:  crandym2003 at yahoo dot com
-Status:   No Feedback
+Status:   Open
 Bug Type: CGI related
 Operating System: Windows/Unix
 PHP Version:  4.3.10
 New Comment:

[EMAIL PROTECTED]:

Sorry, I've been unable to check my email for the past couple of
weeks.

Below is the complete script:

The first script is a php file used to capture user input. The second
script is a php file that is called by the POST to store data to mysql
and upload the file (using $_FILES).

If you enter text data into the TEXTAREA of the first script that
contains a trademark special character, the first hidden field is lost
through the POST (i.e., the variable is undefined going into the next
script).  To work around this problem, I've defined the hidden fields
at the end of the script just before .  I normally define hidden
fields after the  statement.  

Somehow, when using the special trademark character ™ in the body
of text in the TEXTAREA input box, causes the $_POST to ignore the
first hidden field.  When this happens, the second script fails because
it is looking for parameters set in the hidden field.

I have found this same problem before when other special characters are
entered.  At first, I couldn't figure out why a hidden field wasn't
being recognized on the following designated post page.

The problem exists on the lastest 4.3.10 and at least as far back as
4.3.4. 

I am running Internet Explorer 6.0.2900.2180 on Windows XP Professional
(Service Pack 2) with IIS.  But I've tested and found the same problem
when running under UNIX/Apache and Internet Explorer 6.0.2.2900.2180.

Hope this helps you reproduce the problem.  It has been a problem for
quite some time, but is only a problem when special characters are
entered.

Randy

+-+
 '') { 
$m = get_record_array('series', 'series_id',
$HTTP_GET_VARS['series_id']);
// clean up data
foreach($m as $key => $val) {
$m[$key] = trim(clean_entities($val));
};  
$series_id = $m['series_id'];
$series_name = $m['series_name'];
$series_briefdesc = $m['series_briefdesc'];
$series_desc = $m['series_desc'];
$series_key = $m['series_key'];
$series_photo = '../photos/series/'.$m['series_photo'];
$series_label = 'Series '.$series_name;
} else {
$series_id = '';
$series_name = '';
$series_key = '';
$series_desc = '';
$series_photo = '';
$series_label = 'New Series';
};


include('./ssi_header.php');

?>


function CheckForm(EditSeries){
if(EditSeries.series_name.value == ""){
alert("EditSeries name is a required field.");
EditSeries.series_name.focus();
return false;
}

return true
}



';
// hidden field variables defined below to workaround php bug

include('./ssi_navbar.php');

print '';
print '';
print '';
print '';
print '';
print ' '.$series_label.'';
print '';
print '';
print '';
print '';

print '';
  print '';
print '';

print '';

  print '';
print '';
print 'Name: ';
print '';
print '';

print '';
print 'Initials: ';
print '';
print '';

print '';
print 'Brief Desc: ';
print '';
print '';

print '';
print 'Full
Desc: ';
print ''.$series_desc.'';
print '';

print '';
print 'Photo: '; 
 print '';
print '';


if (is_file($series_photo)) {
$array = get_display_size($series_photo);
$width = $array[0];
$height = $array[1];

print '';
print 'Delete? ';
print ' ';
print '';
};

print ''; 
print '';
print '';
print '';

print ''; 
print '';
print '  Cancel';
print '';

print '';
print '';
print '';
print '';

// hidden items located here to overcome php bug when special
characters are entered on form
// series below is dummy value because of bug
print '';
print '';
print '';
print '';

print '';

include('./ssi_footer.php'); 

?>

++

Next is the complete script which stores data to mysql and uploads the
file

++

 $val) {
if($val!="") { // dont process null fields
$HTTP_POST_VARS[$key] = addslashes($val);
};
};
};

// set local hidden variables passed from previous page
$series_id = $HTTP_POST_VARS['series_id'];
$series_key = $HTTP_POST_VARS['series_key'];
$series_name = $HTTP_POST_VARS['series_name'];
$series_briefdesc = $HTTP_POST_VARS['series_briefdesc'];
$series_desc = $HTTP_POST_VARS

#32475 [NEW]: Memory Leak

2005-03-28 Thread lacey at lacey dot cc
From: lacey at lacey dot cc
Operating system: Windows XP
PHP version:  5.0.3
PHP Bug Type: Reproducible crash
Bug description:  Memory Leak

Description:

Memory Leak using the php5isapi.dll under IIS.  When TSRMLS_FETCH() is
called from HTTPExtensionProc, ts_free_thread leaves a Memory Leak of
approximately 100K for every call.  When TSRMLS_FETCH() isn't called,
there's no leak.  This leak will crash a Server under light loads within a
few hours.


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


#32473 [NEW]: base64_encode cuts text - input to 2933 Characters

2005-03-28 Thread f-bischof at versanet dot de
From: f-bischof at versanet dot de
Operating system: Win XP Sp2
PHP version:  4.3.10
PHP Bug Type: Apache related
Bug description:  base64_encode cuts text - input to 2933 Characters

Description:

I use Apache/1.3.31 (Win32) PHP/4.3.10 mod_ssl/2.8.18 OpenSSL/0.9.7d

I host a website: http://pocketwelt.dyndns.org

If someone writes a forum-article that is longer then
2933 Bytes and i try to save the input (base64_encoded)
in my database, and then reload the article, it´s
truncated after 2933 bytes. The rest deleted...

If i write the article without base64_encoding, i get 
so much characters in the databse like i want.

The Bug seems only appear if i use base64_encoding.
(also tested with PHP 5.05 with the same result...)



Reproduce code:
---
$text=base64_encode($text);

Text should be about 4 or 5 KB to see the bug !


Expected result:

Truncated Text afeter 2933 Bytes


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


#32472 [Opn->Fbk]: DOMDocument::createElement changes property value

2005-03-28 Thread rrichards
 ID:   32472
 Updated by:   [EMAIL PROTECTED]
 Reported By:  c dot d at earthlink dot net
-Status:   Open
+Status:   Feedback
 Bug Type: DOM XML related
 Operating System: Mac OS X 10.3.8
 PHP Version:  5.0.3
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2005-03-28 13:12:16] c dot d at earthlink dot net

Description:

I'm using libxml2 2.6.17.

In the following code, the call to createElement() changes the value of
the private property $rootTag to null.

Reproduce code:
---
preserveWhiteSpace = FALSE;
$this->formatOutput = FALSE;

if ($rootTag) {
$this->rootTag = $rootTag;
}
else {
$this->rootTag = 'table';
}

if ($rowTag) {
$this->rowTag = $rowTag;
}
else {
$this->rowTag = 'row';
}

$this->appendChild($this->createElement($this->rootTag));

}

}

$modulesDOM = new bdmDOMTable('modules', 'module');

var_dump($modulesDOM);
?>

Expected result:

object(bdmDOMTable)#1 (2) { ["rootTag:private"]=>  string(7) "modules"
["rowTag:private"]=>  string(6) "module" }

Actual result:
--
object(bdmDOMTable)#1 (2) { ["rootTag:private"]=>  NULL
["rowTag:private"]=>  string(6) "module" }







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


#32472 [NEW]: DOMDocument::createElement changes property value

2005-03-28 Thread c dot d at earthlink dot net
From: c dot d at earthlink dot net
Operating system: Mac OS X 10.3.8
PHP version:  5.0.3
PHP Bug Type: DOM XML related
Bug description:  DOMDocument::createElement changes property value

Description:

I'm using libxml2 2.6.17.

In the following code, the call to createElement() changes the value of
the private property $rootTag to null.

Reproduce code:
---
preserveWhiteSpace = FALSE;
$this->formatOutput = FALSE;

if ($rootTag) {
$this->rootTag = $rootTag;
}
else {
$this->rootTag = 'table';
}

if ($rowTag) {
$this->rowTag = $rowTag;
}
else {
$this->rowTag = 'row';
}

$this->appendChild($this->createElement($this->rootTag));

}

}

$modulesDOM = new bdmDOMTable('modules', 'module');

var_dump($modulesDOM);
?>

Expected result:

object(bdmDOMTable)#1 (2) { ["rootTag:private"]=>  string(7) "modules"
["rowTag:private"]=>  string(6) "module" }

Actual result:
--
object(bdmDOMTable)#1 (2) { ["rootTag:private"]=>  NULL
["rowTag:private"]=>  string(6) "module" }



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


#32426 [Opn->Fbk]: XML catalogs are not used on Windows

2005-03-28 Thread rrichards
 ID:   32426
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jirka at kosek dot cz
-Status:   Open
+Status:   Feedback
 Bug Type: DOM XML related
 Operating System: Windows XP
 PHP Version:  5CVS-2005-03-23 (dev)
 New Comment:

file not found on your server


Previous Comments:


[2005-03-24 09:03:22] jirka at kosek dot cz

Demo script, together with sample XML catalog and test file is located
at:

http://kosek.cz/libxmlbug.zip



[2005-03-23 23:44:27] [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 possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.





[2005-03-23 12:21:52] jirka at kosek dot cz

Description:

When XML document references external entity (such as a DTD) libxml2
can use XML catalog to redirect loading of the entity from HTTP server
to some local location.

XML catalog file should be taken from /etc/catalog or from files
specified in XML_CATALOG_FILES environment variable. This works in
Windows when libxml2 invoked from command-line (e.g. using xmllint
command). However if I use XML related functions in PHP5 under Windows,
catalog files are not taken into account. I even monitored files
accessed by Apache process and there were no attempt to locate catalog
file.

Any idea?






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


#32471 [Opn->Bgs]: Darstellungsproblem

2005-03-28 Thread tony2001
 ID:   32471
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dsiekiera at academy24 dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: Linux 9.0 - AOLserver 4.0.8
 PHP Version:  5.0.3
 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.

Write in English, please.


Previous Comments:


[2005-03-28 10:55:21] dsiekiera at academy24 dot com

Description:

Ich habe alles sauber installiert und php läuft auch auf unserem
System. Aber der Inhalt einer *.php-Datei wird erst nach einer
Aktuallisierung angezeigt und dann auch noch doppelt. Benutze ich
dagegen den Opera Browser, wird alles normal dargestellt. Woran kann es
liegen, das mit Firefox oder dem I-Explorer der Inhalt nicht normal
dargestellt werden kann?






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


#32471 [NEW]: Darstellungsproblem

2005-03-28 Thread dsiekiera at academy24 dot com
From: dsiekiera at academy24 dot com
Operating system: Linux 9.0 - AOLserver 4.0.8
PHP version:  5.0.3
PHP Bug Type: Unknown/Other Function
Bug description:  Darstellungsproblem

Description:

Ich habe alles sauber installiert und php läuft auch auf unserem System.
Aber der Inhalt einer *.php-Datei wird erst nach einer Aktuallisierung
angezeigt und dann auch noch doppelt. Benutze ich dagegen den Opera
Browser, wird alles normal dargestellt. Woran kann es liegen, das mit
Firefox oder dem I-Explorer der Inhalt nicht normal dargestellt werden
kann?


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


#32470 [Opn->Fbk]: preg_compile() Need way to pre-compile regex

2005-03-28 Thread tony2001
 ID:   32470
 Updated by:   [EMAIL PROTECTED]
 Reported By:  sam_bravard at yahoo dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Feature/Change Request
 Operating System: all
 PHP Version:  5.0.3
 New Comment:

All pcre_* funcs do not compile expressions each time, they use cache
of precompiled regexps.
See pcre_get_compiled_regex_ex() in ext/pcre/php_pcre.c
Or you're proposing something different?


Previous Comments:


[2005-03-28 10:04:13] sam_bravard at yahoo dot com

Description:

PHP is missing the ability to pre-compile regex expressions and then
use the pre-compiled regex.

This is a _major_ performance issue (100x) when processing files or
text streams with regex's.  In PHP you have to recompile the regex for
each line you process... a major waste of cpu time.

See Perl, .NET or Java's regex support for an example of how to use
precompiled regex's.

Perhaps PHP can add something like the following and just overload the
first argument to preg_match and friends:

$precompiled_expression = preg_compile("regex expression");
preg_match($precompiled_expression, $sourcedata, $matches);



Reproduce code:
---
$precompiled_expression = preg_compile("regex expression");
preg_match($precompiled_expression, $sourcedata, $matches);

Actual result:
--
Function doesn't exist... sorely needed for performance.





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


#32470 [NEW]: preg_compile() Need way to pre-compile regex

2005-03-28 Thread sam_bravard at yahoo dot com
From: sam_bravard at yahoo dot com
Operating system: all
PHP version:  5.0.3
PHP Bug Type: Feature/Change Request
Bug description:  preg_compile() Need way to pre-compile regex

Description:

PHP is missing the ability to pre-compile regex expressions and then use
the pre-compiled regex.

This is a _major_ performance issue (100x) when processing files or text
streams with regex's.  In PHP you have to recompile the regex for each
line you process... a major waste of cpu time.

See Perl, .NET or Java's regex support for an example of how to use
precompiled regex's.

Perhaps PHP can add something like the following and just overload the
first argument to preg_match and friends:

$precompiled_expression = preg_compile("regex expression");
preg_match($precompiled_expression, $sourcedata, $matches);



Reproduce code:
---
$precompiled_expression = preg_compile("regex expression");
preg_match($precompiled_expression, $sourcedata, $matches);

Actual result:
--
Function doesn't exist... sorely needed for performance.

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