#29780 [Opn-Fbk]: Constructor isn't called if a class is extended from a built in class

2004-08-29 Thread tony2001 
 ID:   29780
 Updated by:   [EMAIL PROTECTED]
 Reported By:  d dot khan at ventigo dot com
-Status:   Open
+Status:   Feedback
-Bug Type: Zend Engine 2 problem
+Bug Type: Unknown/Other Function
 Operating System: *
 PHP Version:  5.*
 New Comment:

Works fine for me with latest PHP and PDO.
Btw, this is not ZE problem, reclassifying.


Previous Comments:


[2004-08-26 20:32:26] [EMAIL PROTECTED]

HINT to all extension developers:

Constructors of internal classes need to have the name '__construct'
rather that the class's name.



[2004-08-25 22:46:08] d dot khan at ventigo dot com

You example works - mine doesn't. It seems to be an oddity with
extensions...

Example code:
?php
class test extends stdClass {

function __construct() {
echo 'Called in child';
}

}
$test = new test;


Class rltxPDO extends PDO {

function __construct() {
echo 'Called in child 2';
}
}

$test2 = new rltxPDO;
?

Output:
Called in child
Warning: PDO::__construct() expects at least 1 parameter, 0 given in
/home/shares/development/khan/wandern/html/test.php on line 19



[2004-08-23 18:20:12] [EMAIL PROTECTED]

This code:
?
class test extends stdClass {

function __construct() {
echo 'Called in child';
}

}

$test = new test;
?
works fine and outputs 'Called in child' for me.
Please, check it one more time and/or try newer snapshot.



[2004-08-21 11:58:01] d dot khan at ventigo dot com

Description:

Hello,

maybe this is bogus but I found a situation where the OOP engine
doesn't behave as - at least I - would expect.

I tried to extend the PDO extension and my local construct method isn't
called.
The engine always calls the parent construct method.

Greetings

Daniel Khan

Reproduce code:
---
Class rltxPDO extends PDO {

function __construct() {
echo 'Called in child';
}

public static function instance() {
static $instance;
if (!$instance) {
$instance = new rltxPDO();
}
return $instance;
}
}

Expected result:

Output: Called in child

Actual result:
--
Warning: PDO::__construct() expects at least 1 parameter, 0 given





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

#29880 [NEW]: trans-sid randomly not added to forms

2004-08-29 Thread r dot wilczek at web-appz dot de 
From: r dot wilczek at web-appz dot de
Operating system: Windows XP Prof.
PHP version:  5.0.0
PHP Bug Type: Session related
Bug description:  trans-sid randomly not added to forms

Description:

Sometimes I encounter the strange behaviour that PHP does not add an 
input type=hidden name=PHPSESSID value=6745etcetc /
in forms having additional whitespaces in the form-tag.

I like to have forms readable and often write them like shown in
tmplt_button_form.php below.

Sometimes it works; sometimes I have to strip all additional whitespaces
from the opening form-tag to make PHP rewriting the HTML-output. 
Switching output-buffering on and off did not change the effect. Had the
same phenomenon in PHP 4 before.

So my workaround for now is not to write
form method=post 
  action=[-- URL --]

but 
form method=post action=[-- URL --]

- Roland

Reproduce code:
---
// The method ...
function HTMLButton($url, $action, $comment)
{
$file  = 'templates/tmplt_button_form.php';
$tmplt = implode('', file($file));
$replace = array(
   '[-- URL --]' = htmlentities($url),
   '[-- ACTION --]'  = htmlentities($action),
   '[-- COMMENT --]' = htmlentities($comment)
);
echo strtr($tmplt, $replace);
}

-- The file tmplt_button_form.php: --

form method=post 
  action=[-- URL --]
 input type=hidden 
name=myaction 
value=[-- ACTION --]
 input type=submit 
value=[-- COMMENT --]
/form

Expected result:

form method=post 
  action=http://www.default.com;input type=hidden
name=PHPSESSID value=6745135150906f4748b27d0cbe43d99a /
 input type=hidden 
name=myaction 
value=someAction
 input type=submit 
value=Just do it!
/form

Actual result:
--
form method=post 
  action=http://www.default.com;
 input type=hidden 
name=myaction 
value=someAction
 input type=submit 
value=Just do it!
/form

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

#29878 [Opn-Bgs]: ImageCreateFromJpeg returns 'not a valid jpeg file'

2004-08-29 Thread pajoye 
 ID:   29878
 Updated by:   [EMAIL PROTECTED]
 Reported By:  cyleriggs at kc dot rr dot com
-Status:   Open
+Status:   Bogus
 Bug Type: GD related
 Operating System: Linux 2.6.8.1
 PHP Version:  5.0.1
-Assigned To:  
+Assigned To:  pajoye
 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. 

Thank you for your interest in PHP.

Your jpeg file is not valid. PHP could not take care of each possible
failures in image files. Desktop softwares could. Fix your image and
replace it.

--Pierre



Previous Comments:


[2004-08-28 23:00:25] cyleriggs at kc dot rr dot com

Description:

When calling ImageCreateFromJPEG() on a valid jpeg file it fails and i
get errors such as the following in my php error log:

code
[28-Aug-2004 05:21:29] PHP Warning:  imagecreatefromjpeg() [a
href='function.imagecreatefromjpeg'function.imagecreatefromjpeg/a]:
'/usr/local/apache2/htdocs/pictures/Before Dad Went to
Iraq/IMGP0008.JPG' is not a valid JPEG file in
/home/www/pictures/index.php on line 43
/code

however as can be seen through this link the file is a valid jpeg
file:

http://cyle.dyndns.org/pictures/Before Dad Went to Iraq/IMGP0008.JPG

Also i have a memory_limit of 25mb so this cannot be the issue.

Something that might help:
http://cyle.dyndns.org/phpinfo.php

I am writing this code for a picture gallery browser, while most
pictures load, about 10% of my pictures cannot be opened through
ImageCreateFromJpeg(), however it is always the same pictures that
cannot be opened. The only trend i can see is that this does not appear
to be happening on small jpegs.

The page that I am having problems with is
http://cyle.dyndns.org/pictures/index.php.  The source code for this is
at http://cyle.dyndns.org/pictures/index.phps.

Expected result:

The image would be loaded and code continue to execute and i get the
error message described above.

Actual result:
--
Sometimes images load sometimes images cannot be opened.





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

#28487 [Opn-Fbk]: crash when function declared in switch is called

2004-08-29 Thread tony2001 
 ID:   28487
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tomas dot matousek at matfyz dot cz
-Status:   Open
+Status:   Feedback
 Bug Type: Scripting Engine problem
 Operating System: WinXP
 PHP Version:  5.0.0RC2
 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

Seems to be fixed. Please, test it again.


Previous Comments:


[2004-07-29 09:59:44] stefan at hotpaenz dot de

I experienced this crash on Linux 2.6.3 with PHP 4.3.3 and 
PHP 5.1.0-dev snapshot 200407271430. Perhaps somebody 
should set the category to reproducible crash. 
 
This is the PHP 5.1.0-dev backtrace: 
 
#0  0x08271843 in zend_switch_free_handler  
(execute_data=0xbfffd5a0, opline=0x8726fe4,  
op_array=0x8721970, tsrm_ls=0x8430018)  
at /root/php/200407271430/php5-5.0.0/Zend/zend_execute.c:200  
  
200 if (!T(opline-op1.u.var).var.ptr_ptr) {  
  
(gdb) bt  
  
#0  0x08271843 in zend_switch_free_handler  
(execute_data=0xbfffd5a0, opline=0x8726fe4,  
op_array=0x8721970, tsrm_ls=0x8430018)  
at /root/php/200407271430/php5-5.0.0/Zend/zend_execute.c:200  
  
#1  0x0826c0b5 in execute (op_array=0x8721970,  
tsrm_ls=0x8430018)  
at /root/php/200407271430/php5-5.0.0/Zend/zend_execute.c:1391  
  
#2  0x0826fe63 in zend_do_fcall_common_helper  
(execute_data=0xbfffd670, opline=0x8725ecc,  
op_array=0x8721b94, tsrm_ls=0x8430018)  
at /root/php/200407271430/php5-5.0.0/Zend/zend_execute.c:2728  
  
#3  0x0826c0b5 in execute (op_array=0x8721b94,  
tsrm_ls=0x8430018)  
at /root/php/200407271430/php5-5.0.0/Zend/zend_execute.c:1391  
  
#4  0x0824ce31 in zend_execute_scripts (type=8,  
tsrm_ls=0x8430018, retval=0x0, file_count=3)  
at /root/php/200407271430/php5-5.0.0/Zend/zend.c:1068  
  
#5  0x08210044 in php_execute_script  
(primary_file=0xba40, tsrm_ls=0x8430018)  
at /root/php/200407271430/php5-5.0.0/main/main.c:1631  
  
#6  0x08278bfc in main (argc=2, argv=0xbb04)  
at /root/php/200407271430/php5-5.0.0/sapi/cgi/cgi_main.c:1568



[2004-07-24 21:22:29] Jared dot Williams1 at ntworld dot com

Just discovered this one with

PHP Version 5.1.0-dev 
System  Windows NT WIN2KS 5.0 build 2195  
Build Date  Jul 23 2004 16:22:08  

and

PHP Version 5.1.0-dev 
System  Windows NT WIN2KS 5.0 build 2195  
Build Date  Jul 24 2004 20:15:28



[2004-07-20 16:35:29] jb-php at microbasic dot net

I have the same problem, example :
?
$somecode=1;
switch($somecode){
case 1:
function test(){
echo success;
}
test();
break;
}
?
With php5 final, this code was working with php 4.3.7



[2004-07-13 18:07:43] fixxxer at php5 dot ru

The bug exists in the last snapshot php5-200407131230.
Tested under FreeBSD 4.9 and Windows XP.

(gdb) bt
#0  zend_switch_free_handler (execute_data=0xbfbfe314,
opline=0x84f8824, op_array=0x8504780)
at /usr/ports/lang/php5/work/php-5.0.0RC3/Zend/zend_execute.c:65
#1  0x823fbcf in execute (op_array=0x8504780) at
/usr/ports/lang/php5/work/php-5.0.0RC3/Zend/zend_execute.c:1391
#2  0x825d8c5 in zend_do_fcall_common_helper (execute_data=0xbfbfe404,
opline=0x850e368, op_array=0x8505124)
at /usr/ports/lang/php5/work/php-5.0.0RC3/Zend/zend_execute.c:2728
#3  0x825dd22 in zend_do_fcall_by_name_handler
(execute_data=0xbfbfe404, opline=0x850e368, op_array=0x8505124)
at /usr/ports/lang/php5/work/php-5.0.0RC3/Zend/zend_execute.c:2810
#4  0x823fbcf in execute (op_array=0x8505124) at
/usr/ports/lang/php5/work/php-5.0.0RC3/Zend/zend_execute.c:1391
#5  0x821e32e in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/ports/lang/php5/work/php-5.0.0RC3/Zend/zend.c:1061
#6  0x81e3ba5 in php_execute_script (primary_file=0xbfbffac0) at
/usr/ports/lang/php5/work/php-5.0.0RC3/main/main.c:1627
#7  0x82688ce in main (argc=3, argv=0xbfbffb3c) at
/usr/ports/lang/php5/work/php-5.0.0RC3/sapi/cli/php_cli.c:943



[2004-05-22 12:54:44] tomas dot matousek at matfyz dot cz

Description:

PHP crashes when an arbitrary function declared in a switch statement
is called.

Reproduce code:
---
?
$x = 1;

switch($x)
{
  case 1:
function f() { }
  
break;  
}

f();
?

Expected result:

no crash

Actual result:
--
crash





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

#29735 [Opn-Fbk]: Segfault (11) / Possible stack corruption

2004-08-29 Thread tony2001 
 ID:   29735
 Updated by:   [EMAIL PROTECTED]
 Reported By:  sparkeh at btinternet dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Linux 2.6.7-gentoo-r9
 PHP Version:  5.0.1
 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

Seems to be fixed. Please, test it again.


Previous Comments:


[2004-08-21 03:56:14] sparkeh at btinternet dot com

I've noticed that this is a duplicate of bug #28487



[2004-08-19 20:50:11] sparkeh at btinternet dot com

gdb stack trace from the first script (Ref: 3:24pm CEST)

#0  0x081e74a2 in _zval_ptr_dtor ()
#1  0x08216d9f in zend_switch_free_handler ()
#2  0x08211dff in execute ()
#3  0x0821567d in zend_do_fcall_common_helper ()
#4  0x08215993 in zend_do_fcall_by_name_handler ()
#5  0x08211dff in execute ()
#6  0x081f2b17 in zend_execute_scripts ()
#7  0x081b4d31 in php_execute_script ()
#8  0x in ?? ()
#9  0x0003 in ?? ()
#10 0x in ?? ()
...
#970 0x5f706870 in ?? ()
#971 0x69727473 in ?? ()
#972 0x68775f70 in ?? ()
#973 0x4083a6c4 in mallopt () from /lib/libc.so.6
Previous frame inner to this frame (corrupt stack?)
(gdb)

:o)



[2004-08-19 18:27:58] hip at cs dot okstate dot edu

I getting a seg. fault on a simple little script that's worked for
years and it sure smells like stack corruption.

?
require_once(config.inc);
require_once(Database.inc);

$db = new Database(USER_ID, USER_PASSWORD);
$db-connect();

$sql  = select from STUDENT_STATUS ;
$sql .= where STATUS='APPROVED' ;
?

On my solaris 9 x86 box this seq. faults. Change the last line it seq
faults. Remove the last line it doesn't. After a
hour of playing, I've discovered that I can prevent a seg. fault by
place echo statements (or some other random statment) in key positions
in the file.  That sure smells
like stack corruption.

I ran gdb on the core dump and the last lines of the backtrace are:

#20 0x81b65da in zend_deactivate () at
/usr/local/src/php-5.0.1/Zend/zend.c:819
#21 0x8182007 in php_request_shutdown (dummy=0x0)
at /usr/local/src/php-5.0.1/main/main.c:1212
#22 0x81db50f in main (argc=2, argv=0x8047a18)
at /usr/local/src/php-5.0.1/sapi/cli/php_cli.c:1046

and from what little I know of gdb it looks like it's happening when
php is trying to shutdown.



[2004-08-18 20:36:46] sparkeh at btinternet dot com

N.B. Original code tested and works as expected with PHP 4.3.3



[2004-08-18 19:44:13] sparkeh at btinternet dot com

There is no loop here. This is segfaulting because the function is
failing to return correctly (stack corruption). Remove the global
statement, and add an echo '' outside of the switch() braces to see
normal (expected) program flow.



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

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

#29882 [NEW]: isset crashes on arrays

2004-08-29 Thread tomas_matousek at hotmail dot com 
From: tomas_matousek at hotmail dot com
Operating system: WinXP
PHP version:  5.0.1
PHP Bug Type: Reproducible crash
Bug description:  isset crashes on arrays

Description:

isset applied to operator [] with empty array key crashes

Reproduce code:
---
 $x = array();
 var_dump(isset($x[]));

Expected result:

bool(false)

Actual result:
--
Crash

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

#29883 [NEW]: isset gives invalid values on strings

2004-08-29 Thread tomas_matousek at hotmail dot com 
From: tomas_matousek at hotmail dot com
Operating system: WinXP
PHP version:  5.0.1
PHP Bug Type: Scripting Engine problem
Bug description:  isset gives invalid values on strings

Description:

isset applied on a string with negative index returns true.
It should return false.

Reproduce code:
---
$x = bug;
var_dump(isset($x[-1]));

Expected result:

bool(false)

Actual result:
--
bool(true)

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

#29626 [Opn-Fbk]: Variables read from $_SESSION loose their values when using HTTP

2004-08-29 Thread tony2001 
 ID:   29626
 Updated by:   [EMAIL PROTECTED]
 Reported By:  proteus at proteusworld dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Session related
 Operating System: Linux (might be Windows too)
 PHP Version:  Irrelevant
 New Comment:

HTTP  HTTPS are two different sites for your browser, so you're mixing
two different sessions here.
Please, supply more readable example - a short reproduce script would
definitely help more than a verbose essay.


Previous Comments:


[2004-08-12 08:26:48] proteus at proteusworld dot com

Description:

I found a strange (to me at least) behaviour with sessions when using
HTTPS.

Let's say that $_SESSION[message] contains old_message. Take the
following code:

$old_message = $_SESSION[message];
$_SESSION[message] = new message;
echo The message was: .$old_message;

Now, over HTTP you would get the expected output (old_message). But
over HTTPS the output will contain new_message.

You can use session_unregister(message) if you want $old_message to
preserve its value, but this means you can't set anymore a new value
for $_SESSION[message].







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

#29616 [Opn-Fbk]: Error in checking APXS versionn

2004-08-29 Thread tony2001 
 ID:   29616
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jpbarrette at savoirfairelinux dot net
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: Mandrake linux 10.0 (Community)
 PHP Version:  5.0.0
 New Comment:

What shell do you use and what exactly did you remove from ./configure
to make it work? Could plz show what's on line 3169?


Previous Comments:


[2004-08-11 16:46:14] jpbarrette at savoirfairelinux dot net

Description:

When I run the configure script with these options: 
 
'./configure' '--prefix=/usr' '--exec-prefix=/usr' 
'--bindir=/usr/bin' '--sbindir=/usr/sbin' 
'--sysconfdir=/etc' '--datadir=/usr/share' 
'--includedir=/usr/include' '--libdir=/usr/lib' 
'--libexecdir=/usr/lib' '--localstatedir=/var/lib' 
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info' '--enable-discard-path' 
'--disable-force-cgi-redirect' '--enable-shared' 
'--disable-static' '--disable-debug' '--disable-rpath' 
'--enable-pic' '--enable-inline-optimization' 
'--enable-memory-limit' '--with-config-file-path=/etc' 
'--with-config-file-scan-dir=/etc/php' 
'--with-pear=/usr/share/pear' '--enable-magic-quotes' 
'--enable-debugger' '--enable-track-vars' 
'--with-exec-dir=/usr/bin' '--with-versioning' 
'--with-mod_charset' '--with-regex=php' 
'--enable-track-vars' '--enable-trans-sid' 
'--enable-safe-mode' '--enable-ctype' '--enable-ftp' 
'--with-gettext=/usr' '--enable-posix' '--enable-session' 
'--enable-sysvsem' '--enable-sysvshm' '--enable-yp' 
'--with-openssl=/usr' '--without-kerberos' '--with-ttf' 
'--with-freetype-dir=/usr' '--with-zlib=/usr' 
'--with-zlib=/usr' '--with-zlib-dir=/usr' '--without-pear' 
'--with-apxs=/usr/sbin/apxs'  
 
I got this error: 
 
checking for Apache 1.x module support via DSO through 
APXS... expr: non-numeric argument 
./configure: line 3169: test: : integer expression 
expected 
 
The only way I could resolve this is remove the version 
test on the lines next to line 3169 and this line too. 
 
It work fine after that. 






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

#29882 [Opn]: isset crashes on arrays

2004-08-29 Thread helly 
 ID:   29882
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tomas_matousek at hotmail dot com
 Status:   Open
 Bug Type: Reproducible crash
-Operating System: WinXP
+Operating System: *
-PHP Version:  5.0.1
+PHP Version:  4.3.8
-Assigned To:  
+Assigned To:  helly
 New Comment:

4.3.8 returns false which is wrong, too.


Previous Comments:


[2004-08-29 13:07:12] tomas_matousek at hotmail dot com

Description:

isset applied to operator [] with empty array key crashes

Reproduce code:
---
 $x = array();
 var_dump(isset($x[]));

Expected result:

bool(false)

Actual result:
--
Crash





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

#29882 [Opn]: isset crashes on arrays

2004-08-29 Thread helly 
 ID:   29882
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tomas_matousek at hotmail dot com
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: *
 PHP Version:  4.3.8
 Assigned To:  helly
 New Comment:

Fixed in 5, 4.3 still returns false.


Previous Comments:


[2004-08-29 15:27:28] [EMAIL PROTECTED]

4.3.8 returns false which is wrong, too.



[2004-08-29 13:07:12] tomas_matousek at hotmail dot com

Description:

isset applied to operator [] with empty array key crashes

Reproduce code:
---
 $x = array();
 var_dump(isset($x[]));

Expected result:

bool(false)

Actual result:
--
Crash





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

#29882 [Opn-Csd]: isset crashes on arrays

2004-08-29 Thread helly 
 ID:   29882
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tomas_matousek at hotmail dot com
-Status:   Open
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: *
 PHP Version:  4.3.8
 Assigned To:  helly
 New Comment:

This bug has been fixed in CVS.

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


Previous Comments:


[2004-08-29 15:42:57] [EMAIL PROTECTED]

Fixed in 5, 4.3 still returns false.



[2004-08-29 15:27:28] [EMAIL PROTECTED]

4.3.8 returns false which is wrong, too.



[2004-08-29 13:07:12] tomas_matousek at hotmail dot com

Description:

isset applied to operator [] with empty array key crashes

Reproduce code:
---
 $x = array();
 var_dump(isset($x[]));

Expected result:

bool(false)

Actual result:
--
Crash





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

#29882 [Csd]: isset crashes on arrays

2004-08-29 Thread helly 
 ID:   29882
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tomas_matousek at hotmail dot com
 Status:   Closed
 Bug Type: Reproducible crash
 Operating System: *
-PHP Version:  4.3.9, 5.0.1
+PHP Version:  4.3.8, 5.0.1
 Assigned To:  helly
 New Comment:

Correct versions. 4.3.9 and 5.0.2 will be correct.


Previous Comments:


[2004-08-29 18:56:39] [EMAIL PROTECTED]

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.



[2004-08-29 15:42:57] [EMAIL PROTECTED]

Fixed in 5, 4.3 still returns false.



[2004-08-29 15:27:28] [EMAIL PROTECTED]

4.3.8 returns false which is wrong, too.



[2004-08-29 13:07:12] tomas_matousek at hotmail dot com

Description:

isset applied to operator [] with empty array key crashes

Reproduce code:
---
 $x = array();
 var_dump(isset($x[]));

Expected result:

bool(false)

Actual result:
--
Crash





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

#29879 [Opn-WFx]: strtotime() should return false instead of -1 on failure

2004-08-29 Thread iliaa 
 ID:   29879
 Updated by:   [EMAIL PROTECTED]
 Reported By:  info at peter-thomassen dot de
-Status:   Open
+Status:   Wont fix
 Bug Type: Date/time related
 Operating System: any
 PHP Version:  Irrelevant
 New Comment:

This change would break backwards compatibility. 


Previous Comments:


[2004-08-29 00:50:56] info at peter-thomassen dot de

Description:

If an invalid time is specified, strtotime() returns -1. 
 
Because -1 is ambiguous (it could also mean 1969-12-31 
23:59:59 UTC), I request to return (bool)false on failure. 
 
BTW: 
http://www.gnu.org/software/tar/manual/html_chapter/tar_7.html#SEC117 
which is mentioned in the docs allows a number preceded by 
an '@' for the time argument to represent seconds since 
the epoch. This results in an error -- shall I report 
another bug for that? 
 
Thanks! 

Reproduce code:
---
?php
var_dump(strtotime('invalid'));
?

Expected result:

bool(false) 

Actual result:
--
int(-1) 





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

#29879 [WFx]: strtotime() should return false instead of -1 on failure

2004-08-29 Thread info at peter-thomassen dot de 
 ID:   29879
 User updated by:  info at peter-thomassen dot de
 Reported By:  info at peter-thomassen dot de
 Status:   Wont fix
 Bug Type: Date/time related
 Operating System: any
 PHP Version:  Irrelevant
 New Comment:

That's right, but I think -- since PHP5 is not that 
established to avoid any minor changes -- you can keep the 
old behaviour if zend.ze1_compatibility_mode is set to On 
and otherwise use more meaningful return values, can't 
you? 
 
I find it kind of sad if there wouldn't be any possibility 
to do proper date calculations, but another would be 
overkill ...


Previous Comments:


[2004-08-29 19:01:48] [EMAIL PROTECTED]

This change would break backwards compatibility. 



[2004-08-29 00:50:56] info at peter-thomassen dot de

Description:

If an invalid time is specified, strtotime() returns -1. 
 
Because -1 is ambiguous (it could also mean 1969-12-31 
23:59:59 UTC), I request to return (bool)false on failure. 
 
BTW: 
http://www.gnu.org/software/tar/manual/html_chapter/tar_7.html#SEC117 
which is mentioned in the docs allows a number preceded by 
an '@' for the time argument to represent seconds since 
the epoch. This results in an error -- shall I report 
another bug for that? 
 
Thanks! 

Reproduce code:
---
?php
var_dump(strtotime('invalid'));
?

Expected result:

bool(false) 

Actual result:
--
int(-1) 





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

#29884 [NEW]: incorrect intval return

2004-08-29 Thread babansky at cox dot net 
From: babansky at cox dot net
Operating system: Mandrake 9.2
PHP version:  4.3.7
PHP Bug Type: Strings related
Bug description:  incorrect intval return

Description:

if you try to do intval on the following string:
$str_value='09123456789';

you receive the following: 2147483647



Reproduce code:
---
$str_value='09123456789';

echo str_value - $str_valueBR;

$num_value=intval($str_value);
echo num_value - $num_valueBR;


Expected result:

$num_value = 9123456789

Actual result:
--
$num_value=2147483647

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

#29885 [NEW]: recursive functions on get_defined_vars() in PHP5

2004-08-29 Thread nospamplease at veganismus dot ch 
From: nospamplease at veganismus dot ch
Operating system: WinXP
PHP version:  5.0.1
PHP Bug Type: *General Issues
Bug description:  recursive functions on get_defined_vars() in PHP5

Description:

it seems that you cant use any recursive function on get_defined_vars() in
PHP5. 

?
$arr = get_defined_vars();
echo 'Number of Defined Vars: ';
echo count($arr,COUNT_RECURSIVE);
?

in PHP4 this will output some integer like 199 as expected.
in PHP5 this doesnt even output any error report. I just get a connection
closed by server message or the like. When changing line 3 to 
?
echo count($arr); // nonrecursive
?
it outputs something like 7 (which seems to be correct). also if i use
any multi-dimensional array instead of get_defined_vars() the result will
be correct.

Reproduce code:
---
?
$arr = get_defined_vars();
echo 'Number of Defined Vars: ';
echo count($arr,COUNT_RECURSIVE);
?

Expected result:

Number of Defined Vars: 199

Actual result:
--
The result is nothing (no errormessage by PHP5 or Apache2) so the acctualy
displayed message depends on the browser: 
Modzilla: The document contains no data.
Opera: connection closed by server
M$IE: Page Cannot Be Displayed

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

#29455 [Fbk-NoF]: DBA can not be built with FreeBSD DBM

2004-08-29 Thread php-bugs 
 ID:   29455
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dada at bbs dot giga dot net dot tw
-Status:   Feedback
+Status:   No Feedback
 Bug Type: *Compile Issues
 Operating System: FreeBSD
 PHP Version:  5.0.0
 Assigned To:  helly
 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:


[2004-08-22 17:59:05] [EMAIL PROTECTED]

Another thing we could do is providing a new subhandler called db1 to
deal with teh db 1.85 format interface. The question is whether that
makes sense and how to distinguish from ndbm interface and libs?



[2004-08-19 20:34:21] [EMAIL PROTECTED]

The dbm extension didn't care for the data format. Neither do you if
you are using ndm functions which are normally mapped to db2 or db3.
Also dbm is a bad idea because you can only have one single file open
(though we currently miss some check code for that).

To verify which what version you are dealing look for
'DB_VERSION_STRING' in the db.h file or any file it includes.

Maybe we can switch to search fro the db_185.h haeder and use that if
available. This thing also provides a way to open multiple datase
files. Probably this is what you see in your db.h file.



[2004-08-18 17:23:20] dada at bbs dot giga dot net dot tw

The deprecated DBM extension seems using 'ndbm' in FreeBSD
 (instead of built-in db library)
 for accessing Berkeley DB 1.85 format in BSD system.

1. Deprecated DBM extension use ndbm's dbm_open() in FreeBSD's
/usr/include/ndbm.h
2. my solution use dbopen() in FreeBSD's /usr/include/db.h

Both works!

My codes use the 2nd solution to support db 1.85 format.

Maybe you can barrow the codes from the deprecated DBM extension to
utilize the 1st solution
to support the Berkeley DB 1.85 format in FreeBSD.
This may increase the portability.

~ dada



[2004-08-05 04:05:21] dada at bbs dot giga dot net dot tw

I just send the modified source to you.

Thanks.



[2004-08-05 00:37:40] [EMAIL PROTECTED]

Please send me your handler file. I'll see what to do next. And thanks
for your patience and very much for your efforts in helping.



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

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

#29805 [Opn]: HTTP Authentication Issues

2004-08-29 Thread michaelw at webcentral dot com dot au 
 ID:   29805
 User updated by:  michaelw at webcentral dot com dot au
 Reported By:  michaelw at webcentral dot com dot au
 Status:   Open
 Bug Type: iPlanet related
 Operating System: Solaris 9
 PHP Version:  4.3.8
 New Comment:

Any progress with this ?


Previous Comments:


[2004-08-25 11:10:22] michaelw at webcentral dot com dot au

Currently, it is the ONLY AuthTrans directive.



[2004-08-25 11:05:24] [EMAIL PROTECTED]

The PHP AuthTrans must be the first AuthTrans directive. I can take a
look at this the next days.



[2004-08-25 00:45:31] michaelw at webcentral dot com dot au

From obj.conf

Object name=default
AuthTrans fn=php4_auth_trans

snipped



[2004-08-24 23:51:33] [EMAIL PROTECTED]

Have you installed the fake authenticator php4_ as written in the
docs?

To use PHP Authentication on a single directory, add the following:
Object ppath=d:\path\to\authenticated\dir\*
AuthTrans fn=php4_auth_trans
/Object

The problem is: iPlanet SunONE does not send the password to PHP so it
is not a problem of PHP. With the code from the docs you tell SunONE to
pass the authentication data to the fake function php4_auth_trans
that only says auth done and no other AuthTrans directives from
obj.conf get executed. This switches of all other authentication in the
server (Java, .htaccess,...) but lets PHP get the data. By limiting this
to a directory you can leave the SunONE authentication for other
directories intact.
 




[2004-08-24 03:39:56] michaelw at webcentral dot com dot au

Description:

Hi,

PHP HTTP Authentication under Sun One Webserver 6.0 (and presumably any
iPlanet variant) doesn't seem to work correctly.

The PHP_AUTH_USER and PHP_AUTH_PW variables don't seem to get set.
(This is with Safe Mode disabled). 

Additionally, with Safe Mode enabled, I cannot determine the username
or password entered by the user.  



Reproduce code:
---
?php
  if (!isset($_SERVER['PHP_AUTH_USER'])) {
   header('WWW-Authenticate: Basic realm=My Realm');
   header('HTTP/1.0 401 Unauthorized');
   echo 'Text to send if user hits Cancel button';
   exit;
  } else {
   echo pHello {$_SERVER['PHP_AUTH_USER']}./p;
   echo pYou entered {$_SERVER['PHP_AUTH_PW']} as your
password./p;
  }
?


Expected result:

Under apache, the output is:

Hello testing.

You entered 123 as your password.

(when username is testing and 123 is password)

Under SunOne, the username/password box just keeps redisplaying. 

Actual result:
--
Under SunOne, the username/password box just keeps redisplaying. 





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

#29886 [NEW]: segment fault when processing curl output with wrapper-registered stream

2004-08-29 Thread public at grik dot net 
From: public at grik dot net
Operating system: Linux
PHP version:  5CVS-2004-08-30 (dev)
PHP Bug Type: cURL related
Bug description:  segment fault when processing curl output with wrapper-registered 
stream

Description:

I register a wrapper, create a stream and pass the pointer to the
curl_setopt to process CURL output.
When amount of data returned by CURL exeeds 8192 bytes (size of the CURL
buffer), PHP ends with Segmentation fault.

I could not reach the crash using fwrite().

Similar problem was in PHP 4.3.3, in 4.3.7 everything works fine.
I detected this problem again in 5.0.0 and replicated it in the latest
stable CSV.

I do not know if it happens upon shutdown and if it is relevant to bug
#29358. This happens with CURL only.

Reproduce code:
---
The sample code can be found at:
http://www.grik.net/sample.phps

Can be run form command line:
php -f sample.php

Expected result:

In PHP 4.3.7 this script would output the amount of bytes obtained from
CURL:

8192
8192
...

Actual result:
--
In PHP 5.0.0:

8192
8192
Segmentation fault

Backtrace (I am not enough good with gdb, could not locate):

(gdb) bt
#0  0x081f714a in _zval_copy_ctor (zvalue=0x8344684,
__zend_filename=0x8273780
/usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c,
__zend_lineno=3001) at
/usr/src/web/php5-STABLE-200408292230/Zend/zend_variables.c:136
#1  0x08227ab6 in zend_send_by_var_helper (execute_data=0xbfffb210,
opline=0x8349e38, op_array=0x834b0e4)
at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c:3001
#2  0x08221824 in zend_send_var_handler (execute_data=0xbfffb210,
opline=0x8349e38, op_array=0x834b0e4)
at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c:3061
#3  0x0821cb76 in execute (op_array=0x834b0e4)
at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute.c:1400
#4  0x081ed157 in zend_call_function (fci=0xbfffb370, fci_cache=0x0)
at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute_API.c:835
#5  0x081ec1a9 in call_user_function_ex (function_table=0x0,
object_pp=0x82e5f00,
function_name=0xbfffb400, retval_ptr_ptr=0xbfffb3fc, param_count=1,
params=0xbfffb3f0,
no_separation=0, symbol_table=0x0)
at /usr/src/web/php5-STABLE-200408292230/Zend/zend_execute_API.c:550
#6  0x081cd58c in php_userstreamop_write (stream=0x83446c4,
buf=0x4003 !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01
Transitional//EN\\nhtml\nhead\n titlePHP: Hypertext
Preprocessor/title\n link rel=\stylesheet\
href=\http://static.php.net/www.php.net/style.css\; /\n...,
count=8192)
at /usr/src/web/php5-STABLE-200408292230/main/streams/userspace.c:459
#7  0x081c539d in _php_stream_write_buffer (stream=0x83446c4,
buf=0x4003 !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01
Transitional//EN\\nhtml\nhead\n titlePHP: Hypertext
Preprocessor/title\n link rel=\stylesheet\
href=\http://static.php.net/www.php.net/style.css\; /\n..., count=8192)
at /usr/src/web/php5-STABLE-200408292230/main/streams/streams.c:889
#8  0x081c561f in _php_stream_write (stream=0x83446c4,
buf=0x4003 !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01
Transitional//EN\\nhtml\nhead\n titlePHP: Hypertext
Preprocessor/title\n link rel=\stylesheet\
href=\http://static.php.net/www.php.net/style.css\; /\n..., count=8192)
at /usr/src/web/php5-STABLE-200408292230/main/streams/streams.c:1000
#9  0x081c7c66 in stream_cookie_writer (cookie=0x83446c4,
buffer=0x4003 !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01
Transitional//EN\\nhtml\nhead\n titlePHP: Hypertext
Preprocessor/title\n link rel=\stylesheet\
href=\http://static.php.net/www.php.net/style.css\; /\n..., size=8192)
at /usr/src/web/php5-STABLE-200408292230/main/streams/cast.c:96
#10 0x42062019 in _IO_cookie_write () from /lib/tls/libc.so.6
#11 0x4206d09e in new_do_write () from /lib/tls/libc.so.6
#12 0x4206d036 in _IO_new_do_write () from /lib/tls/libc.so.6
#13 0x4206d7b8 in _IO_new_file_overflow () from /lib/tls/libc.so.6
#14 0x4206e220 in _IO_new_file_xsputn () from /lib/tls/libc.so.6
#15 0x42062a62 in fwrite () from /lib/tls/libc.so.6
#16 0x40027de3 in last_use () from /usr/lib/20040412/curl.so
#17 0x4064c139 in Curl_client_write (data=0x834c50c, type=1,
ptr=0x834c7b8 \n The PHP Development Team would like to announce the
immediate availability of a href=\/downloads.php\PHP 5.0.1/a.\n This
is a maintenance release that in addition to many non-critical bug fixes
..., len=1448) at sendf.c:337
#18 0x40663fcf in Curl_httpchunk_read (conn=0x8344f3c,
datap=0x834c7b8 \n The PHP Development Team would like to announce
the immediate availability of a href=\/downloads.php\PHP 5.0.1/a.\n
This is a maintenance release that in addition to many non-critical bug
fixes ..., datalen=1448, wrotep=0xbfffb880) at http_chunks.c:186
#19 0x40660fd7 in Curl_readwrite (conn=0x8344f3c, done=0xbfffb8df ) at
transfer.c:980
#20 0x40661f56 in Transfer (conn=0x8344f3c) at transfer.c:1480
#21 0x4066294a in

#29888 [NEW]: Compile Failure due to mbstring error: redefinition of `struct re_registers'

2004-08-29 Thread alietss at yahoo dot com 
From: alietss at yahoo dot com
Operating system: Fedora Core 2
PHP version:  5.0.1
PHP Bug Type: Compile Failure
Bug description:  Compile Failure due to mbstring error: redefinition of `struct 
re_registers'

Description:

Hi php team, I'm trying to build rpms of php 5.0.1 on a Fedora Core 2
system, with httpd-2.0.50, but the compile process is failing to a error
related to mbstring here my configure line and the error...

%configure \
--cache-file=../config.cache \
--with-config-file-path=%{_sysconfdir} \
--with-config-file-scan-dir=%{_sysconfdir}/php.d \
--enable-force-cgi-redirect \
--disable-debug \
--enable-pic \
--disable-rpath \
--enable-inline-optimization \
--with-bz2 \
--with-db4=%{_prefix} \
--with-curl \
--with-exec-dir=%{_bindir} \
--with-freetype-dir=%{_prefix} \
--with-png-dir=%{_prefix} \
--with-gd \
--enable-gd-native-ttf \
--without-gdbm \
--with-gettext \
--with-ncurses \
--with-gmp \
--with-iconv \
--with-jpeg-dir=%{_prefix} \
--with-openssl \
--with-png \
--with-pspell \
--with-regex=system \
--with-xml \
--with-expat-dir=%{_prefix} \
--with-dom=shared,%{_prefix} \
--with-dom-xslt=%{_prefix} --with-dom-exslt=%{_prefix} \
--with-xmlrpc=shared \
--with-pcre-regex=%{_prefix} \
--with-zlib \
--with-layout=GNU \
--enable-bcmath \
--enable-exif \
--enable-ftp \
--enable-magic-quotes \
--enable-safe-mode \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-track-vars \
--enable-trans-sid \
--enable-yp \
--enable-wddx \
--with-pear=/usr/share/pear \
--with-imap=shared --with-imap-ssl \
--with-kerberos \
--with-ldap=shared \
--with-mysql=shared,%{_prefix} \
%{?_with_oci8:--with-oci8=shared} \
%{?_with_mssql:--with-mssql=shared} \
%{?_with_mhash:--with-mhash=shared} \
--with-pgsql=shared \
--with-snmp=shared,%{_prefix} \
--with-snmp=shared \
--enable-ucd-snmp-hack \
--with-unixODBC=shared,%{_prefix} \
--enable-memory-limit \
--enable-bcmath \
--enable-shmop \
--enable-calendar \
--enable-dbx \
--enable-dio \
--enable-mcal \
--enable-mbstring=shared --enable-mbstr-enc-trans \
--enable-mbregex \
$*

make %{?_smp_mflags}
}

the error...

In file included from
/usr/src/redhat/BUILD/php-5.0.1/ext/mbstring/php_mbregex.h:28,
 from
/usr/src/redhat/BUILD/php-5.0.1/ext/mbstring/mbstring.h:77,
 from
/usr/src/redhat/BUILD/php-5.0.1/ext/standard/html.c:52:
/usr/src/redhat/BUILD/php-5.0.1/ext/mbstring/oniguruma/oniguruma.h:573:
error: redefinition of `struct re_registers'
make: *** [ext/standard/html.lo] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.73791 (%build)
 
 
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.73791 (%build)


Expected result:

php builds


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

#29884 [Opn-Bgs]: incorrect intval return

2004-08-29 Thread tony2001 
 ID:   29884
 Updated by:   [EMAIL PROTECTED]
 Reported By:  babansky at cox dot net
-Status:   Open
+Status:   Bogus
 Bug Type: Strings related
 Operating System: Mandrake 9.2
 PHP Version:  4.3.7
 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. 

Thank you for your interest in PHP.

Read about octal numbers and type-juggling here:
http://www.php.net/manual/en/language.types.integer.php


Previous Comments:


[2004-08-29 22:57:13] babansky at cox dot net

Description:

if you try to do intval on the following string:
$str_value='09123456789';

you receive the following: 2147483647



Reproduce code:
---
$str_value='09123456789';

echo str_value - $str_valueBR;

$num_value=intval($str_value);
echo num_value - $num_valueBR;


Expected result:

$num_value = 9123456789

Actual result:
--
$num_value=2147483647





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

#29763 [Opn-Bgs]: mysql_pconnect silently ignores the CLIENT_FOUND_ROWS flag

2004-08-29 Thread georg 
 ID:   29763
 Updated by:   [EMAIL PROTECTED]
 Reported By:  sigurd at totallydigital dot co dot nz
-Status:   Open
+Status:   Bogus
 Bug Type: MySQL related
 Operating System: Debian Linux
 PHP Version:  4.3.8
 New Comment:

mysql_pconnect tries to reuse an exisiting connection with 
the same host/port/username/password from connection pool. 
If you don't open every connection with same client flags, 
it can happen that you will get an exisiting connection, 
where these flags weren't set. 
 
You should use mysql_connect or always call mysql_pconnect 
with the client_flags you need. It isn't possible to 
change client_flags for an existing connection. 


Previous Comments:


[2004-08-28 22:54:13] sigurd at totallydigital dot co dot nz

Read the original post. I am not asking for it to return changed rows,
I am asking it to return FOUND rows. You are supposed to be able to do
this by setting a flag upon connection and this does was not
experienced.

One reason for using found rows is where you have a standard function
in an abstraction layer to perform updates, and it wants to ensure that
you updated (or could have updated) a row, and throw an error if the
'where' clause returned no rows to update, as opposed to the data being
identical. This  makes for wise error checking.

The point is, I set the CLIENT_FOUND_ROWS flag upon connection, which
is supposed to define a certain behaviour, and this behaviour is not
experienced.

Additionally, the behaviour is inconsistant between a normal  and
persistant connection.



[2004-08-28 20:24:03] [EMAIL PROTECTED]

Why would it tell you it changed something when it doesn't?
If you update a field with same data as it was before - there is no
_change_ or affected rows.

Try the same with the mysql console.




[2004-08-19 19:46:45] sigurd at totallydigital dot co dot nz

Description:

PHP 4.3.8-5 installed as 'unstable' package from Debian recently.

Background: 

The CLIENT_FOUND_ROWS MySQL connection flag is a vital means for
verifying that an UPDATE has affected a row (without doing an
inefficient 'select' afterwards to doublecheck!)

Under 'normal' connection, however, an UPDATE that updates values to
what they are in the database already will not increment the
affected-row-count, hence the purpose of the CLIENT_FOUND_ROWS flag,
which when set, DOES return rows that matched the WHERE clause of the
UPDATE.

Bug:

When connecting to a server with 

$connectionid = mysql_pconnect($serveraddress, $username, $password,
2);

The CLIENT_FOUND_ROWS behaviour is not experienced.

Merely changing this to a standard connect, does work. (note the
addition of a fourth parameter!) E.g.;

$connectionid = mysql_pconnect($serveraddress, $username, $password,
false, 2);

Reproduce code:
---
$connectionid = mysql_pconnect($serveraddress, $username, $password,
2);

// aasume Field was not 1 to begin with;
mysql_query(UPDATE Field=1 WHERE SomeField=1);
print mysql_affected_rows(); // 1

mysql_query(UPDATE Field=1 WHERE SomeField=1);
print mysql_affected_rows(); // 0

// again for good measure.
mysql_query(UPDATE Field=5 WHERE SomeField=1);
print mysql_affected_rows(); // 1

Expected result:

Each update shold produce an affected row count of one.






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

#29763 [Bgs]: mysql_pconnect silently ignores the CLIENT_FOUND_ROWS flag

2004-08-29 Thread sigurd at totallydigital dot co dot nz 
 ID:   29763
 User updated by:  sigurd at totallydigital dot co dot nz
 Reported By:  sigurd at totallydigital dot co dot nz
 Status:   Bogus
 Bug Type: MySQL related
 Operating System: Debian Linux
 PHP Version:  4.3.8
 New Comment:

Thank you. This make sense :)

I presume in that case I will revert to standard connect in this case.
It is possible to check the flags that are in operation on a
connection?

It believe it will be worthwhile throwing a mysql warning in pconnect
where the flags requested do not match the flags a connection has.

(It makes me realise there is a dangerous caveat with opening a
persistant 'found_rows' connection, if another independant script
performs a pconnect, expecting normal affected_rows behavious).


Previous Comments:


[2004-08-30 07:04:30] [EMAIL PROTECTED]

mysql_pconnect tries to reuse an exisiting connection with 
the same host/port/username/password from connection pool. 
If you don't open every connection with same client flags, 
it can happen that you will get an exisiting connection, 
where these flags weren't set. 
 
You should use mysql_connect or always call mysql_pconnect 
with the client_flags you need. It isn't possible to 
change client_flags for an existing connection. 



[2004-08-28 22:54:13] sigurd at totallydigital dot co dot nz

Read the original post. I am not asking for it to return changed rows,
I am asking it to return FOUND rows. You are supposed to be able to do
this by setting a flag upon connection and this does was not
experienced.

One reason for using found rows is where you have a standard function
in an abstraction layer to perform updates, and it wants to ensure that
you updated (or could have updated) a row, and throw an error if the
'where' clause returned no rows to update, as opposed to the data being
identical. This  makes for wise error checking.

The point is, I set the CLIENT_FOUND_ROWS flag upon connection, which
is supposed to define a certain behaviour, and this behaviour is not
experienced.

Additionally, the behaviour is inconsistant between a normal  and
persistant connection.



[2004-08-28 20:24:03] [EMAIL PROTECTED]

Why would it tell you it changed something when it doesn't?
If you update a field with same data as it was before - there is no
_change_ or affected rows.

Try the same with the mysql console.




[2004-08-19 19:46:45] sigurd at totallydigital dot co dot nz

Description:

PHP 4.3.8-5 installed as 'unstable' package from Debian recently.

Background: 

The CLIENT_FOUND_ROWS MySQL connection flag is a vital means for
verifying that an UPDATE has affected a row (without doing an
inefficient 'select' afterwards to doublecheck!)

Under 'normal' connection, however, an UPDATE that updates values to
what they are in the database already will not increment the
affected-row-count, hence the purpose of the CLIENT_FOUND_ROWS flag,
which when set, DOES return rows that matched the WHERE clause of the
UPDATE.

Bug:

When connecting to a server with 

$connectionid = mysql_pconnect($serveraddress, $username, $password,
2);

The CLIENT_FOUND_ROWS behaviour is not experienced.

Merely changing this to a standard connect, does work. (note the
addition of a fourth parameter!) E.g.;

$connectionid = mysql_pconnect($serveraddress, $username, $password,
false, 2);

Reproduce code:
---
$connectionid = mysql_pconnect($serveraddress, $username, $password,
2);

// aasume Field was not 1 to begin with;
mysql_query(UPDATE Field=1 WHERE SomeField=1);
print mysql_affected_rows(); // 1

mysql_query(UPDATE Field=1 WHERE SomeField=1);
print mysql_affected_rows(); // 0

// again for good measure.
mysql_query(UPDATE Field=5 WHERE SomeField=1);
print mysql_affected_rows(); // 1

Expected result:

Each update shold produce an affected row count of one.






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