date:20030205

 ID:   20874
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   No Feedback
+Status:   Duplicate
 Bug Type: Sockets related
 Operating System: Windows XP
 PHP Version:  4.3.0RC2
 New Comment:

21197 seems to provide better information. Will mark this 
one as duplicate. 
Please add new comments to: 21197 
 


Previous Comments:


[2003-02-05 21:33:16] [EMAIL PROTECTED]

duplicate of #21197

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



[2002-12-25 01:00:03] [EMAIL PROTECTED]

No feedback was provided for this bug for over 2 weeks, 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".



[2002-12-09 09:22:53] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2002-12-07 15:09:06] [EMAIL PROTECTED]

I downgraded the PHP version on this server to 4.2.2
It now works properly on this version.

It crashes on socket_read();

The parameters I am using in my Application are:
socket_read($this->sock[1],2048);

Like I said, the Example Aplication from the PHP Manual for  a WWW
Client also crashes, also on socket_read.



[2002-12-07 14:52:22] [EMAIL PROTECTED]

Can you isolate the function that crashes & with what parameters? So
far, I was unable to reproduce the crash using the test servers I have
here.



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

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

#22078 [Opn->Csd]: iconv is not recognized during ./configure

 ID:   22078
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: ICONV related
 Operating System: OpenBSD 3.2 sparc64
 PHP Version:  4.2.3
 New Comment:

O.k. we'll take a look into the other problems.

Now closing this report... (fixed in later versions)


Previous Comments:


[2003-02-05 15:30:31] [EMAIL PROTECTED]

See bug #22076 & #22077



[2003-02-05 14:05:41] [EMAIL PROTECTED]

As we don't support older versions anymore, I yet think the best
solution is to use 4.3.0.

Then, what's wrong with the latest version?




[2003-02-05 13:50:45] [EMAIL PROTECTED]

1. ./configure --prefix=/usr/local/libiconv

2. Not the case; always uninstalled previous versions before I tried a
new one.

3. Works; however I have other problems with 4.3.0 hence me trying
4.2.3



[2003-02-05 13:36:37] [EMAIL PROTECTED]

1) What option did you specify at the libiconv's configure script?

2) Please check whether another iconv library such as BSD iconv is
installed somewhere else. When two different iconv implementations are
installed, configure may fail.

3) Try the best available version, 4.3.0.





[2003-02-05 11:50:12] [EMAIL PROTECTED]

I reproduced this with iconv 1.8 & 1.7.
Tried the packages and compiling iconv myself. The outcome was
identical.

./configure --with-zlib --with-gd --with-jpeg --with-png
--with-mysql=/usr/local/mysql --with-curl --with-gdbm --with-xmlrpc
--with-dom --with-dom-xslt --with-expat --with
-iconv=/usr/local/libiconv/ --with-iconv-dir=/usr/local/libiconv/



configure: error: Please specify the install prefix of iconv with
--with-iconv=





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

#20874 [Com]: socket_read on Multihomed Windows XP crashes PHP

 ID:   20874
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   No Feedback
 Bug Type: Sockets related
 Operating System: Windows XP
 PHP Version:  4.3.0RC2
 New Comment:

duplicate of #21197

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


Previous Comments:


[2002-12-25 01:00:03] [EMAIL PROTECTED]

No feedback was provided for this bug for over 2 weeks, 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".



[2002-12-09 09:22:53] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2002-12-07 15:09:06] [EMAIL PROTECTED]

I downgraded the PHP version on this server to 4.2.2
It now works properly on this version.

It crashes on socket_read();

The parameters I am using in my Application are:
socket_read($this->sock[1],2048);

Like I said, the Example Aplication from the PHP Manual for  a WWW
Client also crashes, also on socket_read.



[2002-12-07 14:52:22] [EMAIL PROTECTED]

Can you isolate the function that crashes & with what parameters? So
far, I was unable to reproduce the crash using the test servers I have
here.



[2002-12-07 04:21:59] [EMAIL PROTECTED]

I have written a couple OO-PHP based TCP clients for a Proprietary PHP
Socket Server that create a web based interface to certin aspects of
an
unnamed server.

This week, we had some hardware trouble, and we ended up moving one
server to Windows XP instead of Windows 2000.  It was a clean
format.(new hd)

After some intial re-installation, I have found, that anytime I call
the
socket_read function PHP promptly crashes.  The exact same code worked
on the same hardware running windows 2000, and the code also works
completely on Slackware-9.0(current).

The only thing that is unquie about this server is that it is
Multihomed
to about 30 different IP addresses.

This is repeatable. 100% everytime, using Apache2 Module, Apache13
Module, and the CLI interfaces to PHP.

The example script for a TCP Client on the Sockets Documentation also
crashes PHP:
TCP/IP Connection\n";

/* Get the port for the WWW service. */
$service_port = getservbyname ('www', 'tcp');

/* Get the IP address for the target host. */
$address = gethostbyname ('www.example.com');

/* Create a TCP/IP socket. */
$socket = socket_create (AF_INET, SOCK_STREAM, 0);
if ($socket < 0) {
echo "socket_create() failed: reason: " . socket_strerror
($socket)
. "\n";
} else {
echo "OK.\n";
}

echo "Attempting to connect to '$address' on port '$service_port'...";
$result = socket_connect ($socket, $address, $service_port);
if ($result < 0) {
echo "socket_connect() failed.\nReason: ($result) " .
socket_strerror($result) . "\n";
} else {
echo "OK.\n";
}

$in = "HEAD / HTTP/1.0\r\n\r\n";
$out = '';

echo "Sending HTTP HEAD request...";
socket_write ($socket, $in, strlen ($in));
echo "OK.\n";

echo "Reading response:\n\n";
while ($out = socket_read ($socket, 2048)) {
echo $out;
}

echo "Closing socket...";
socket_close ($socket);
echo "OK.\n\n";
?>

It gets to the echo "Reading response:\n\n"; and then PHP crashes, and
I
get the Windows XP message asking if I would like to send Microsoft a
bug report. I have several times. Maybe they will respond :-)



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

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

#21760 [Com]: socket_read PHP_NORMAL_READ problem

 ID:   21760
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Sockets related
 Operating System: FreeBSD 4.7
 PHP Version:  4.3.0
 New Comment:

ah. found my windows 2000 socket_read bug:
http://bugs.php.net/bug.php?id=21197


Previous Comments:


[2003-02-05 21:08:07] [EMAIL PROTECTED]

I can repeat this bug.

here is an example script that i used:
http://force-elite.com/~chip/test/socket_phpreadnormal.phps

it is a modification of the basic HTTP client given as an example in
the PHP.net documentation.

When PHP_NORMAL_READ is used, and certen buffer sizes, it will resuilt
in socket_read returning bogus data, commonly all newlines(\n).

On both a FreeBSD-4.7-stable(built Fri Nov 29), and
FreeBSD-5.0-RC(built Wed Jan 8), both using PHP-4.3.0-cli, with a
buffer size of 2048 it would work, with a buffer size of 100,
socket_read() would return a stream of \n.

On Linux 2.4.18-18.7.x(Redhat Box) using PHP-4.3.0-cli, it would always
work, regardless of the buffer size.

On Linux 2.4.19-crypto-r7(Gentoo Box) using PHP-4.3.0-cli, it would
work with 2048 buffer size, but with 100 it would bail with:
Notice: Undefined offset:  0 in /path/socket_phpreadnormal.php on line
51
Warning: socket_read() expects parameter 1 to be resource,
null given in /path/socket_phpreadnormal.php on line 51
(I don't have direct access to this box, I didn't want to heavly debug
it, it is possibly an error in my script.)

On Windows 2000, using PHP-4.3.0-cli, it would always return 0(EOF)
from socket_read(). It Bailed with:
Warning: socket_read() unable to read from socket [0]: The operation
completed successfully.
(perhaps a seperate bug :-) )



[2003-02-05 09:53:04] [EMAIL PROTECTED]

I believe this is caused by a comparison to an uninitialized buffer in
php_read (buffer emalloc'd in socket_read).

Patch:

--- php5/ext/sockets/sockets.c  2003-01-18 19:28:06.0 +
+++ php5-atropine/ext/sockets/sockets.c  2003-02-05 15:43:00.0
+
@@ -288,6 +288,7 @@
 
set_errno(0);
 
+   *t = 0;
while (*t != '\n' && *t != '\r' && n < maxlen) {
if (m > 0) {
t++;



[2003-01-19 23:18:44] [EMAIL PROTECTED]

$string = socket_read( $socket, 100, PHP_NORMAL_READ ); will return a
"\n" after several reads, and continue to return "\n" in an infinite
loop rather than the rest of the buffer.

The server it's reading from sends a large multi-line (lines terminated
with "\n") packet (~7500 bytes) in one write() call. After reading
through about half of it with the line above, socket_read will start
returning bad data about 10% - 20% of the time.




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

#21197 [Com]: socket_read() seems to doesn't work

 ID:   21197
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Analyzed
 Bug Type: Sockets related
 Operating System: Win2k pro
 PHP Version:  4.3.0RC4
 New Comment:

See my comment on this bug report:
http://bugs.php.net/bug.php?id=21760

I tested the same script on windows 2000, and it broke.


Previous Comments:


[2003-01-09 13:13:25] [EMAIL PROTECTED]

I've analyzed this bug. It's because of fcntl() that just returns -1
under windows when F_GETFL is given. Then the php_read function just
also returns -1 and then socket_read sends the error because it
returned -1. 

I've sent my comment to Wez too.



[2002-12-30 23:08:50] [EMAIL PROTECTED]

I've experianced this bug on WindowsXP also. I've tried PHP 4.3.0
(stable) and 4.4.0-dev just to see if it was fixed, and it is not. I
have also talked to someone with WindowsXP who experianced this problem
in PHP 4.2.3. The function does work fine without a third parameter,
but, this is a big inconvienice when I need the read to stop at \n or
\r. The function just stops reading when the buffer is full if there is
no third parameter. Hope this is helpful.



[2002-12-26 20:39:22] [EMAIL PROTECTED]

If you omit the third parameter to socket_read() it seems to work fine.
However, adding PHP_NORMAL_READ causes error as described in the bug
report.



[2002-12-26 09:32:25] [EMAIL PROTECTED]

Hello

I have a source which works with PHP 4.1.x to PHP 4.2.x,
it's work perfectly. But with PHP 4.3RC4 (windows version,
client mode) I have this warning :
Warning: socket_read() unable to read from socket [0]: OpÚration
rÚussie. in E:\PHP\KioobFTP\v0.7.1\KioobFTP_SocketMode.php on line 262

Then, the result of the function is FALSE. 
The socket is in blocking mode.
The code is :
$tmp=socket_read($this->stream,4096,PHP_NORMAL_READ);

Do you need others info ?

Thanks.

Bool




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

#21760 [Com]: socket_read PHP_NORMAL_READ problem

 ID:   21760
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Sockets related
 Operating System: FreeBSD 4.7
 PHP Version:  4.3.0
 New Comment:

I can repeat this bug.

here is an example script that i used:
http://force-elite.com/~chip/test/socket_phpreadnormal.phps

it is a modification of the basic HTTP client given as an example in
the PHP.net documentation.

When PHP_NORMAL_READ is used, and certen buffer sizes, it will resuilt
in socket_read returning bogus data, commonly all newlines(\n).

On both a FreeBSD-4.7-stable(built Fri Nov 29), and
FreeBSD-5.0-RC(built Wed Jan 8), both using PHP-4.3.0-cli, with a
buffer size of 2048 it would work, with a buffer size of 100,
socket_read() would return a stream of \n.

On Linux 2.4.18-18.7.x(Redhat Box) using PHP-4.3.0-cli, it would always
work, regardless of the buffer size.

On Linux 2.4.19-crypto-r7(Gentoo Box) using PHP-4.3.0-cli, it would
work with 2048 buffer size, but with 100 it would bail with:
Notice: Undefined offset:  0 in /path/socket_phpreadnormal.php on line
51
Warning: socket_read() expects parameter 1 to be resource,
null given in /path/socket_phpreadnormal.php on line 51
(I don't have direct access to this box, I didn't want to heavly debug
it, it is possibly an error in my script.)

On Windows 2000, using PHP-4.3.0-cli, it would always return 0(EOF)
from socket_read(). It Bailed with:
Warning: socket_read() unable to read from socket [0]: The operation
completed successfully.
(perhaps a seperate bug :-) )


Previous Comments:


[2003-02-05 09:53:04] [EMAIL PROTECTED]

I believe this is caused by a comparison to an uninitialized buffer in
php_read (buffer emalloc'd in socket_read).

Patch:

--- php5/ext/sockets/sockets.c  2003-01-18 19:28:06.0 +
+++ php5-atropine/ext/sockets/sockets.c  2003-02-05 15:43:00.0
+
@@ -288,6 +288,7 @@
 
set_errno(0);
 
+   *t = 0;
while (*t != '\n' && *t != '\r' && n < maxlen) {
if (m > 0) {
t++;



[2003-01-19 23:18:44] [EMAIL PROTECTED]

$string = socket_read( $socket, 100, PHP_NORMAL_READ ); will return a
"\n" after several reads, and continue to return "\n" in an infinite
loop rather than the rest of the buffer.

The server it's reading from sends a large multi-line (lines terminated
with "\n") packet (~7500 bytes) in one write() call. After reading
through about half of it with the line above, socket_read will start
returning bad data about 10% - 20% of the time.




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

#22073 [Csd]: --with-mcrypt won't compile

 ID:   22073
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Compile Failure
 Operating System: Red Hat Linux 8.0
 PHP Version:  4.3.0
 New Comment:

Any idea what the bug was?

If it's too much trouble to track down the source of the bug don't wory
about it but if someone knows please do tell :)


Previous Comments:


[2003-02-05 20:43:38] [EMAIL PROTECTED]

User reports the bug is gone in CVS => Closed. 



[2003-02-05 20:38:39] [EMAIL PROTECTED]

Bug disapears with newest CVS snapshot. Thank you.

Just curious but what was the bug?



[2003-02-05 11:48:24] [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

Very likely to be fixed in CVS.



[2003-02-05 11:14:00] [EMAIL PROTECTED]

Sorry, I forgot to answer you question about mcrypt version.

# libmcrypt-config --version
2.5.6



[2003-02-05 10:55:26] [EMAIL PROTECTED]

I am not using mcrypt. I am only using libmcrypt (as per the PHP
documentation). The version is 2.5.6

> When you are using the --with-mcrypt=../libmcrypt-2.5.6/, does it
still
try to open /usr/local/include/mcrypt.h?

Uh ... don't know. How do I find the answer for you?

I followed your suggestions, here is the result:

# cd /usr/src/php-4.3.0/
# rm config.cache 
# make clean
find . -name \*.lo -o -name \*.o | xargs rm -f
find . -name \*.la -o -name \*.a | xargs rm -f 
find . -name \*.so | xargs rm -f
find . -name .libs -a -type d|xargs rm -rf
rm -f libphp4.la sapi/cli/php libphp4.la modules/* libs/*
# ./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt  
[...]
Configuring extensions
[...]
checking for mcrypt support... yes
checking for mcrypt_module_open in -lmcrypt... no
checking for init_mcrypt in -lmcrypt... yes

# make
gcc  -Iext/ctype/ -I/usr/src/php-4.3.0/ext/ctype/ -DPHP_ATOM_INC
-I/usr/src/php-4.3.0/include -I/usr/src/php-4.3.0/main
-I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend -I/usr/local/include
-I/usr/src/php-4.3.0/ext/xml/expat  -I/usr/src/php-4.3.0/TSRM  -g -O2 
-c /usr/src/php-4.3.0/ext/ctype/ctype.c -o ext/ctype/ctype.o  && echo >
ext/ctype/ctype.lo
cc1: warning: changing search order for system directory
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system
directory
gcc  -Iext/mcrypt/ -I/usr/src/php-4.3.0/ext/mcrypt/ -DPHP_ATOM_INC
-I/usr/src/php-4.3.0/include -I/usr/src/php-4.3.0/main
-I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend -I/usr/local/include
-I/usr/src/php-4.3.0/ext/xml/expat  -I/usr/src/php-4.3.0/TSRM  -g -O2 
-c /usr/src/php-4.3.0/ext/mcrypt/mcrypt.c -o ext/mcrypt/mcrypt.o  &&
echo > ext/mcrypt/mcrypt.lo
cc1: warning: changing search order for system directory
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system
directory
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:229:1: warning: "MCRYPT_FAILED"
redefined
In file included from /usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:34:
/usr/local/include/mcrypt.h:31:1: warning: this is the location of the
previous definition
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c: In function
`zm_startup_mcrypt':
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:279: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:280: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: `MCRYPT_BLOWFISH_128'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: (Each undeclared identifier
is reported only once
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: for each function it
appears in.)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:282: `MCRYPT_BLOWFISH_192'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:283: `MCRYPT_BLOWFISH_256'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:284: `MCRYPT_BLOWFISH_448'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:285: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:286: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:287: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.

#22073 [Opn->Csd]: --with-mcrypt won't compile

 ID:   22073
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: Red Hat Linux 8.0
 PHP Version:  4.3.0
 New Comment:

User reports the bug is gone in CVS => Closed. 


Previous Comments:


[2003-02-05 20:38:39] [EMAIL PROTECTED]

Bug disapears with newest CVS snapshot. Thank you.

Just curious but what was the bug?



[2003-02-05 11:48:24] [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

Very likely to be fixed in CVS.



[2003-02-05 11:14:00] [EMAIL PROTECTED]

Sorry, I forgot to answer you question about mcrypt version.

# libmcrypt-config --version
2.5.6



[2003-02-05 10:55:26] [EMAIL PROTECTED]

I am not using mcrypt. I am only using libmcrypt (as per the PHP
documentation). The version is 2.5.6

> When you are using the --with-mcrypt=../libmcrypt-2.5.6/, does it
still
try to open /usr/local/include/mcrypt.h?

Uh ... don't know. How do I find the answer for you?

I followed your suggestions, here is the result:

# cd /usr/src/php-4.3.0/
# rm config.cache 
# make clean
find . -name \*.lo -o -name \*.o | xargs rm -f
find . -name \*.la -o -name \*.a | xargs rm -f 
find . -name \*.so | xargs rm -f
find . -name .libs -a -type d|xargs rm -rf
rm -f libphp4.la sapi/cli/php libphp4.la modules/* libs/*
# ./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt  
[...]
Configuring extensions
[...]
checking for mcrypt support... yes
checking for mcrypt_module_open in -lmcrypt... no
checking for init_mcrypt in -lmcrypt... yes

# make
gcc  -Iext/ctype/ -I/usr/src/php-4.3.0/ext/ctype/ -DPHP_ATOM_INC
-I/usr/src/php-4.3.0/include -I/usr/src/php-4.3.0/main
-I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend -I/usr/local/include
-I/usr/src/php-4.3.0/ext/xml/expat  -I/usr/src/php-4.3.0/TSRM  -g -O2 
-c /usr/src/php-4.3.0/ext/ctype/ctype.c -o ext/ctype/ctype.o  && echo >
ext/ctype/ctype.lo
cc1: warning: changing search order for system directory
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system
directory
gcc  -Iext/mcrypt/ -I/usr/src/php-4.3.0/ext/mcrypt/ -DPHP_ATOM_INC
-I/usr/src/php-4.3.0/include -I/usr/src/php-4.3.0/main
-I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend -I/usr/local/include
-I/usr/src/php-4.3.0/ext/xml/expat  -I/usr/src/php-4.3.0/TSRM  -g -O2 
-c /usr/src/php-4.3.0/ext/mcrypt/mcrypt.c -o ext/mcrypt/mcrypt.o  &&
echo > ext/mcrypt/mcrypt.lo
cc1: warning: changing search order for system directory
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system
directory
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:229:1: warning: "MCRYPT_FAILED"
redefined
In file included from /usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:34:
/usr/local/include/mcrypt.h:31:1: warning: this is the location of the
previous definition
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c: In function
`zm_startup_mcrypt':
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:279: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:280: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: `MCRYPT_BLOWFISH_128'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: (Each undeclared identifier
is reported only once
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: for each function it
appears in.)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:282: `MCRYPT_BLOWFISH_192'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:283: `MCRYPT_BLOWFISH_256'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:284: `MCRYPT_BLOWFISH_448'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:285: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:286: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:287: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:288: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:289: `MCRYPT_IDEA' undeclared
(first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.

#22073 [Fbk->Opn]: --with-mcrypt won't compile

 ID:   22073
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: Red Hat Linux 8.0
 PHP Version:  4.3.0
 New Comment:

Bug disapears with newest CVS snapshot. Thank you.

Just curious but what was the bug?


Previous Comments:


[2003-02-05 11:48:24] [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

Very likely to be fixed in CVS.



[2003-02-05 11:14:00] [EMAIL PROTECTED]

Sorry, I forgot to answer you question about mcrypt version.

# libmcrypt-config --version
2.5.6



[2003-02-05 10:55:26] [EMAIL PROTECTED]

I am not using mcrypt. I am only using libmcrypt (as per the PHP
documentation). The version is 2.5.6

> When you are using the --with-mcrypt=../libmcrypt-2.5.6/, does it
still
try to open /usr/local/include/mcrypt.h?

Uh ... don't know. How do I find the answer for you?

I followed your suggestions, here is the result:

# cd /usr/src/php-4.3.0/
# rm config.cache 
# make clean
find . -name \*.lo -o -name \*.o | xargs rm -f
find . -name \*.la -o -name \*.a | xargs rm -f 
find . -name \*.so | xargs rm -f
find . -name .libs -a -type d|xargs rm -rf
rm -f libphp4.la sapi/cli/php libphp4.la modules/* libs/*
# ./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt  
[...]
Configuring extensions
[...]
checking for mcrypt support... yes
checking for mcrypt_module_open in -lmcrypt... no
checking for init_mcrypt in -lmcrypt... yes

# make
gcc  -Iext/ctype/ -I/usr/src/php-4.3.0/ext/ctype/ -DPHP_ATOM_INC
-I/usr/src/php-4.3.0/include -I/usr/src/php-4.3.0/main
-I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend -I/usr/local/include
-I/usr/src/php-4.3.0/ext/xml/expat  -I/usr/src/php-4.3.0/TSRM  -g -O2 
-c /usr/src/php-4.3.0/ext/ctype/ctype.c -o ext/ctype/ctype.o  && echo >
ext/ctype/ctype.lo
cc1: warning: changing search order for system directory
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system
directory
gcc  -Iext/mcrypt/ -I/usr/src/php-4.3.0/ext/mcrypt/ -DPHP_ATOM_INC
-I/usr/src/php-4.3.0/include -I/usr/src/php-4.3.0/main
-I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend -I/usr/local/include
-I/usr/src/php-4.3.0/ext/xml/expat  -I/usr/src/php-4.3.0/TSRM  -g -O2 
-c /usr/src/php-4.3.0/ext/mcrypt/mcrypt.c -o ext/mcrypt/mcrypt.o  &&
echo > ext/mcrypt/mcrypt.lo
cc1: warning: changing search order for system directory
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system
directory
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:229:1: warning: "MCRYPT_FAILED"
redefined
In file included from /usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:34:
/usr/local/include/mcrypt.h:31:1: warning: this is the location of the
previous definition
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c: In function
`zm_startup_mcrypt':
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:279: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:280: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: `MCRYPT_BLOWFISH_128'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: (Each undeclared identifier
is reported only once
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: for each function it
appears in.)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:282: `MCRYPT_BLOWFISH_192'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:283: `MCRYPT_BLOWFISH_256'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:284: `MCRYPT_BLOWFISH_448'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:285: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:286: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:287: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:288: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:289: `MCRYPT_IDEA' undeclared
(first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:290: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:291: warning: pas

#13472 [Com]: input type=hidden should be in a fieldset if there is one (XHTML and trans sid)

2003-02-05 Thread xanthor

 ID:   13472
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Session related
 Operating System: Any
 PHP Version:  4.3.0
 New Comment:

And if we can't access php.ini ?


Previous Comments:


[2003-02-05 16:00:29] [EMAIL PROTECTED]

The adding of the hidden input field can now be turned
off by just removing the 'form=' entry from url_rewriter.tags





[2003-01-12 15:38:08] [EMAIL PROTECTED]

Opened again.



[2003-01-08 19:07:11] [EMAIL PROTECTED]

so could anybody reopen this bug...
or create a new one?



[2003-01-08 17:07:06] [EMAIL PROTECTED]

It looks like they fixed the openness of input tags, i.e. - the tags
close like  rather than  but the hidden input field is
still automatically inserted *outside* of a block-level element.

It's a mistake to automatically force the hidden input field on us to
begin with.  Is there a way to turn JUST that part of the trans-id
off?

This bug is still very much a problem in 4.3



[2003-01-05 19:10:09] [EMAIL PROTECTED]

is this really fixed?

i have php 4.3 and php add the input tag directly after the form tag!

the only _fix_ i found is a comment  in the php.ini

; to URLs.  If you want XHTML conformity, remove the form entry.



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

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

#7253 [Com]: URL rewriter causing problems

2003-02-05 Thread xanthor

 ID:   7253
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: *Session related
 Operating System: RH Linux 6.2 kernel 2.2.16
 PHP Version:  4.0.3pl1
 New Comment:

The bug exists also with hyperlinks tag

For exemple :
If I write :





I obtain :

#19817 [Fbk->Opn]: ImageCreateFromGD2() doesnt recognize uncompressed .gd2 images

2003-02-05 Thread sprice

 ID:   19817
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Darwin 6.1 (Mac 10.2.1)
 PHP Version:  4CVS-2002-10-08
 New Comment:

Nope, it still dosen't work with either compressed or uncompressed
images. I am using GD 2.0.11 to produce the GD2 images. You guys should
sync up with the current GD so I can try using it, instead.


Previous Comments:


[2003-02-05 10:58:23] [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





[2002-10-29 21:40:12] [EMAIL PROTECTED]

This is more of a feature request.  As far as I know nobody is working
on it.  I certainly don't need this functionality.  Feel free to submit
a patch.



[2002-10-29 21:38:19] [EMAIL PROTECTED]

Problem still exists using latest CVS snap and GD 2.0.4. (I thought I
would mention it 'cause I have seen lots of GD work being done in
both.)



[2002-10-19 21:06:21] [EMAIL PROTECTED]

FYI: this bug still exists in the latest CVS snapshot.



[2002-10-11 06:15:54] [EMAIL PROTECTED]

Did test http://144.92.10.251/riverdata/images/uncompressed_med.gd2 and
got the following:

$ php 19817.php
Error from seek: 25

Warning: imagecreatefromgd2part()
[http://www.php.net/function.imagecreatefromgd2part]:
'uncompressed_med.gd2' is not a valid GD2 file in
/home/mfischer/src/php/bugs/gd/19817.php on line 7
/home/mfischer/src/php/bugs/gd/19817.php(7) : Warning -
imagecreatefromgd2part()
[http://www.php.net/function.imagecreatefromgd2part]:
'uncompressed_med.gd2' is not a valid GD2 file

Warning: imagecopy(): supplied argument is not a valid Image resource
in /home/mfischer/src/php/bugs/gd/19817.php on line 10
/home/mfischer/src/php/bugs/gd/19817.php(10) : Warning - imagecopy():
supplied argument is not a valid Image resource

Warning: imagedestroy(): supplied argument is not a valid Image
resource in /home/mfischer/src/php/bugs/gd/19817.php on line 11
/home/mfischer/src/php/bugs/gd/19817.php(11) : Warning -
imagedestroy(): supplied argument is not a valid Image resource
PNG

IHDR vpkIDATxí×1 À°Ïà¢$ [binary scumm]


The interesting thing I think is "Error from seek: 25" which actually
comes from the bundled libgd from libgd/gd_gd2.c from
gdImageCreateFromGd2PartCtx, line 584:

  if (gdSeek (in, dpos) != 0)
{
  printf ("Error from seek: %d\n", errno);
  goto fail2;
};


Error code 25 means "Inappropriate ioctl for device", no idea why this
happens though.

Maybe a problem related from mixing PHP Streams and native access to
FILE fd's ?



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

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

#21880 [Csd->Bgs]: socket_read does not stop at line breaks

2003-02-05 Thread pollita

 ID:   21880
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Bogus
 Bug Type: Sockets related
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

Not Bug => Bogus.

Just dots the 'i's and crosses the 't's for statistics...


Previous Comments:


[2003-02-05 17:14:25] [EMAIL PROTECTED]

Well then, allow me to take my foot out of my mouthI have been
unable to recreate this error now, using the exact same script as I had
before (the one that didnt work) now works.

Thanks...and sorry for the confusion.



[2003-02-05 13:29:46] [EMAIL PROTECTED]

I've attempted to recreate this error under linux, win32, and irix and
have gotten expected results each time. (socket_read returns after
receiving a \n)

Can you provide a full and complete script which exhibits this
behavior?  ((As short and simple as possible while still reliably
reproducing the bug))



[2003-01-25 18:30:24] [EMAIL PROTECTED]

I followed the instructions on all the manuals and tried searching the
inet, but couldent find anything that solved this.

I have a socket that is supposed to read from a client (this is a smtpd
server-type script)..

When I use 

while ($line = socket_read($my_socket,2048,PHP_NORMAL_READ)) {

stuff
}

I can connect to this server via win32 putty, and it will break on line
breaks. But when using Linux telnet and trying to get other smtpd's to
send to it, they would have to send 2048 bytes to get stuff to execute
once.

To make sure they were sending \r or \n I made the socket read go byte
by byte and assemble a string, checking for \n or \r

 while($tstr = socket_read($connection,1)) {

 if (($tstr != chr(13)) && ($tstr != chr(10)))
{
 $buf .= $tstr;
  continue;
 }

^^Example of my byte-by-byte checker

It does find \r and \n in the strings and I am able to gte my server to
work...

Would be nice if the built in function socket_read would really break
on \n or \r.

If more information is needed, please ask




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

#21895 [Com]: implicit_flush and flush() not working proplerly with CLI SAPI

2003-02-05 Thread sthomas

 ID:   21895
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Output Control
 Operating System: FreeBSD 4.7
 PHP Version:  4.3.0
 New Comment:

I think the key is this:

implicit_flush => On => Off

Is there a double internal pointer to this setting or something?  No
amount of setting implicit_flush will
make both of them true.

This script does not output as you'd expect:



This should output a period every second on the CLI, but does not. 
Even putting a call to flush() in the while loop does nothing.  I was
able to get this to work by using ob_flush() oddly enough.

So essentially, flushing is completely broken unless you use ob_flush.


Previous Comments:


[2003-01-27 01:12:59] [EMAIL PROTECTED]

Basically it just seems to not be working at all on my system...however
when initiating "php -i" I get:

implicit_flush => On => Off

my configure line was: ./configure --with-mysql --enable-ftp
--with-apxs=/usr/local/apache/bin/apxs


Here is the script, which doesn't output ANYTHING until the script
ends...it is then all flushed out at once...the warning messages come
out as the script executes, but not the echo's or print()'s







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

#19918 [Com]: no libphp4.so produced

2003-02-05 Thread kbrott

 ID:   19918
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Compile Failure
 Operating System: HP-UX 11.00
 PHP Version:  4.3.0
 New Comment:

Reproduced bug on patched-to-current HP-UX 11.00 system trying to 
build php-4.3.0 against apache httpd 2.0.43 (as well as the 
php-200301290030.tar.gz snapshot).

Have determined cause and offer working solution (well - it worked on 
my systems anyway).

Here's the config.nice that I used for this instance:
#! /bin/sh
#
# Created by configure

CFLAGS='-O3' \
LDFLAGS='-L/opt/admin/lib -L/opt/tools/lib' \
CC='gcc' \
'./configure' \
'--prefix=/opt/php4' \
'--with-apxs2=/opt/apache/sbin/apxs' \
'--enable-shared' \
'--enable-force-cgi-redirect' \
'--with-openssl=/opt/tools' \
'--with-zlib=/opt/tools' \
'--enable-bcmath' \
'--with-bz2=/opt/tools' \
'--enable-calendar' \
'--enable-dba' \
'--with-gdbm=/opt/tools' \
'--with-db3=/opt/tools' \
'--with-flatfile' \
'--enable-dbase' \
'--enable-dbx' \
'--enable-ftp' \
'--with-gmp=/opt/tools' \
'--with-mysql=/opt/mysql' \
'--enable-mime-magic' \
'--with-ldap=/opt/tools' \
'--enable-mbstring' \
'--enable-mbregex' \
'--with-readline=/opt/tools' \
"$@" 

HP's linker via libtool (apache2 or otherwise) cannot seem to use a 
lib(anything).a to make a shared library file (at least not in this 
instance - I gave up on it after a couple of months) - so the trick is

to make sure not to call any static libraries.

HP moved all of the shared crpyt functions into libc ( as of HP-UX 
10.20 see 

).
So all calls in ./configure for HP-UX 11.00 should use -lc instead of 
-lcrypt for the crypt_r/ calls (tested - it works).

HP has completely deprecated termcap usage ( see 
, 
, and more 
specifically

)
so you have to use libcurses instead if you want to access a shared 
library with those functions.  So all calls in ./configure when 
OS=hpux11 should use -lcurses instead of -ltermcap for the tgetent 
calls (tested - it works).

Making these changes to ./configure, executing ./config.nice, then 
doing make, make install allowed compilation and installation with 
no problems (well, once I rebuilt bzip2 with a shared libbz2 that is).

Feel free to ping me with questions - I have a working php 4.3.0
install running on HP-UX 11.00 as a shared install under apache 2.0.43
now so I must have done something right. :)


Previous Comments:


[2003-02-05 11:54:39] [EMAIL PROTECTED]

oups ! it was with-apxs2 and not with-apxs...



[2003-02-05 11:29:07] [EMAIL PROTECTED]

OS : HP-UX11.00 (32 bits)
gcc 2.95.2
PHP 4.3.0.
apache 2.0.44

php config :
./configure --with-apxs=/home/apache2/bin/apxs
--without-mysql
--enable-track-vars
make
I have crypt warning about share libs !!
Then I changed the Make file and removed -lcrypt
make
--> OK no more warning
make install
--> OK
apachectl start 
--> no errors
I started then it works, (I got the phpinfo page),
What the lib crypt is made for ??? what functions are using it ?



[2003-01-22 12:44:34] [EMAIL PROTECTED]

i have the same probleme with PHP 4.3 + SAPI NSAPI on HP-UX 11!

/bin/sh libtool --silent --mode=link gcc -g -O2 -DZTS -prefer-pic 
-rpath /opt/php43/php-4.3.0/libs -avoid-version -module -L/usr/lo
cal/lib -L/opt/bzip2/lib -L/opt/jpeg-6/lib -L/opt/libpng/lib
-L/opt/xpm/lib -L/opt/freetype/lib -L/opt/T1/lib -L/opt/gd/lib  -R
/usr
/local/lib -R /opt/bzip2/lib -R /opt/jpeg-6/lib -R /opt/libpng/lib -R
/opt/xpm/lib -R /opt/freetype/lib -R /opt/T1/lib -R /opt/gd/li
b ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/bz2/bz2.lo
ext/ctype/ctype.lo ext/gd/gd.lo ext/gd/gdttf.lo ext/gd/gdcache.lo e
xt/overload/overload.lo ext/pcre/pcrelib/maketables.lo
ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo
ext/pcre/pcrelib/pcre.lo ex
t/pcre/php_pcre.lo ext/session/session.lo ext/session/mod_files.lo
ext/session/mod_mm.lo ext/session/mod_user.lo ext/standard/array.
lo ext/standard/base64.lo ext/standard/basic_functions.lo
ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo
ext/s
tandard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo
ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/
standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo
ext/standard/formatted_print.lo ext/standard/fsock.lo ext/sta
ndard/head.lo ext/standard/html.lo ext/standard/image.lo
ext/standard/info.lo ext/s

#22084 [NEW]: Content-Type: text/css, broaken bigtime in new versions of PHP

2003-02-05 Thread tlb

From: [EMAIL PROTECTED]
Operating system: Linux Mandrake 9.0
PHP version:  4.2.3
PHP Bug Type: Apache related
Bug description:  Content-Type: text/css, broaken bigtime in new versions of PHP

As written in the RFC this "Content-Type: text/css" should be interpreted
as
"Content-Type: text/css; charset=ISO-8859-1" by 
any HTTP 1.0/1.1 software, but it's not by newer version of php and it's
changed to "Content-Type: text/html; charset=" and that's plain wrong, the
one provided to Apache is even more broaken, "Content-Type: text/html;
charset=iso-8859-15" there by breaking
support for standard compliant Mozilla/Netscape 7.0 and making any CSS
used by non functional.


http://www.jorendorff.com/articles/unicode/unicode-http.html

and

ftp://ftp.isi.edu/in-notes/rfc2616.txt

3.4.1 Missing Charset

   Some HTTP/1.0 software has interpreted a Content-Type header without
   charset parameter incorrectly to mean "recipient should guess."
   Senders wishing to defeat this behavior MAY include a charset
   parameter even when the charset is ISO-8859-1 and SHOULD do so when
   it is known that it will not confuse the recipient.

   Unfortunately, some older HTTP/1.0 clients did not deal properly with
   an explicit charset parameter. HTTP/1.1 recipients MUST respect the
   charset label provided by the sender; and those user agents that have
   a provision to "guess" a charset MUST use the charset from the

and

test.php:


[tlb@tlb tlb]$ wget -O - -d http://tlb.rapanden.dk/test.php
DEBUG output created by Wget 1.8.2 on linux-gnu.

--00:14:54--  http://tlb.rapanden.dk/test.php
   => `-'
Resolving tlb.rapanden.dk... done.
Caching tlb.rapanden.dk => 195.249.214.150
Connecting to tlb.rapanden.dk[195.249.214.150]:80... connected.
Created socket 3.
Releasing 0x80830e8 (new refcount 1).
---request begin---
GET /test.php HTTP/1.0
User-Agent: Wget/1.8.2
Host: tlb.rapanden.dk
Accept: */*
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response... HTTP/1.1 200 OK
Date: Wed, 05 Feb 2003 23:13:26 GMT
Server: Apache-AdvancedExtranetServer/1.3.26 (Mandrake Linux/6.1mdk)
PHP/4.2.3
Vary: Host
X-Powered-By: PHP/4.2.3
Connection: close
Content-Type: text/html; charset=iso-8859-15
Length: unspecified [text/html]
-- 
Edit bug report at http://bugs.php.net/?id=22084&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22084&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22084&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22084&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22084&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22084&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22084&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22084&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22084&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22084&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22084&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22084&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22084&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22084&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22084&r=gnused

#22079 [Opn->Csd]: logging warnings causes header() to fail

2003-02-05 Thread zlo

 ID:   22079
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Output Control
 Operating System: RedHat 7.2
 PHP Version:  4CVS-2003-02-05 (stable)
 New Comment:

I have an idea why that might be the case.
By default, errors/warnings/notices are logged to stderr.
When run from console, it is displayed. PHP therefore considers it
"output", produces headers and the subsequent attempts to use header()
fail.
When used in such cgi mode, stderr is redirected to apache's error_log,
but PHP does not suspect that and behaves as if the first NOTICE was
sent to the output.

directing PHP's error_log to a file from php.ini solves this problem.


Previous Comments:


[2003-02-05 16:25:52] [EMAIL PROTECTED]

>This isn't the source of 'problem.php'
But it is! the messages and source code are exactly that!
http://docs.ndg.ru/p1.php
this one works as intended (in all versions) - redirects to ok.php

this one fails in cgi versions and produces those error messages in
error_log:
http://docs.ndg.ru/p2.php


also, see the http "conversation":

GET /p1.php HTTP/1.1
HOST: docs.ndg.ru

HTTP/1.1 302
Date: Wed, 05 Feb 2003 22:05:10 GMT
Server: Apache/1.3.27 (Unix) PHP/4.3.0
X-Powered-By: PHP/4.3.1-dev
Location: ok.php
Transfer-Encoding: chunked
Content-Type: text/html; charset=windows-1251

2
hi
0

GET /p2.php HTTP/1.1
HOST: docs.ndg.ru

HTTP/1.1 200 OK
Date: Wed, 05 Feb 2003 22:05:39 GMT
Server: Apache/1.3.27 (Unix) PHP/4.3.0
X-Powered-By: PHP/4.3.1-dev
Transfer-Encoding: chunked
Content-Type: text/html; charset=windows-1251

2
hi
0

==
my point is, regardless of whether outputting anything after
header('Location: xxx') is correct or not (in fact if i comment out the
last line, the behaviour is exactly the same), this effect is IMHO
undesired and illogical.



[2003-02-05 15:40:20] [EMAIL PROTECTED]

This isn't the source of 'problem.php' as the 'header already sent'
points to line 3, which is the header command itself. It never points
to the header line itself.

Please include post script, so that the correct line is reported.

Also -> this is bound to fail, as line 4 outputs stuff. The header
function != redirect. You should call exit after after the header
command.

I'm leaving this open, since user reports it works in the module
version.



[2003-02-05 12:30:00] [EMAIL PROTECTED]

What i am trying to do: send headers
What happens: headers don't get sent under the excuse that "output
already started" if any messages have been logged by error_reporting,
although no output has been sent to the browser. (logging goes to
error_log) If i disable reporting E_NOTICE or logging, problem
disappears.

this happens under php 4.3.0 and the fresh snapshot from Feb 5, when
used in cgi mode in the following ways:
Action php-script /php4/php
-or-
#!/usr/bin/php
it DOES NOT happen under mod_php 4.3.0

code that exhibits the problem:
(i expect to get redirected to ok.php but i see hi instead)
if i remove the errorneous line that causes warnings, it works as
intended.


error_log:
PHP Notice:  Undefined variable:  na in /www/mysite/htdocs/problem.php
on line 2
PHP Warning:  Cannot modify header information - headers already sent
in /www/mysite/htdocs/problem.php on line 3

configure options:
./configure \
--with-config-file-path=/svr/php-cgi \
--prefix=/svr/php-cgi \
--enable-force-cgi-redirect \
--disable-cli \
--enable-bcmath \
--enable-trans-sid \
--with-zlib-dir=/build/zlib-1.1.4 \
--with-gd=/build/gd-1.8.4 \
--with-png-dir=/build/png-1.2.4 \
--with-jpeg-dir=/build/jpeg-6b \
--with-freetype \
--with-mysql=/usr/local \
--with-gettext \
--with-imap \
--with-imap-ssl \
--with-kerberos \

php.ini, relevant options:
error_reporting E_ALL
output_buffering On
log_errors on
display_errors off





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

#21880 [Fbk->Csd]: socket_read does not stop at line breaks

2003-02-05 Thread talmage

 ID:   21880
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Closed
 Bug Type: Sockets related
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

Well then, allow me to take my foot out of my mouthI have been
unable to recreate this error now, using the exact same script as I had
before (the one that didnt work) now works.

Thanks...and sorry for the confusion.


Previous Comments:


[2003-02-05 13:29:46] [EMAIL PROTECTED]

I've attempted to recreate this error under linux, win32, and irix and
have gotten expected results each time. (socket_read returns after
receiving a \n)

Can you provide a full and complete script which exhibits this
behavior?  ((As short and simple as possible while still reliably
reproducing the bug))



[2003-01-25 18:30:24] [EMAIL PROTECTED]

I followed the instructions on all the manuals and tried searching the
inet, but couldent find anything that solved this.

I have a socket that is supposed to read from a client (this is a smtpd
server-type script)..

When I use 

while ($line = socket_read($my_socket,2048,PHP_NORMAL_READ)) {

stuff
}

I can connect to this server via win32 putty, and it will break on line
breaks. But when using Linux telnet and trying to get other smtpd's to
send to it, they would have to send 2048 bytes to get stuff to execute
once.

To make sure they were sending \r or \n I made the socket read go byte
by byte and assemble a string, checking for \n or \r

 while($tstr = socket_read($connection,1)) {

 if (($tstr != chr(13)) && ($tstr != chr(10)))
{
 $buf .= $tstr;
  continue;
 }

^^Example of my byte-by-byte checker

It does find \r and \n in the strings and I am able to gte my server to
work...

Would be nice if the built in function socket_read would really break
on \n or \r.

If more information is needed, please ask




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

#22076 [Fbk->Opn]: PHP 4.3.0 crashes on OpenBSD 3.2 sparc64 when zlib is linked

 ID:   22076
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: OpenBSD 3.2 SPARC64
 PHP Version:  4.3.0
 New Comment:

[root@sparc64 php-4.3.0]# cat config.nice 
#! /bin/sh
#
# Created by configure

'./configure' \
'--with-zlib' \
'--enable-debug' \
"$@"

[root@sparc64 php-4.3.0]# l /usr/lib/libz*
-r--r--r--  1 root  bin  83270 Oct  3 20:28 /usr/lib/libz.a
-r--r--r--  1 root  bin  67266 Oct  3 20:28 /usr/lib/libz.so.1.4
-r--r--r--  1 root  bin  91040 Oct  3 20:28 /usr/lib/libz_p.a
-r--r--r--  1 root  bin  82904 Oct  3 20:28 /usr/lib/libz_pic.a

I also downloaded zlib 1.1.4 and compiled it myself with the same
results.


Previous Comments:


[2003-02-05 16:17:09] [EMAIL PROTECTED]

What's the zlib version on this box and could you cat/paste
config.nice?



[2003-02-05 13:47:24] [EMAIL PROTECTED]

vi a.c
int main()
{
char *a, *b;
a = 0;
b = 0;
strcpy(a, b);

return 0;
}

[root@sparc64 root]# gcc -o a a.c -g

[root@sparc64 root]# ./a
Segmentation fault (core dumped)

[root@sparc64 root]# gdb -c a.core a
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "sparc64-unknown-openbsd3.2"...
Core was generated by `a'.
Program terminated with signal 11, Segmentation fault.
#0  0x403855b0 in ?? ()
(gdb) bt
#0  0x403855b0 in ?? ()
#1  0x1004dc in ___start ()
(gdb) 

Seems to work...

I used OpenBSD's 3.2 native compiler and debugger.

[root@sparc64 root]# gcc -v
Reading specs from
/usr/lib/gcc-lib/sparc64-unknown-openbsd3.2/2.95.3/specs
gcc version 2.95.3 20010125 (prerelease)

[root@sparc64 root]# gdb -v
GNU gdb 4.16.1



[2003-02-05 13:34:13] [EMAIL PROTECTED]

Looks like something is wrong with your gdb.. I had the 
same problem (gdb coredumping on me), but on Tru64.. 
It went away when I compiled gdb with Compaq's native C 
compiler.. 



[2003-02-05 13:04:28] [EMAIL PROTECTED]

./configure --with-zlib --enable-debug


[root@sparc64 php-4.3.0]# ./sapi/cgi/php
Bus error (core dumped)

[root@sparc64 php-4.3.0]# gdb -c php.core ./sapi/cgi/php
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "sparc64-unknown-openbsd3.2"...
Core was generated by `php'.
Program terminated with signal 10, Bus error.

Dwarf Error: Cannot find referent at offset 507.
(gdb) bt
Segmentation fault (core dumped)


Sorry, that is as good as it gets from a backtrace. I have done this on
two different boxes (U5 & U10) with the same results.



[2003-02-05 12:24:15] [EMAIL PROTECTED]

Can you please compile with --enable-debug, crash the program and then
give us the backtrace? :)



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

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

#22079 [Fbk->Opn]: logging warnings causes header() to fail

2003-02-05 Thread zlo

 ID:   22079
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Output Control
 Operating System: RedHat 7.2
 PHP Version:  4CVS-2003-02-05 (stable)
 New Comment:

>This isn't the source of 'problem.php'
But it is! the messages and source code are exactly that!
http://docs.ndg.ru/p1.php
this one works as intended (in all versions) - redirects to ok.php

this one fails in cgi versions and produces those error messages in
error_log:
http://docs.ndg.ru/p2.php


also, see the http "conversation":

GET /p1.php HTTP/1.1
HOST: docs.ndg.ru

HTTP/1.1 302
Date: Wed, 05 Feb 2003 22:05:10 GMT
Server: Apache/1.3.27 (Unix) PHP/4.3.0
X-Powered-By: PHP/4.3.1-dev
Location: ok.php
Transfer-Encoding: chunked
Content-Type: text/html; charset=windows-1251

2
hi
0

GET /p2.php HTTP/1.1
HOST: docs.ndg.ru

HTTP/1.1 200 OK
Date: Wed, 05 Feb 2003 22:05:39 GMT
Server: Apache/1.3.27 (Unix) PHP/4.3.0
X-Powered-By: PHP/4.3.1-dev
Transfer-Encoding: chunked
Content-Type: text/html; charset=windows-1251

2
hi
0

==
my point is, regardless of whether outputting anything after
header('Location: xxx') is correct or not (in fact if i comment out the
last line, the behaviour is exactly the same), this effect is IMHO
undesired and illogical.


Previous Comments:


[2003-02-05 15:40:20] [EMAIL PROTECTED]

This isn't the source of 'problem.php' as the 'header already sent'
points to line 3, which is the header command itself. It never points
to the header line itself.

Please include post script, so that the correct line is reported.

Also -> this is bound to fail, as line 4 outputs stuff. The header
function != redirect. You should call exit after after the header
command.

I'm leaving this open, since user reports it works in the module
version.



[2003-02-05 12:30:00] [EMAIL PROTECTED]

What i am trying to do: send headers
What happens: headers don't get sent under the excuse that "output
already started" if any messages have been logged by error_reporting,
although no output has been sent to the browser. (logging goes to
error_log) If i disable reporting E_NOTICE or logging, problem
disappears.

this happens under php 4.3.0 and the fresh snapshot from Feb 5, when
used in cgi mode in the following ways:
Action php-script /php4/php
-or-
#!/usr/bin/php
it DOES NOT happen under mod_php 4.3.0

code that exhibits the problem:
(i expect to get redirected to ok.php but i see hi instead)
if i remove the errorneous line that causes warnings, it works as
intended.


error_log:
PHP Notice:  Undefined variable:  na in /www/mysite/htdocs/problem.php
on line 2
PHP Warning:  Cannot modify header information - headers already sent
in /www/mysite/htdocs/problem.php on line 3

configure options:
./configure \
--with-config-file-path=/svr/php-cgi \
--prefix=/svr/php-cgi \
--enable-force-cgi-redirect \
--disable-cli \
--enable-bcmath \
--enable-trans-sid \
--with-zlib-dir=/build/zlib-1.1.4 \
--with-gd=/build/gd-1.8.4 \
--with-png-dir=/build/png-1.2.4 \
--with-jpeg-dir=/build/jpeg-6b \
--with-freetype \
--with-mysql=/usr/local \
--with-gettext \
--with-imap \
--with-imap-ssl \
--with-kerberos \

php.ini, relevant options:
error_reporting E_ALL
output_buffering On
log_errors on
display_errors off





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

#21713 [Com]: include (URL) doesn't remove temporary files

2003-02-05 Thread sfox

 ID:   21713
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Assigned
 Bug Type: *Directory/Filesystem functions
 Operating System: Solaris 8
 PHP Version:  4.3.0
 Assigned To:  wez
 New Comment:

I've run into this as well since upgrading from 4.2.1 to 4.3 under
Solaris 8/Apache.

It only happens when an include is processed that refers to a file that
does NOT exist.  Every time this happens a file named php is left
behind in /var/tmp using up a file handle.

2 errors are logged.  For example:

[error] PHP Warning:  main(left_menu.php) [function.main]: failed to create
stream: No such file or directory in...

[error] PHP Warning:  main() [function.main]: Failed opening 'left_menu.php'
for inclusion (include_path='.:/home/www/code') in..


Previous Comments:


[2003-01-17 19:29:12] [EMAIL PROTECTED]

Let's keep this one open until I verify it; I have reason to believe
that this is a valid problem.



[2003-01-17 19:27:43] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.



[2003-01-17 12:47:23] [EMAIL PROTECTED]

include("URL") doesn't remove temporary files in /var/tmp

PHP creates /var/tmp/php?? files until...

ufs: [ID 682040 kern.notice] NOTICE: /var: out of inodes




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

#22076 [Opn->Fbk]: PHP 4.3.0 crashes on OpenBSD 3.2 sparc64 when zlib is linked

2003-02-05 Thread msopacua

 ID:   22076
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: OpenBSD 3.2 SPARC64
 PHP Version:  4.3.0
 New Comment:

What's the zlib version on this box and could you cat/paste
config.nice?


Previous Comments:


[2003-02-05 13:47:24] [EMAIL PROTECTED]

vi a.c
int main()
{
char *a, *b;
a = 0;
b = 0;
strcpy(a, b);

return 0;
}

[root@sparc64 root]# gcc -o a a.c -g

[root@sparc64 root]# ./a
Segmentation fault (core dumped)

[root@sparc64 root]# gdb -c a.core a
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "sparc64-unknown-openbsd3.2"...
Core was generated by `a'.
Program terminated with signal 11, Segmentation fault.
#0  0x403855b0 in ?? ()
(gdb) bt
#0  0x403855b0 in ?? ()
#1  0x1004dc in ___start ()
(gdb) 

Seems to work...

I used OpenBSD's 3.2 native compiler and debugger.

[root@sparc64 root]# gcc -v
Reading specs from
/usr/lib/gcc-lib/sparc64-unknown-openbsd3.2/2.95.3/specs
gcc version 2.95.3 20010125 (prerelease)

[root@sparc64 root]# gdb -v
GNU gdb 4.16.1



[2003-02-05 13:34:13] [EMAIL PROTECTED]

Looks like something is wrong with your gdb.. I had the 
same problem (gdb coredumping on me), but on Tru64.. 
It went away when I compiled gdb with Compaq's native C 
compiler.. 



[2003-02-05 13:04:28] [EMAIL PROTECTED]

./configure --with-zlib --enable-debug


[root@sparc64 php-4.3.0]# ./sapi/cgi/php
Bus error (core dumped)

[root@sparc64 php-4.3.0]# gdb -c php.core ./sapi/cgi/php
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "sparc64-unknown-openbsd3.2"...
Core was generated by `php'.
Program terminated with signal 10, Bus error.

Dwarf Error: Cannot find referent at offset 507.
(gdb) bt
Segmentation fault (core dumped)


Sorry, that is as good as it gets from a backtrace. I have done this on
two different boxes (U5 & U10) with the same results.



[2003-02-05 12:24:15] [EMAIL PROTECTED]

Can you please compile with --enable-debug, crash the program and then
give us the backtrace? :)



[2003-02-05 11:29:52] [EMAIL PROTECTED]

I posted the following email on the OpenBSD list and no-one knew of
this. I guess it belongs here.

Email:
I am at a loss trying to get PHP 4.3.0 to work on sparc64 using OpenBSD
3.2-release. I have been messing around with this for quite a bit now
and I can't get the damned thing to work. What I did find out is that
the problems are caused by linking zlib (tried the shipped one and also
the latest source). When I tried to debug the issue gdb bombed on me as
well.

Excerpt:
[root@sparc64 php-4.3.0]# gdb sapi/cgi/php
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are welcome to change it and/or distribute copies of it under
certain conditions. Type "show copying" to see the conditions. There is
absolutely no warranty for GDB.  Type "show warranty" for details. This
GDB was configured as "sparc64-unknown-openbsd3.2"...
(gdb) run
Starting program: /root/php-4.3.0/sapi/cgi/php 
Dwarf Error: Cannot find referent at offset 507.
(gdb) bt
Segmentation fault (core dumped)

Anyone any ideas?

I did get it compiled with other stuff as long as it does not require
zlib. Problem for me is that I need gd functionality which depends on
zlib. I searched the PHP site as well as the archives and google but to
no avail.

dmesg:
OpenBSD 3.2 (GENERIC) #8: Thu Oct  3 20:00:17 MDT 2002
 
[EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC
total memory = 134217728
avail memory = 115785728
using 819 buffers containing 6709248 of memory
bootpath: /pci@1f,0/pci@1,1/ide@3,0/disk@0,0
mainbus0 (root): SUNW,Ultra-5_10
cpu0 at mainbus0: SUNW,UltraSPARC-IIi @ 299.825 MHz, version 0 FPU
cpu0: physical 32K instruction (32 b/l), 16K data (32 b/l), 512K
external (64 b/l

#22018 [Ana->Asn]: daylight savings time parameter works wrong

 ID:   22018
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Analyzed
+Status:   Assigned
 Bug Type: Date/time related
 Operating System: Windows 2000 Server
 PHP Version:  4CVS-2003-02-02 (stable)
 Assigned To:  k.schroeder
 New Comment:

I suppose you meant to assign this to yourself..



Previous Comments:


[2003-02-02 15:27:37] [EMAIL PROTECTED]

ext/standard/tests/time/003.phpt fails on W2k server:

diff:
008- 2000-05-29 13:00:00
008+ 2000-05-29 12:00:00
009- 2000-05-29 12:00:00
009+ 2000-05-29 11:00:00
014- 2000-04-29 13:00:00
014+ 2000-04-29 12:00:00
015- 2000-04-29 12:00:00
015+ 2000-04-29 11:00:00

coresponding lines:
echo date("Y-m-d H:i:s", mktime(12,0,0,3,+90,2000,0))."\n";
echo date("Y-m-d H:i:s", mktime(12,0,0,3,+90,2000,1))."\n";
echo date("Y-m-d H:i:s", mktime(12,0,0,5,-1,2000,0))."\n";
echo date("Y-m-d H:i:s", mktime(12,0,0,5,-1,2000,1))."\n";

this lines produce the expected result:
echo date("Y-m-d H:i:s", mktime(12,0,0,3,+90,2000,-1))."\n";
echo date("Y-m-d H:i:s", mktime(12,0,0,5,-90,2000,-1))."\n";
echo date("Y-m-d H:i:s", mktime(12,0,0,5,-90,2000,0))."\n";
echo date("Y-m-d H:i:s", mktime(12,0,0,5,-90,2000,1))."\n";
echo date("Y-m-d H:i:s", mktime(12,0,0,5,-1,2000,-1))."\n";





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

#20014 [Opn->Asn]: SSL w/ fsockopen not working

 ID:   20014
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Assigned
 Bug Type: Sockets related
 Operating System: windows 2000
 PHP Version:  4CVS-2003-02-05
-Assigned To:  
+Assigned To:  edink
 New Comment:

The 'OpenSSL support => enabled' is a bit misleading
since it just means that the openssl _extension_ is available. But the
main PHP is not linked with the ssl
libs (win32 binaries provided by php.net) so of course
the SSL support is not available...Edin is looking into
this so assigning to him.



Previous Comments:


[2003-02-05 01:07:13] [EMAIL PROTECTED]

This is reproducable with latest php4-win32 snap, latest php4 source
snap works on Linux:

Relevant parts from phpinfo():
Registered PHP Streams => php, http, ftp, compress.zlib
OpenSSL support => enabled
OpenSSL Version => OpenSSL 0.9.6g 9 Aug 2002

test:
--TEST--
Bug #20014 SSL w/ fsockopen not working
--SKIPIF--

--FILE--

--EXPECT--
resource(4) of type (stream)


 EXPECTED OUTPUT
resource(4) of type (stream)
 ACTUAL OUTPUT
Warning: fsockopen() [/phpmanual/function.fsockopen.html]: no SSL
support in this build in D:\work\php4\ext\openssl\tests\bug20014.php on
line 2

Warning: fsockopen() [/phpmanual/function.fsockopen.html]: unable to
connect to www.openssl.org:443 in
D:\work\php4\ext\openssl\tests\bug20014.php on line 2
bool(false)
 FAILED



[2002-10-21 15:24:24] [EMAIL PROTECTED]

Looks like main/config.w32.h.in needs to
#define HAVE_OPENSSL_EXT 1

I'm unable to test this ATM, so I'm hoping that some other kind win32
developer can look into it.



[2002-10-21 15:17:27] [EMAIL PROTECTED]

Environment: W2K/IIS5/php 4.3.0-dev (win32 snapshot 10/21, 7:25), CGI

Reproduce w/:

$fp = fsockopen('ssl://secure.hostname.here',$port);

Error:

"Warning: fsockopen() [function.fsockopen]: no SSL support in this
build in E:\test\fsockopen_ssl.php"

phpinfo() shows OpenSSL is available. I tested the openssl funcs to
confirm availability. All DLLs are copied to system32 dir.




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

#22079 [Opn->Fbk]: logging warnings causes header() to fail

2003-02-05 Thread msopacua

 ID:   22079
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Output Control
 Operating System: RedHat 7.2
 PHP Version:  4CVS-2003-02-05 (stable)


Previous Comments:


[2003-02-05 15:40:20] [EMAIL PROTECTED]

This isn't the source of 'problem.php' as the 'header already sent'
points to line 3, which is the header command itself. It never points
to the header line itself.

Please include post script, so that the correct line is reported.

Also -> this is bound to fail, as line 4 outputs stuff. The header
function != redirect. You should call exit after after the header
command.

I'm leaving this open, since user reports it works in the module
version.



[2003-02-05 12:30:00] [EMAIL PROTECTED]

What i am trying to do: send headers
What happens: headers don't get sent under the excuse that "output
already started" if any messages have been logged by error_reporting,
although no output has been sent to the browser. (logging goes to
error_log) If i disable reporting E_NOTICE or logging, problem
disappears.

this happens under php 4.3.0 and the fresh snapshot from Feb 5, when
used in cgi mode in the following ways:
Action php-script /php4/php
-or-
#!/usr/bin/php
it DOES NOT happen under mod_php 4.3.0

code that exhibits the problem:
(i expect to get redirected to ok.php but i see hi instead)
if i remove the errorneous line that causes warnings, it works as
intended.


error_log:
PHP Notice:  Undefined variable:  na in /www/mysite/htdocs/problem.php
on line 2
PHP Warning:  Cannot modify header information - headers already sent
in /www/mysite/htdocs/problem.php on line 3

configure options:
./configure \
--with-config-file-path=/svr/php-cgi \
--prefix=/svr/php-cgi \
--enable-force-cgi-redirect \
--disable-cli \
--enable-bcmath \
--enable-trans-sid \
--with-zlib-dir=/build/zlib-1.1.4 \
--with-gd=/build/gd-1.8.4 \
--with-png-dir=/build/png-1.2.4 \
--with-jpeg-dir=/build/jpeg-6b \
--with-freetype \
--with-mysql=/usr/local \
--with-gettext \
--with-imap \
--with-imap-ssl \
--with-kerberos \

php.ini, relevant options:
error_reporting E_ALL
output_buffering On
log_errors on
display_errors off





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

#22072 [Opn->Fbk]: connection_status() always returning 0

 ID:   22072
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
-Bug Type: *General Issues
+Bug Type: Apache2 related
 Operating System: FREEBSD 4.7-STABLE
 PHP Version:  4.3.0
 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:


[2003-02-05 15:58:50] [EMAIL PROTECTED]

connection_status() always returns zero on Win32 4.3.0 running IIS.
Yes, ignore_user_abort(true) is set.

Bradley Crockett



[2003-02-05 09:05:27] [EMAIL PROTECTED]

This bug is effecting the connection_status() function in apache 2.x

Okay, getting back to a long standing bug, which we kind of come to the
conclusion last time that it may be a bug in apache 2.x because it
works in apache 1.

Well time has come on, I have submitted the bug to apache after they
fixed the incorrect bytes logged bug, and this is what they have come
up with :-

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16426

ok, I've grabbed the current php source and looked into sapi_apache2.c.
It's
definitely a php bug. Line 90 shows:

if (ap_pass_brigade(f->next, bb) != APR_SUCCESS) {
php_handle_aborted_connection();
}

which won't match in most cases. Also Line 252 and 498.
AFAICS mod_php should (additionally) check connection->aborted.

(marking this bug invalid again)





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

#22070 [Ver->Csd]: trans_id: Hidden fields placed incorrectly

 ID:   22070
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Verified
+Status:   Closed
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

You can disable the adding of the hidden field by
removing 'form=' from url_rewriter.tags



Previous Comments:


[2003-02-05 09:16:05] [EMAIL PROTECTED]

Output from http://validator.w3.org: 
Line 7, column 115: document type does not allow element 
"input" here; missing one of "ins", "del", "h1", "h2", 
"h3", "h4", "h5", "h6", "p", "div", "address", "fieldset" 
start-tag 
 
  ...="f78cfab3aa4745920992c99cabedc75f" /> 
  ^ 



[2003-02-05 08:33:42] [EMAIL PROTECTED]

When using session.use_trans_sid, a hidden input field containing the
session name and ID is placed right after the  tag. Unfortually,
this makes the HTML invalid if you're using XHTML 1.1, strict XHTML
1.0, or strict HTML 4.0: All input fields (even hidden ones) must be
placed inside a block-level element such as  or .

The solution: When the parser discovers a form on the page, it should
place the hidden field containing the session name + ID right next to
one of the other input fields:

The original page:


  

  


After being processed by the parser:


  

  





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

#13472 [Opn->Csd]: input type=hidden should be in a fieldset if there is one (XHTML and trans sid)

 ID:   13472
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Session related
 Operating System: Any
 PHP Version:  4.3.0
 New Comment:

The adding of the hidden input field can now be turned
off by just removing the 'form=' entry from url_rewriter.tags




Previous Comments:


[2003-01-12 15:38:08] [EMAIL PROTECTED]

Opened again.



[2003-01-08 19:07:11] [EMAIL PROTECTED]

so could anybody reopen this bug...
or create a new one?



[2003-01-08 17:07:06] [EMAIL PROTECTED]

It looks like they fixed the openness of input tags, i.e. - the tags
close like  rather than  but the hidden input field is
still automatically inserted *outside* of a block-level element.

It's a mistake to automatically force the hidden input field on us to
begin with.  Is there a way to turn JUST that part of the trans-id
off?

This bug is still very much a problem in 4.3



[2003-01-05 19:10:09] [EMAIL PROTECTED]

is this really fixed?

i have php 4.3 and php add the input tag directly after the form tag!

the only _fix_ i found is a comment  in the php.ini

; to URLs.  If you want XHTML conformity, remove the form entry.



[2002-12-03 23:00:43] [EMAIL PROTECTED]

to: [EMAIL PROTECTED]

is this bug fixed entirely? re:

[3 Mar 8:08am] [EMAIL PROTECTED]
Notice .. any blocklevel tag is affected .. not just fieldset and as
such any solution to this problem should take this issue into account.



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

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

#22072 [Com]: connection_status() always returning 0

2003-02-05 Thread crockett

 ID:   22072
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: *General Issues
 Operating System: FREEBSD 4.7-STABLE
 PHP Version:  4.3.0
 New Comment:

connection_status() always returns zero on Win32 4.3.0 running IIS.
Yes, ignore_user_abort(true) is set.

Bradley Crockett


Previous Comments:


[2003-02-05 09:05:27] [EMAIL PROTECTED]

This bug is effecting the connection_status() function in apache 2.x

Okay, getting back to a long standing bug, which we kind of come to the
conclusion last time that it may be a bug in apache 2.x because it
works in apache 1.

Well time has come on, I have submitted the bug to apache after they
fixed the incorrect bytes logged bug, and this is what they have come
up with :-

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16426

ok, I've grabbed the current php source and looked into sapi_apache2.c.
It's
definitely a php bug. Line 90 shows:

if (ap_pass_brigade(f->next, bb) != APR_SUCCESS) {
php_handle_aborted_connection();
}

which won't match in most cases. Also Line 252 and 498.
AFAICS mod_php should (additionally) check connection->aborted.

(marking this bug invalid again)





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

#22083 [NEW]: php-cli MySQL charset problem

2003-02-05 Thread spam

From: [EMAIL PROTECTED]
Operating system: Windows
PHP version:  4.3.0
PHP Bug Type: MySQL related
Bug description:  php-cli MySQL charset problem

When I set default-character-set=win1250 in my.ini, php-cli says:

File 'c:\mysql\\share\charsets\?.conf' not found (Errcode: 2)
Character set '#26' is not a compiled character set and is not specified
in the 'c:\mysql\\share\charsets\Index' file

The problem is, that php-cli ignores character-sets-dir= in my.ini and
uses its own hard-coded path c:\mysql\. If I move the share\charsets\
directory into c:\mysql\, the problem is still here because there are two
backslashes in path, where php-cli tries to find it.

When I hexa edited php4ts.dll and change c:/mysql/ to c:/mysql3 and move
share\charsets\ directory there, everything is working.

Solution:
1. Change the default path for finding charsets from "c:/mysql/" to
"c:/mysql"
2. If possible, read character-sets-dir= from C:\Windows\my.ini.

-- 
Edit bug report at http://bugs.php.net/?id=22083&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22083&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22083&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22083&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22083&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22083&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22083&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22083&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22083&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22083&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22083&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22083&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22083&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22083&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22083&r=gnused

#22052 [Opn]: Ftp ftp_rawlist,ftp_nlist broken

2003-02-05 Thread ntrujillo

 ID:   22052
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: FreeBSD 5.0-RELEASE #0
 PHP Version:  4.3.1-dev
 New Comment:

this is broken with following configurations:

FreeBSD 5 RELEASE 0# php-4.2.3(release)
FreeBSD 5 RELEASE 0# php-4.3.0(release)
FreeBSD 5 RELEASE 0# php-4.3.1-dev (current snap)
FreeBSD 4.7 RELEASE 0# php-4.3.1-dev (current snap)

but works on:
FreeBSD 4.7 RELEASE 0# php-4.3.0 (release)
FreeBSD 4.5 RELEASE 0# php-4.3.0 (release)


Previous Comments:


[2003-02-04 16:46:39] [EMAIL PROTECTED]

got a php dump finally:
gdb `which php` php.core.1
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-undermydesk-freebsd"...
Core was generated by `php'.
Program terminated with signal 10, Bus error.
Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.10...done.
Loaded symbols for /usr/local/lib/mysql/libmysqlclient.so.10
Reading symbols from /usr/local/lib/libming.so.3...done.
Loaded symbols for /usr/local/lib/libming.so.3
Reading symbols from /usr/lib/libm.so.2...done.
Loaded symbols for /usr/lib/libm.so.2
Reading symbols from /usr/local/lib/libgd.so.2...done.
Loaded symbols for /usr/local/lib/libgd.so.2
Reading symbols from /usr/local/lib/libfreetype.so.9...done.
Loaded symbols for /usr/local/lib/libfreetype.so.9
Reading symbols from /usr/local/lib/libpng.so.5...done.
Loaded symbols for /usr/local/lib/libpng.so.5
Reading symbols from /usr/lib/libz.so.2...done.
Loaded symbols for /usr/lib/libz.so.2
Reading symbols from /usr/local/lib/libjpeg.so.9...done.
Loaded symbols for /usr/local/lib/libjpeg.so.9
Reading symbols from /usr/lib/libcrypt.so.2...done.
Loaded symbols for /usr/lib/libcrypt.so.2
Reading symbols from /usr/lib/libc.so.5...done.
Loaded symbols for /usr/lib/libc.so.5
Reading symbols from /usr/libexec/ld-elf.so.1...done.
Loaded symbols for /usr/libexec/ld-elf.so.1
#0  _efree (ptr=0x0, __zend_filename=0x0, __zend_lineno=0,
__zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/ports/www/mod_php4/work/php-4.3.0/Zend/zend_alloc.c:215
215 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p->size);
(gdb) bt
#0  _efree (ptr=0x0, __zend_filename=0x0, __zend_lineno=0,
__zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/ports/www/mod_php4/work/php-4.3.0/Zend/zend_alloc.c:215
#1  0x0806c127 in ftp_chdir (ftp=0xffdc, dir=0x0) at
/usr/ports/www/mod_php4/work/php-4.3.0/ext/ftp/ftp.c:425
#2  0x080693e2 in zif_ftp_chdir (ht=0, return_value=0x8244724,
this_ptr=0x0, return_value_used=0)
at /usr/ports/www/mod_php4/work/php-4.3.0/ext/ftp/php_ftp.c:299
#3  0x0817a56b in execute (op_array=0x823f000) at
/usr/ports/www/mod_php4/work/php-4.3.0/Zend/zend_execute.c:1596
#4  0x0817a788 in execute (op_array=0x8237080) at
/usr/ports/www/mod_php4/work/php-4.3.0/Zend/zend_execute.c:1640
#5  0x0817a788 in execute (op_array=0x82201a4) at
/usr/ports/www/mod_php4/work/php-4.3.0/Zend/zend_execute.c:1640
#6  0x0816990c in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/ports/www/mod_php4/work/php-4.3.0/Zend/zend.c:864
#7  0x0813919b in php_execute_script (primary_file=0xbfbffb64) at
/usr/ports/www/mod_php4/work/php-4.3.0/main/main.c:1582
#8  0x08180183 in main (argc=2, argv=0xbfbffbc4) at
/usr/ports/www/mod_php4/work/php-4.3.0/sapi/cli/php_cli.c:753
#9  0x080647f5 in _start ()
(gdb) frame 3
#3  0x0817a56b in execute (op_array=0x823f000) at
/usr/ports/www/mod_php4/work/php-4.3.0/Zend/zend_execute.c:1596
1596   
((zend_internal_function *) EX(function_state).function)->
handler(EX(opline)->extended_value,
EX(Ts)[EX(opline)->result.u.var].var.ptr, EX(object).ptr,
return_value_used TSRMLS_CC)
;



[2003-02-04 14:31:07] [EMAIL PROTECTED]

Cannot replicate the bug on Linux using the latest CVS, possibly a BSD
only issue. Can you reproduce the crash using PHP's CLI sapi?
The backtrace does not indicate the the crash is the result of PHP
code, but rather something in Apache code(?).



[2003-02-04 14:20:57] [EMAIL PROTECTED]

Spider,
   The Stable branch is still breaking somewhere along the ftp
ftp_*list functions in FreeBSD5. These errors don't appear with the
list command commented out. Please Take note that it is now
seg-faulting twice as opposed to once as well as killing 2 child
procs:

tail - /var/log/htt

#22060 [Fbk->Opn]: mssql.datetimeconvert=0 gets wrong month

2003-02-05 Thread cunha17

 ID:   22060
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: MSSQL related
 Operating System: Linux 2.4
 PHP Version:  4.3.0
 New Comment:

same happened with php4-STABLE-200302052030.


Previous Comments:


[2003-02-04 18:05:43] [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



[2003-02-04 17:11:28] [EMAIL PROTECTED]

>>When using this:

$c = mssql_connect("172.16.0.1:1433", "hn", "hn");
mssql_select_db("hn");
$r = mssql_query("select * from hn.employee");
print_r(mssql_fetch_array($r));

>>I get this(as expected):
Array ( [0] => M4398648MG [id] => M4398648MG [1] => FRED [nome] => FRED
[2] => 105 roadhouse, av [addr] => 105 roadhouse, av [3] => NY [city]
=> NY [4] => NY [state] => NY [5] => 70272 [zip] => 70272 [6] => 280876
[id2] => 280876 [7] => FRED [nick] => FRED [8] => Mar 17 1973 12:00AM
[birth] => Mar 17 1973 12:00AM ) 
 
>>When using this:
ini_set('mssql.datetimeconvert',0);
$c = mssql_connect("172.16.0.1:1433", "hn", "hn");
mssql_select_db("hn");
$r = mssql_query("select * from hn.employee");
print_r(mssql_fetch_array($r));

>>I get a wrong month number (02 instead of 03):
Array ( [0] => M4398648MG [id] => M4398648MG [1] => FRED [nome] => FRED
[2] => 105 roadhouse, av [addr] => 105 roadhouse, av [3] => NY [city]
=> NY [4] => NY [state] => NY [5] => 70272 [zip] => 70272 [6] => 280876
[id2] => 280876 [7] => FRED [nick] => FRED [8] => 1973-02-17 00:00:00
[birth] => 1973-02-17 00:00:00 ) 






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

#22079 [Opn]: logging warnings causes header() to fail

2003-02-05 Thread msopacua

 ID:   22079
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Output Control
 Operating System: RedHat 7.2
 PHP Version:  4CVS-2003-02-05 (stable)
 New Comment:

This isn't the source of 'problem.php' as the 'header already sent'
points to line 3, which is the header command itself. It never points
to the header line itself.

Please include post script, so that the correct line is reported.

Also -> this is bound to fail, as line 4 outputs stuff. The header
function != redirect. You should call exit after after the header
command.

I'm leaving this open, since user reports it works in the module
version.


Previous Comments:


[2003-02-05 12:30:00] [EMAIL PROTECTED]

What i am trying to do: send headers
What happens: headers don't get sent under the excuse that "output
already started" if any messages have been logged by error_reporting,
although no output has been sent to the browser. (logging goes to
error_log) If i disable reporting E_NOTICE or logging, problem
disappears.

this happens under php 4.3.0 and the fresh snapshot from Feb 5, when
used in cgi mode in the following ways:
Action php-script /php4/php
-or-
#!/usr/bin/php
it DOES NOT happen under mod_php 4.3.0

code that exhibits the problem:
(i expect to get redirected to ok.php but i see hi instead)
if i remove the errorneous line that causes warnings, it works as
intended.


error_log:
PHP Notice:  Undefined variable:  na in /www/mysite/htdocs/problem.php
on line 2
PHP Warning:  Cannot modify header information - headers already sent
in /www/mysite/htdocs/problem.php on line 3

configure options:
./configure \
--with-config-file-path=/svr/php-cgi \
--prefix=/svr/php-cgi \
--enable-force-cgi-redirect \
--disable-cli \
--enable-bcmath \
--enable-trans-sid \
--with-zlib-dir=/build/zlib-1.1.4 \
--with-gd=/build/gd-1.8.4 \
--with-png-dir=/build/png-1.2.4 \
--with-jpeg-dir=/build/jpeg-6b \
--with-freetype \
--with-mysql=/usr/local \
--with-gettext \
--with-imap \
--with-imap-ssl \
--with-kerberos \

php.ini, relevant options:
error_reporting E_ALL
output_buffering On
log_errors on
display_errors off





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

#22078 [Fbk->Opn]: iconv is not recognized during ./configure

 ID:   22078
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: ICONV related
 Operating System: OpenBSD 3.2 sparc64
 PHP Version:  4.2.3
 New Comment:

See bug #22076 & #22077


Previous Comments:


[2003-02-05 14:05:41] [EMAIL PROTECTED]

As we don't support older versions anymore, I yet think the best
solution is to use 4.3.0.

Then, what's wrong with the latest version?




[2003-02-05 13:50:45] [EMAIL PROTECTED]

1. ./configure --prefix=/usr/local/libiconv

2. Not the case; always uninstalled previous versions before I tried a
new one.

3. Works; however I have other problems with 4.3.0 hence me trying
4.2.3



[2003-02-05 13:36:37] [EMAIL PROTECTED]

1) What option did you specify at the libiconv's configure script?

2) Please check whether another iconv library such as BSD iconv is
installed somewhere else. When two different iconv implementations are
installed, configure may fail.

3) Try the best available version, 4.3.0.





[2003-02-05 11:50:12] [EMAIL PROTECTED]

I reproduced this with iconv 1.8 & 1.7.
Tried the packages and compiling iconv myself. The outcome was
identical.

./configure --with-zlib --with-gd --with-jpeg --with-png
--with-mysql=/usr/local/mysql --with-curl --with-gdbm --with-xmlrpc
--with-dom --with-dom-xslt --with-expat --with
-iconv=/usr/local/libiconv/ --with-iconv-dir=/usr/local/libiconv/



configure: error: Please specify the install prefix of iconv with
--with-iconv=





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

#22080 [NEW]: NOTICE error reporting fails when an undeclared var is global within function

2003-02-05 Thread skander

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.3.0
PHP Bug Type: Scripting Engine problem
Bug description:  NOTICE error reporting fails when an undeclared var is global within 
function

Hi,

I've turned error_reporting() to die() the execution of my scripts as soon
as any error, warning, notice, etc is encountered. 

Yet, in the example global_test() function below,
$some_undefined_variable, which is never set, is declared global, and
$another_undefined_variable is never set and isn't declared global.
isset() returns false on both variables, yet only the line "print
$another_undefined_variable;" triggers an error.

Here's the code:
---
Error [" . $ERROR_STR[$errno] . "] $errstr\n";
  echo "Fatal error in line ".$errline." of file ".$errfile."";
  exit -1;
  break;
} 

$ERROR_STR = array(1 => 'ERROR', 2 => 'WARNING', 4 => 'PARSE',
   8 => 'NOTICE', 16 => 'CORE_ERROR', 32 =>
'CORE_WARNING',
   64 => 'COMPILE_ERROR', 128 => 'COMPILE_WARNING', 256 =>
'USER_ERROR',
   512 => 'USER_WARNING', 1024 => 'USER_NOTICE');

error_reporting (E_ALL);
set_error_handler("allErrorsFatal");


function global_test() {
global $some_undefined_variable;
if (isset($some_undefined_variable)) {
print "some_undefined_variable is set - \n";
} else {
print "some_undefined_variable is not set - \n";
}
print $some_undefined_variable;
if (isset($another_undefined_variable)) {
print "another_undefined_variable is set - \n";
} else {
print "another_undefined_variable is not set - \n";
}
print $another_undefined_variable;
}

global_test();

?>
---


Outputs:
---
some_undefined_variable is not set - 
another_undefined_variable is not set - 
Error [NOTICE] Undefined variable:  another_undefined_variable
Fatal error in line 33 of file /[...]/global_test.php
---


IMHO, the line "print $some_undefined_variable;" should trigger the
notice. Apparently, the global keyword incorrectly affects the way
$some_undefined_variable is handled by the parser later on.

-Kai Schutte
-- 
Edit bug report at http://bugs.php.net/?id=22080&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22080&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22080&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22080&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22080&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22080&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22080&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22080&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22080&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22080&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22080&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22080&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22080&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22080&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22080&r=gnused

#22078 [Opn->Fbk]: iconv is not recognized during ./configure

 ID:   22078
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: ICONV related
 Operating System: OpenBSD 3.2 sparc64
 PHP Version:  4.2.3
 New Comment:

As we don't support older versions anymore, I yet think the best
solution is to use 4.3.0.

Then, what's wrong with the latest version?



Previous Comments:


[2003-02-05 13:50:45] [EMAIL PROTECTED]

1. ./configure --prefix=/usr/local/libiconv

2. Not the case; always uninstalled previous versions before I tried a
new one.

3. Works; however I have other problems with 4.3.0 hence me trying
4.2.3



[2003-02-05 13:36:37] [EMAIL PROTECTED]

1) What option did you specify at the libiconv's configure script?

2) Please check whether another iconv library such as BSD iconv is
installed somewhere else. When two different iconv implementations are
installed, configure may fail.

3) Try the best available version, 4.3.0.





[2003-02-05 11:50:12] [EMAIL PROTECTED]

I reproduced this with iconv 1.8 & 1.7.
Tried the packages and compiling iconv myself. The outcome was
identical.

./configure --with-zlib --with-gd --with-jpeg --with-png
--with-mysql=/usr/local/mysql --with-curl --with-gdbm --with-xmlrpc
--with-dom --with-dom-xslt --with-expat --with
-iconv=/usr/local/libiconv/ --with-iconv-dir=/usr/local/libiconv/



configure: error: Please specify the install prefix of iconv with
--with-iconv=





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

#22078 [Fbk->Opn]: iconv is not recognized during ./configure

 ID:   22078
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: ICONV related
 Operating System: OpenBSD 3.2 sparc64
 PHP Version:  4.2.3
 New Comment:

1. ./configure --prefix=/usr/local/libiconv

2. Not the case; always uninstalled previous versions before I tried a
new one.

3. Works; however I have other problems with 4.3.0 hence me trying
4.2.3


Previous Comments:


[2003-02-05 13:36:37] [EMAIL PROTECTED]

1) What option did you specify at the libiconv's configure script?

2) Please check whether another iconv library such as BSD iconv is
installed somewhere else. When two different iconv implementations are
installed, configure may fail.

3) Try the best available version, 4.3.0.





[2003-02-05 11:50:12] [EMAIL PROTECTED]

I reproduced this with iconv 1.8 & 1.7.
Tried the packages and compiling iconv myself. The outcome was
identical.

./configure --with-zlib --with-gd --with-jpeg --with-png
--with-mysql=/usr/local/mysql --with-curl --with-gdbm --with-xmlrpc
--with-dom --with-dom-xslt --with-expat --with
-iconv=/usr/local/libiconv/ --with-iconv-dir=/usr/local/libiconv/



configure: error: Please specify the install prefix of iconv with
--with-iconv=





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

#14255 [Com]: setcookie bug (Cookie is destroyed/Inaccessible)

2003-02-05 Thread mike

 ID:   14255
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   No Feedback
 Bug Type: HTTP related
 Operating System: Debian 2.2.19
 PHP Version:  4.0.6
 Assigned To:  shiflett
 New Comment:

Oh, I forgot to mention IN THE PREVIOUS POSTING, MY SETUP IS AS
FOLLOWS:

PHP/4.0.6 
APACHE 1.3.22 (Unix)


Previous Comments:


[2003-02-05 13:50:17] [EMAIL PROTECTED]

Oh, I forgot to mention IN THE PREVIOUS POSTING, MY SETUP IS AS
FOLLOWS:

PHP/4.0.6 
APACHE 1.3.22 (Unix)



[2003-02-05 13:44:51] [EMAIL PROTECTED]

I have a PHP script that sets a cookie as follows:

$cookie_expire = time()+3600; 
$cookie_name= "loginpipoclub";  
$value= "mike";  
setcookie ($cookie_name, $value, $cookie_expire);  

THis IS NOT WORKING anymore (I swear it did work
!).  So I have finally tried to find out why the cookie is not being
set by using Telnet.  The response I get in the header shows that the
cookie is expired, but I cannot understand WHY!!!  THE server time
shows the correct time/date according to my system and my watch BUT THE
COOKIE IS MARKED AS DELETED (SEE SetCookie: header below) despite the
fact that I have set it to expire at time() + 3600.   In fact, the
expiry date is marked to be last year.

HERE IS THE RESPONSE FROM THE SERVER USING TELNET ON PORT 80:

HTTP/1.1 200 OK

Date: Wed, 05 Feb 2003 19:40:29 GMT

Server: Apache/1.3.22 (Unix) mod_ssl/2.8.5 OpenSSL/0.9.6a PHP/4.0.6
mod_perl/1.0
X-Powered-By: PHP/4.0.6

Set-Cookie: loginpipoclub=deleted; expires=Tue, 05-Feb-02 19:40:39 GMT;
path=/;m
Transfer-Encoding: chunked 

Content-Type: text/html

PLEASE, CAN ANYONE SHED SOME LIGHT ON THIS. I have been looking all
over the internet on various forums BUT i cannot get a solution to the
problem,

I am using PHP/MYSQL on a unix system in the US, which i am accessing
from telnet in spain. My browser is Internet Explorer 6.0.128
(initially i thought it was a browser issue since I had this working on
other browsers, but the telnet proof shows that it is not a browser
issue, the cookie has in fact been marked as DELETED).

regards
Mike Ferrer



[2002-03-07 00:00:05] [EMAIL PROTECTED]

No feedback was provided for this bug for over a month, 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".



[2002-02-06 14:00:02] [EMAIL PROTECTED]

I'm changing the category to HTTP and status to feedback. I do not
think this is a bug but want to give the submitter time to respond to
my inquiry.



[2002-02-06 12:33:40] [EMAIL PROTECTED]

Is this even a bug?  It's under documentation problem.  Do I need to
change something in the documentation?




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

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

#14255 [Com]: setcookie bug (Cookie is destroyed/Inaccessible)

2003-02-05 Thread mike

 ID:   14255
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   No Feedback
 Bug Type: HTTP related
 Operating System: Debian 2.2.19
 PHP Version:  4.0.6
 Assigned To:  shiflett
 New Comment:

Oh, I forgot to mention IN THE PREVIOUS POSTING, MY SETUP IS AS
FOLLOWS:

PHP/4.0.6 
APACHE 1.3.22 (Unix)


Previous Comments:


[2003-02-05 13:44:51] [EMAIL PROTECTED]

I have a PHP script that sets a cookie as follows:

$cookie_expire = time()+3600; 
$cookie_name= "loginpipoclub";  
$value= "mike";  
setcookie ($cookie_name, $value, $cookie_expire);  

THis IS NOT WORKING anymore (I swear it did work
!).  So I have finally tried to find out why the cookie is not being
set by using Telnet.  The response I get in the header shows that the
cookie is expired, but I cannot understand WHY!!!  THE server time
shows the correct time/date according to my system and my watch BUT THE
COOKIE IS MARKED AS DELETED (SEE SetCookie: header below) despite the
fact that I have set it to expire at time() + 3600.   In fact, the
expiry date is marked to be last year.

HERE IS THE RESPONSE FROM THE SERVER USING TELNET ON PORT 80:

HTTP/1.1 200 OK

Date: Wed, 05 Feb 2003 19:40:29 GMT

Server: Apache/1.3.22 (Unix) mod_ssl/2.8.5 OpenSSL/0.9.6a PHP/4.0.6
mod_perl/1.0
X-Powered-By: PHP/4.0.6

Set-Cookie: loginpipoclub=deleted; expires=Tue, 05-Feb-02 19:40:39 GMT;
path=/;m
Transfer-Encoding: chunked 

Content-Type: text/html

PLEASE, CAN ANYONE SHED SOME LIGHT ON THIS. I have been looking all
over the internet on various forums BUT i cannot get a solution to the
problem,

I am using PHP/MYSQL on a unix system in the US, which i am accessing
from telnet in spain. My browser is Internet Explorer 6.0.128
(initially i thought it was a browser issue since I had this working on
other browsers, but the telnet proof shows that it is not a browser
issue, the cookie has in fact been marked as DELETED).

regards
Mike Ferrer



[2002-03-07 00:00:05] [EMAIL PROTECTED]

No feedback was provided for this bug for over a month, 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".



[2002-02-06 14:00:02] [EMAIL PROTECTED]

I'm changing the category to HTTP and status to feedback. I do not
think this is a bug but want to give the submitter time to respond to
my inquiry.



[2002-02-06 12:33:40] [EMAIL PROTECTED]

Is this even a bug?  It's under documentation problem.  Do I need to
change something in the documentation?




[2002-02-03 22:47:01] [EMAIL PROTECTED]

A couple of comments.

Kris, in regards to your comment on NOV-27-2001 at 1:48PM, that code
will fail because you cannot set a cookie and give a Location header in
the same HTTP response. Well, you *can*, but your cookie will not be
set. Since the server would not be able to identify the client without
the cookie, you get the unexpected behavior. This is a protocol-level
situation, but is generally *not* considered a bug in HTTP (in case you
got the feeling I was supporting that idea). Basically, PHP gives you
the freedom to specify your own headers in the HTTP response, but you
need to have a clear grasp of what they do to use them.

So, if this example was a clear illustration of the problem you've been
having, it's not a bug in PHP. You can spread that around to others who
are having the same problems.

Also, in regards to the time/date discussion, it is correct to say that
the browser uses the client time (obviously) to determine whether to
send a cookie along with subsequent HTTP requests. It is also correct
to say that the setcookie function uses the server time to set the
expiration date. However, since both are in GMT as [EMAIL PROTECTED]
explained (sorry, I don't know your name), this only matters if both
clocks are considerably out of sync or if the expiration time of the
cookie is extremely small. If this is a concern, consider using
client-side scripting to set the cookie, so that the browser itself
creates the cookie based on its own time. You can create the
client-side script itself using PHP, s

#22076 [Opn]: PHP 4.3.0 crashes on OpenBSD 3.2 sparc64 when zlib is linked

 ID:   22076
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: OpenBSD 3.2 SPARC64
 PHP Version:  4.3.0
 New Comment:

vi a.c
int main()
{
char *a, *b;
a = 0;
b = 0;
strcpy(a, b);

return 0;
}

[root@sparc64 root]# gcc -o a a.c -g

[root@sparc64 root]# ./a
Segmentation fault (core dumped)

[root@sparc64 root]# gdb -c a.core a
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "sparc64-unknown-openbsd3.2"...
Core was generated by `a'.
Program terminated with signal 11, Segmentation fault.
#0  0x403855b0 in ?? ()
(gdb) bt
#0  0x403855b0 in ?? ()
#1  0x1004dc in ___start ()
(gdb) 

Seems to work...

I used OpenBSD's 3.2 native compiler and debugger.

[root@sparc64 root]# gcc -v
Reading specs from
/usr/lib/gcc-lib/sparc64-unknown-openbsd3.2/2.95.3/specs
gcc version 2.95.3 20010125 (prerelease)

[root@sparc64 root]# gdb -v
GNU gdb 4.16.1


Previous Comments:


[2003-02-05 13:34:13] [EMAIL PROTECTED]

Looks like something is wrong with your gdb.. I had the 
same problem (gdb coredumping on me), but on Tru64.. 
It went away when I compiled gdb with Compaq's native C 
compiler.. 



[2003-02-05 13:04:28] [EMAIL PROTECTED]

./configure --with-zlib --enable-debug


[root@sparc64 php-4.3.0]# ./sapi/cgi/php
Bus error (core dumped)

[root@sparc64 php-4.3.0]# gdb -c php.core ./sapi/cgi/php
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "sparc64-unknown-openbsd3.2"...
Core was generated by `php'.
Program terminated with signal 10, Bus error.

Dwarf Error: Cannot find referent at offset 507.
(gdb) bt
Segmentation fault (core dumped)


Sorry, that is as good as it gets from a backtrace. I have done this on
two different boxes (U5 & U10) with the same results.



[2003-02-05 12:24:15] [EMAIL PROTECTED]

Can you please compile with --enable-debug, crash the program and then
give us the backtrace? :)



[2003-02-05 11:29:52] [EMAIL PROTECTED]

I posted the following email on the OpenBSD list and no-one knew of
this. I guess it belongs here.

Email:
I am at a loss trying to get PHP 4.3.0 to work on sparc64 using OpenBSD
3.2-release. I have been messing around with this for quite a bit now
and I can't get the damned thing to work. What I did find out is that
the problems are caused by linking zlib (tried the shipped one and also
the latest source). When I tried to debug the issue gdb bombed on me as
well.

Excerpt:
[root@sparc64 php-4.3.0]# gdb sapi/cgi/php
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are welcome to change it and/or distribute copies of it under
certain conditions. Type "show copying" to see the conditions. There is
absolutely no warranty for GDB.  Type "show warranty" for details. This
GDB was configured as "sparc64-unknown-openbsd3.2"...
(gdb) run
Starting program: /root/php-4.3.0/sapi/cgi/php 
Dwarf Error: Cannot find referent at offset 507.
(gdb) bt
Segmentation fault (core dumped)

Anyone any ideas?

I did get it compiled with other stuff as long as it does not require
zlib. Problem for me is that I need gd functionality which depends on
zlib. I searched the PHP site as well as the archives and google but to
no avail.

dmesg:
OpenBSD 3.2 (GENERIC) #8: Thu Oct  3 20:00:17 MDT 2002
 
[EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC
total memory = 134217728
avail memory = 115785728
using 819 buffers containing 6709248 of memory
bootpath: /pci@1f,0/pci@1,1/ide@3,0/disk@0,0
mainbus0 (root): SUNW,Ultra-5_10
cpu0 at mainbus0: SUNW,UltraSPARC-IIi @ 299.825 MHz, version 0 FPU
cpu0: physical 32K instruction (32 b/l), 16K data (32 b/l), 512K
external (64 b/l) psycho0 at mainbus0 addr 0xfffc4000
SUNW,sabre: impl 0, version 0: ign 7c0 bus range 0 to 2; PCI bus 0
IOTDB: 7c6000 to 846000
pci0 at psycho0
ppb0 at pci0 dev 1 function 1 "Sun Simba PCI-PCI" rev 0x11
pci1 at

#14255 [Com]: setcookie bug (Cookie is destroyed/Inaccessible)

2003-02-05 Thread mike

 ID:   14255
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   No Feedback
 Bug Type: HTTP related
 Operating System: Debian 2.2.19
 PHP Version:  4.0.6
 Assigned To:  shiflett
 New Comment:

I have a PHP script that sets a cookie as follows:

$cookie_expire = time()+3600; 
$cookie_name= "loginpipoclub";  
$value= "mike";  
setcookie ($cookie_name, $value, $cookie_expire);  

THis IS NOT WORKING anymore (I swear it did work
!).  So I have finally tried to find out why the cookie is not being
set by using Telnet.  The response I get in the header shows that the
cookie is expired, but I cannot understand WHY!!!  THE server time
shows the correct time/date according to my system and my watch BUT THE
COOKIE IS MARKED AS DELETED (SEE SetCookie: header below) despite the
fact that I have set it to expire at time() + 3600.   In fact, the
expiry date is marked to be last year.

HERE IS THE RESPONSE FROM THE SERVER USING TELNET ON PORT 80:

HTTP/1.1 200 OK

Date: Wed, 05 Feb 2003 19:40:29 GMT

Server: Apache/1.3.22 (Unix) mod_ssl/2.8.5 OpenSSL/0.9.6a PHP/4.0.6
mod_perl/1.0
X-Powered-By: PHP/4.0.6

Set-Cookie: loginpipoclub=deleted; expires=Tue, 05-Feb-02 19:40:39 GMT;
path=/;m
Transfer-Encoding: chunked 

Content-Type: text/html

PLEASE, CAN ANYONE SHED SOME LIGHT ON THIS. I have been looking all
over the internet on various forums BUT i cannot get a solution to the
problem,

I am using PHP/MYSQL on a unix system in the US, which i am accessing
from telnet in spain. My browser is Internet Explorer 6.0.128
(initially i thought it was a browser issue since I had this working on
other browsers, but the telnet proof shows that it is not a browser
issue, the cookie has in fact been marked as DELETED).

regards
Mike Ferrer


Previous Comments:


[2002-03-07 00:00:05] [EMAIL PROTECTED]

No feedback was provided for this bug for over a month, 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".



[2002-02-06 14:00:02] [EMAIL PROTECTED]

I'm changing the category to HTTP and status to feedback. I do not
think this is a bug but want to give the submitter time to respond to
my inquiry.



[2002-02-06 12:33:40] [EMAIL PROTECTED]

Is this even a bug?  It's under documentation problem.  Do I need to
change something in the documentation?




[2002-02-03 22:47:01] [EMAIL PROTECTED]

A couple of comments.

Kris, in regards to your comment on NOV-27-2001 at 1:48PM, that code
will fail because you cannot set a cookie and give a Location header in
the same HTTP response. Well, you *can*, but your cookie will not be
set. Since the server would not be able to identify the client without
the cookie, you get the unexpected behavior. This is a protocol-level
situation, but is generally *not* considered a bug in HTTP (in case you
got the feeling I was supporting that idea). Basically, PHP gives you
the freedom to specify your own headers in the HTTP response, but you
need to have a clear grasp of what they do to use them.

So, if this example was a clear illustration of the problem you've been
having, it's not a bug in PHP. You can spread that around to others who
are having the same problems.

Also, in regards to the time/date discussion, it is correct to say that
the browser uses the client time (obviously) to determine whether to
send a cookie along with subsequent HTTP requests. It is also correct
to say that the setcookie function uses the server time to set the
expiration date. However, since both are in GMT as [EMAIL PROTECTED]
explained (sorry, I don't know your name), this only matters if both
clocks are considerably out of sync or if the expiration time of the
cookie is extremely small. If this is a concern, consider using
client-side scripting to set the cookie, so that the browser itself
creates the cookie based on its own time. You can create the
client-side script itself using PHP, so that the cookie's value can
still be dynamically generated by your PHP scripts.

Hope that clears a few things up. If this didn't solve your problem,
please post another small example, and I'll try to reproduce your
envir

#22055 [Fbk->Opn]: Memory leak with references in objects

2003-02-05 Thread jparneodo

 ID:   22055
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: RedHat 7.2
-PHP Version:  4.3.0
+PHP Version:  4.3.1-dev
 New Comment:

Same result with PHP Version 4.3.1-dev
php4-STABLE-200302051830.tar.gz
Build Date  Feb 5 2003 20:08:24


Previous Comments:


[2003-02-04 14:37:20] [EMAIL PROTECTED]

oops!

you need to development snapshot from snaps.php.net, which should solve
this.

Derick



[2003-02-04 14:36: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



[2003-02-04 14:35:56] [EMAIL PROTECTED]

/*
If you don't set the UP property,
garbage collection is done in real time

If you set the UP property,
garbage collection is done on script shutdown only
and the VmSize increase.

This is a test case
but if a sub-object (in some package) creates a 
circular reference with a sub-sub-object you leak 
memory without the knowledge of it.
*/
for($i=1;$i<=$nb_loop;$i++){
echo "loop $i";
flush();
for($j=1;$j<=$nb_by_loop;$j++){
$a=&new A(500);
$a->b=&new B(500);
$a->b->UP=&$a; // Memory Leak here
//  unset($a->b->up);
}
sleep($sleep_by_loop);
}





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

#22078 [Opn->Fbk]: iconv is not recognized during ./configure

 ID:   22078
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
-Bug Type: *General Issues
+Bug Type: ICONV related
 Operating System: OpenBSD 3.2 sparc64
 PHP Version:  4.2.3
 New Comment:

1) What option did you specify at the libiconv's configure script?

2) Please check whether another iconv library such as BSD iconv is
installed somewhere else. When two different iconv implementations are
installed, configure may fail.

3) Try the best available version, 4.3.0.




Previous Comments:


[2003-02-05 11:50:12] [EMAIL PROTECTED]

I reproduced this with iconv 1.8 & 1.7.
Tried the packages and compiling iconv myself. The outcome was
identical.

./configure --with-zlib --with-gd --with-jpeg --with-png
--with-mysql=/usr/local/mysql --with-curl --with-gdbm --with-xmlrpc
--with-dom --with-dom-xslt --with-expat --with
-iconv=/usr/local/libiconv/ --with-iconv-dir=/usr/local/libiconv/



configure: error: Please specify the install prefix of iconv with
--with-iconv=





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

#22076 [Opn]: PHP 4.3.0 crashes on OpenBSD 3.2 sparc64 when zlib is linked

 ID:   22076
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: OpenBSD 3.2 SPARC64
 PHP Version:  4.3.0
 New Comment:

Looks like something is wrong with your gdb.. I had the 
same problem (gdb coredumping on me), but on Tru64.. 
It went away when I compiled gdb with Compaq's native C 
compiler.. 


Previous Comments:


[2003-02-05 13:04:28] [EMAIL PROTECTED]

./configure --with-zlib --enable-debug


[root@sparc64 php-4.3.0]# ./sapi/cgi/php
Bus error (core dumped)

[root@sparc64 php-4.3.0]# gdb -c php.core ./sapi/cgi/php
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "sparc64-unknown-openbsd3.2"...
Core was generated by `php'.
Program terminated with signal 10, Bus error.

Dwarf Error: Cannot find referent at offset 507.
(gdb) bt
Segmentation fault (core dumped)


Sorry, that is as good as it gets from a backtrace. I have done this on
two different boxes (U5 & U10) with the same results.



[2003-02-05 12:24:15] [EMAIL PROTECTED]

Can you please compile with --enable-debug, crash the program and then
give us the backtrace? :)



[2003-02-05 11:29:52] [EMAIL PROTECTED]

I posted the following email on the OpenBSD list and no-one knew of
this. I guess it belongs here.

Email:
I am at a loss trying to get PHP 4.3.0 to work on sparc64 using OpenBSD
3.2-release. I have been messing around with this for quite a bit now
and I can't get the damned thing to work. What I did find out is that
the problems are caused by linking zlib (tried the shipped one and also
the latest source). When I tried to debug the issue gdb bombed on me as
well.

Excerpt:
[root@sparc64 php-4.3.0]# gdb sapi/cgi/php
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are welcome to change it and/or distribute copies of it under
certain conditions. Type "show copying" to see the conditions. There is
absolutely no warranty for GDB.  Type "show warranty" for details. This
GDB was configured as "sparc64-unknown-openbsd3.2"...
(gdb) run
Starting program: /root/php-4.3.0/sapi/cgi/php 
Dwarf Error: Cannot find referent at offset 507.
(gdb) bt
Segmentation fault (core dumped)

Anyone any ideas?

I did get it compiled with other stuff as long as it does not require
zlib. Problem for me is that I need gd functionality which depends on
zlib. I searched the PHP site as well as the archives and google but to
no avail.

dmesg:
OpenBSD 3.2 (GENERIC) #8: Thu Oct  3 20:00:17 MDT 2002
 
[EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC
total memory = 134217728
avail memory = 115785728
using 819 buffers containing 6709248 of memory
bootpath: /pci@1f,0/pci@1,1/ide@3,0/disk@0,0
mainbus0 (root): SUNW,Ultra-5_10
cpu0 at mainbus0: SUNW,UltraSPARC-IIi @ 299.825 MHz, version 0 FPU
cpu0: physical 32K instruction (32 b/l), 16K data (32 b/l), 512K
external (64 b/l) psycho0 at mainbus0 addr 0xfffc4000
SUNW,sabre: impl 0, version 0: ign 7c0 bus range 0 to 2; PCI bus 0
IOTDB: 7c6000 to 846000
pci0 at psycho0
ppb0 at pci0 dev 1 function 1 "Sun Simba PCI-PCI" rev 0x11
pci1 at ppb0 bus 1
ebus0 at pci1 dev 1 function 0 "Sun PCIO Ebus2" rev 0x01
auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003,
72c000-72c003, 72f000-72f003 power at ebus0 addr 724000-724003 ipl 37
not configured SUNW,pll at ebus0 addr 504000-504002 not configured sab0
at ebus0 addr 40-40007f ipl 43: rev 3.2 sabtty0 at sab0 port 0
sabtty1 at sab0 port 1 comkbd0 at ebus0 addr 3083f8-3083ff ipl 41:
layout 34 wskbd0 at comkbd0: console keyboard com0 at ebus0 addr
3062f8-3062ff ipl 42, mouse: ns16550a, 16 byte fifo lpt0 at ebus0 addr
3043bc-3043cb, 30015c-30015d, 70-7f ipl 34: polled fdthree at
ebus0 addr 3023f0-3023f7, 706000-70600f, 72-720003 ipl 39 not
configured clock0 at ebus0 addr 0-1fff: mk48t59: hostid 8093c4db
flashprom at ebus0 addr 0-f not configured audioce0 at ebus0 addr
20-2000ff, 702000-70200f, 704000-70400f, 722000-722003 ipl 35 ipl
36: nvaddrs 0 audio0 at audioce0 hme0 at pci1 dev 1 function 1 "Sun
HME" rev 0x01: address 08:00:20:93:c4:db nsphy0 at hme0 phy 1: DP83840
10/100 media interface, rev. 1
hme0: using ivec 3021 for interrupt
vgafb0 at pci1 dev 2 function 0 "ATI Mach64 GT" rev 0x9a wsdisplay0 at
vgafb0
wsdisplay0: screen 0 added (sun, sun emulation)
pciide0 a

#21880 [Opn->Fbk]: socket_read does not stop at line breaks

2003-02-05 Thread pollita

 ID:   21880
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Sockets related
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

I've attempted to recreate this error under linux, win32, and irix and
have gotten expected results each time. (socket_read returns after
receiving a \n)

Can you provide a full and complete script which exhibits this
behavior?  ((As short and simple as possible while still reliably
reproducing the bug))


Previous Comments:


[2003-01-25 18:30:24] [EMAIL PROTECTED]

I followed the instructions on all the manuals and tried searching the
inet, but couldent find anything that solved this.

I have a socket that is supposed to read from a client (this is a smtpd
server-type script)..

When I use 

while ($line = socket_read($my_socket,2048,PHP_NORMAL_READ)) {

stuff
}

I can connect to this server via win32 putty, and it will break on line
breaks. But when using Linux telnet and trying to get other smtpd's to
send to it, they would have to send 2048 bytes to get stuff to execute
once.

To make sure they were sending \r or \n I made the socket read go byte
by byte and assemble a string, checking for \n or \r

 while($tstr = socket_read($connection,1)) {

 if (($tstr != chr(13)) && ($tstr != chr(10)))
{
 $buf .= $tstr;
  continue;
 }

^^Example of my byte-by-byte checker

It does find \r and \n in the strings and I am able to gte my server to
work...

Would be nice if the built in function socket_read would really break
on \n or \r.

If more information is needed, please ask




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

#22076 [Fbk->Opn]: PHP 4.3.0 crashes on OpenBSD 3.2 sparc64 when zlib is linked

 ID:   22076
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: OpenBSD 3.2 SPARC64
 PHP Version:  4.3.0
 New Comment:

./configure --with-zlib --enable-debug


[root@sparc64 php-4.3.0]# ./sapi/cgi/php
Bus error (core dumped)

[root@sparc64 php-4.3.0]# gdb -c php.core ./sapi/cgi/php
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "sparc64-unknown-openbsd3.2"...
Core was generated by `php'.
Program terminated with signal 10, Bus error.

Dwarf Error: Cannot find referent at offset 507.
(gdb) bt
Segmentation fault (core dumped)


Sorry, that is as good as it gets from a backtrace. I have done this on
two different boxes (U5 & U10) with the same results.


Previous Comments:


[2003-02-05 12:24:15] [EMAIL PROTECTED]

Can you please compile with --enable-debug, crash the program and then
give us the backtrace? :)



[2003-02-05 11:29:52] [EMAIL PROTECTED]

I posted the following email on the OpenBSD list and no-one knew of
this. I guess it belongs here.

Email:
I am at a loss trying to get PHP 4.3.0 to work on sparc64 using OpenBSD
3.2-release. I have been messing around with this for quite a bit now
and I can't get the damned thing to work. What I did find out is that
the problems are caused by linking zlib (tried the shipped one and also
the latest source). When I tried to debug the issue gdb bombed on me as
well.

Excerpt:
[root@sparc64 php-4.3.0]# gdb sapi/cgi/php
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are welcome to change it and/or distribute copies of it under
certain conditions. Type "show copying" to see the conditions. There is
absolutely no warranty for GDB.  Type "show warranty" for details. This
GDB was configured as "sparc64-unknown-openbsd3.2"...
(gdb) run
Starting program: /root/php-4.3.0/sapi/cgi/php 
Dwarf Error: Cannot find referent at offset 507.
(gdb) bt
Segmentation fault (core dumped)

Anyone any ideas?

I did get it compiled with other stuff as long as it does not require
zlib. Problem for me is that I need gd functionality which depends on
zlib. I searched the PHP site as well as the archives and google but to
no avail.

dmesg:
OpenBSD 3.2 (GENERIC) #8: Thu Oct  3 20:00:17 MDT 2002
 
[EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC
total memory = 134217728
avail memory = 115785728
using 819 buffers containing 6709248 of memory
bootpath: /pci@1f,0/pci@1,1/ide@3,0/disk@0,0
mainbus0 (root): SUNW,Ultra-5_10
cpu0 at mainbus0: SUNW,UltraSPARC-IIi @ 299.825 MHz, version 0 FPU
cpu0: physical 32K instruction (32 b/l), 16K data (32 b/l), 512K
external (64 b/l) psycho0 at mainbus0 addr 0xfffc4000
SUNW,sabre: impl 0, version 0: ign 7c0 bus range 0 to 2; PCI bus 0
IOTDB: 7c6000 to 846000
pci0 at psycho0
ppb0 at pci0 dev 1 function 1 "Sun Simba PCI-PCI" rev 0x11
pci1 at ppb0 bus 1
ebus0 at pci1 dev 1 function 0 "Sun PCIO Ebus2" rev 0x01
auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003,
72c000-72c003, 72f000-72f003 power at ebus0 addr 724000-724003 ipl 37
not configured SUNW,pll at ebus0 addr 504000-504002 not configured sab0
at ebus0 addr 40-40007f ipl 43: rev 3.2 sabtty0 at sab0 port 0
sabtty1 at sab0 port 1 comkbd0 at ebus0 addr 3083f8-3083ff ipl 41:
layout 34 wskbd0 at comkbd0: console keyboard com0 at ebus0 addr
3062f8-3062ff ipl 42, mouse: ns16550a, 16 byte fifo lpt0 at ebus0 addr
3043bc-3043cb, 30015c-30015d, 70-7f ipl 34: polled fdthree at
ebus0 addr 3023f0-3023f7, 706000-70600f, 72-720003 ipl 39 not
configured clock0 at ebus0 addr 0-1fff: mk48t59: hostid 8093c4db
flashprom at ebus0 addr 0-f not configured audioce0 at ebus0 addr
20-2000ff, 702000-70200f, 704000-70400f, 722000-722003 ipl 35 ipl
36: nvaddrs 0 audio0 at audioce0 hme0 at pci1 dev 1 function 1 "Sun
HME" rev 0x01: address 08:00:20:93:c4:db nsphy0 at hme0 phy 1: DP83840
10/100 media interface, rev. 1
hme0: using ivec 3021 for interrupt
vgafb0 at pci1 dev 2 function 0 "ATI Mach64 GT" rev 0x9a wsdisplay0 at
vgafb0
wsdisplay0: screen 0 added (sun, sun emulation)
pciide0 at pci1 dev 3 function 0 "CMD Technology PCI0646" rev 0x03:
DMA, channel 0 configured to native-PCI, channel 1 configured to
native-PCI
pciide0: using ivec 1820 for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA, 4103MB, 8894 cyl, 15 he

#22079 [NEW]: logging warnings causes header() to fail

2003-02-05 Thread zlo

From: [EMAIL PROTECTED]
Operating system: RedHat 7.2
PHP version:  4CVS-2003-02-05 (stable)
PHP Bug Type: Output Control
Bug description:  logging warnings causes header() to fail

What i am trying to do: send headers
What happens: headers don't get sent under the excuse that "output already
started" if any messages have been logged by error_reporting, although no
output has been sent to the browser. (logging goes to error_log) If i
disable reporting E_NOTICE or logging, problem disappears.

this happens under php 4.3.0 and the fresh snapshot from Feb 5, when used
in cgi mode in the following ways:
Action php-script /php4/php
-or-
#!/usr/bin/php
it DOES NOT happen under mod_php 4.3.0

code that exhibits the problem:
(i expect to get redirected to ok.php but i see hi instead)
if i remove the errorneous line that causes warnings, it works as
intended.


error_log:
PHP Notice:  Undefined variable:  na in /www/mysite/htdocs/problem.php on
line 2
PHP Warning:  Cannot modify header information - headers already sent in
/www/mysite/htdocs/problem.php on line 3

configure options:
./configure \
--with-config-file-path=/svr/php-cgi \
--prefix=/svr/php-cgi \
--enable-force-cgi-redirect \
--disable-cli \
--enable-bcmath \
--enable-trans-sid \
--with-zlib-dir=/build/zlib-1.1.4 \
--with-gd=/build/gd-1.8.4 \
--with-png-dir=/build/png-1.2.4 \
--with-jpeg-dir=/build/jpeg-6b \
--with-freetype \
--with-mysql=/usr/local \
--with-gettext \
--with-imap \
--with-imap-ssl \
--with-kerberos \

php.ini, relevant options:
error_reporting E_ALL
output_buffering On
log_errors on
display_errors off

-- 
Edit bug report at http://bugs.php.net/?id=22079&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22079&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22079&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22079&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22079&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22079&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22079&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22079&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22079&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22079&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22079&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22079&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22079&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22079&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22079&r=gnused

#22076 [Opn->Fbk]: PHP 4.3.0 crashes on OpenBSD 3.2 sparc64 when zlib is linked

2003-02-05 Thread kalowsky

 ID:   22076
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: OpenBSD 3.2 SPARC64
 PHP Version:  4.3.0
 New Comment:

Can you please compile with --enable-debug, crash the program and then
give us the backtrace? :)


Previous Comments:


[2003-02-05 11:29:52] [EMAIL PROTECTED]

I posted the following email on the OpenBSD list and no-one knew of
this. I guess it belongs here.

Email:
I am at a loss trying to get PHP 4.3.0 to work on sparc64 using OpenBSD
3.2-release. I have been messing around with this for quite a bit now
and I can't get the damned thing to work. What I did find out is that
the problems are caused by linking zlib (tried the shipped one and also
the latest source). When I tried to debug the issue gdb bombed on me as
well.

Excerpt:
[root@sparc64 php-4.3.0]# gdb sapi/cgi/php
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are welcome to change it and/or distribute copies of it under
certain conditions. Type "show copying" to see the conditions. There is
absolutely no warranty for GDB.  Type "show warranty" for details. This
GDB was configured as "sparc64-unknown-openbsd3.2"...
(gdb) run
Starting program: /root/php-4.3.0/sapi/cgi/php 
Dwarf Error: Cannot find referent at offset 507.
(gdb) bt
Segmentation fault (core dumped)

Anyone any ideas?

I did get it compiled with other stuff as long as it does not require
zlib. Problem for me is that I need gd functionality which depends on
zlib. I searched the PHP site as well as the archives and google but to
no avail.

dmesg:
OpenBSD 3.2 (GENERIC) #8: Thu Oct  3 20:00:17 MDT 2002
 
[EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC
total memory = 134217728
avail memory = 115785728
using 819 buffers containing 6709248 of memory
bootpath: /pci@1f,0/pci@1,1/ide@3,0/disk@0,0
mainbus0 (root): SUNW,Ultra-5_10
cpu0 at mainbus0: SUNW,UltraSPARC-IIi @ 299.825 MHz, version 0 FPU
cpu0: physical 32K instruction (32 b/l), 16K data (32 b/l), 512K
external (64 b/l) psycho0 at mainbus0 addr 0xfffc4000
SUNW,sabre: impl 0, version 0: ign 7c0 bus range 0 to 2; PCI bus 0
IOTDB: 7c6000 to 846000
pci0 at psycho0
ppb0 at pci0 dev 1 function 1 "Sun Simba PCI-PCI" rev 0x11
pci1 at ppb0 bus 1
ebus0 at pci1 dev 1 function 0 "Sun PCIO Ebus2" rev 0x01
auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003,
72c000-72c003, 72f000-72f003 power at ebus0 addr 724000-724003 ipl 37
not configured SUNW,pll at ebus0 addr 504000-504002 not configured sab0
at ebus0 addr 40-40007f ipl 43: rev 3.2 sabtty0 at sab0 port 0
sabtty1 at sab0 port 1 comkbd0 at ebus0 addr 3083f8-3083ff ipl 41:
layout 34 wskbd0 at comkbd0: console keyboard com0 at ebus0 addr
3062f8-3062ff ipl 42, mouse: ns16550a, 16 byte fifo lpt0 at ebus0 addr
3043bc-3043cb, 30015c-30015d, 70-7f ipl 34: polled fdthree at
ebus0 addr 3023f0-3023f7, 706000-70600f, 72-720003 ipl 39 not
configured clock0 at ebus0 addr 0-1fff: mk48t59: hostid 8093c4db
flashprom at ebus0 addr 0-f not configured audioce0 at ebus0 addr
20-2000ff, 702000-70200f, 704000-70400f, 722000-722003 ipl 35 ipl
36: nvaddrs 0 audio0 at audioce0 hme0 at pci1 dev 1 function 1 "Sun
HME" rev 0x01: address 08:00:20:93:c4:db nsphy0 at hme0 phy 1: DP83840
10/100 media interface, rev. 1
hme0: using ivec 3021 for interrupt
vgafb0 at pci1 dev 2 function 0 "ATI Mach64 GT" rev 0x9a wsdisplay0 at
vgafb0
wsdisplay0: screen 0 added (sun, sun emulation)
pciide0 at pci1 dev 3 function 0 "CMD Technology PCI0646" rev 0x03:
DMA, channel 0 configured to native-PCI, channel 1 configured to
native-PCI
pciide0: using ivec 1820 for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA, 4103MB, 8894 cyl, 15 head, 63 sec, 8404830
sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0:  SCSI0
5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
ppb1 at pci0 dev 1 function 0 "Sun Simba PCI-PCI" rev 0x11
pci2 at ppb1 bus 2
siop0 at pci2 dev 1 function 0 "Symbios Logic 53c875" rev 0x14 using
on-board RAM ivec 10 scsibus1 at siop0: 16 targets siop1 at pci2 dev 1
function 1 "Symbios Logic 53c875" rev 0x14 using on-board RAM ivec 11
scsibus2 at siop1: 16 targets creator0 at mainbus0 addr 0xfebee000:
Creator3D, model SUNW,501-4788 wsdisplay1 at creator0: console (std,
sun emulation), using wskbd0 pcons at mainbus0 not configured No
counter-timer -- using %tick at 299MHz as system clock. root on wd0a
rootdev=0xc00 rrootdev=0x1a00 rawdev=0x1a02





-- 
Edit this bug report at http://bugs.php.net/?id

#19918 [Com]: no libphp4.so produced

2003-02-05 Thread benoit . bruckert

 ID:   19918
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Compile Failure
 Operating System: HP-UX 11.00
 PHP Version:  4.3.0
 New Comment:

oups ! it was with-apxs2 and not with-apxs...


Previous Comments:


[2003-02-05 11:29:07] [EMAIL PROTECTED]

OS : HP-UX11.00 (32 bits)
gcc 2.95.2
PHP 4.3.0.
apache 2.0.44

php config :
./configure --with-apxs=/home/apache2/bin/apxs
--without-mysql
--enable-track-vars
make
I have crypt warning about share libs !!
Then I changed the Make file and removed -lcrypt
make
--> OK no more warning
make install
--> OK
apachectl start 
--> no errors
I started then it works, (I got the phpinfo page),
What the lib crypt is made for ??? what functions are using it ?



[2003-01-22 12:44:34] [EMAIL PROTECTED]

i have the same probleme with PHP 4.3 + SAPI NSAPI on HP-UX 11!

/bin/sh libtool --silent --mode=link gcc -g -O2 -DZTS -prefer-pic 
-rpath /opt/php43/php-4.3.0/libs -avoid-version -module -L/usr/lo
cal/lib -L/opt/bzip2/lib -L/opt/jpeg-6/lib -L/opt/libpng/lib
-L/opt/xpm/lib -L/opt/freetype/lib -L/opt/T1/lib -L/opt/gd/lib  -R
/usr
/local/lib -R /opt/bzip2/lib -R /opt/jpeg-6/lib -R /opt/libpng/lib -R
/opt/xpm/lib -R /opt/freetype/lib -R /opt/T1/lib -R /opt/gd/li
b ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/bz2/bz2.lo
ext/ctype/ctype.lo ext/gd/gd.lo ext/gd/gdttf.lo ext/gd/gdcache.lo e
xt/overload/overload.lo ext/pcre/pcrelib/maketables.lo
ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo
ext/pcre/pcrelib/pcre.lo ex
t/pcre/php_pcre.lo ext/session/session.lo ext/session/mod_files.lo
ext/session/mod_mm.lo ext/session/mod_user.lo ext/standard/array.
lo ext/standard/base64.lo ext/standard/basic_functions.lo
ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo
ext/s
tandard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo
ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/
standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo
ext/standard/formatted_print.lo ext/standard/fsock.lo ext/sta
ndard/head.lo ext/standard/html.lo ext/standard/image.lo
ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo
ext/standard/
link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo
ext/standard/metaphone.lo ext/standard/microtime.lo ext/standa
rd/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo
ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo ex
t/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo
ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.l
o ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo
ext/standard/versioning.lo ext/standard/assert.lo ext/standard
/strnatcmp.lo ext/standard/levenshtein.lo
ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo
ext/standard/ftp_fopen_wra
pper.lo ext/standard/http_fopen_wrapper.lo
ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo
ext/standard/css.lo ext/standar
d/var_unserializer.lo ext/standard/ftok.lo ext/standard/aggregation.lo
ext/standard/sha1.lo ext/tokenizer/tokenizer.lo regex/regcomp
.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo TSRM/TSRM.lo
TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo mai
n/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo
main/fopen_wrappers.lo main/alloca.lo main/php_ini.lo main/SAPI
.lo main/rfc1867.lo main/php_content_types.lo main/strlcpy.lo
main/strlcat.lo main/mergesort.lo main/reentrancy.lo main/php_variable
s.lo main/php_ticks.lo main/streams.lo main/network.lo
main/php_open_temporary_file.lo main/php_logos.lo main/output.lo
main/memory_
streams.lo main/user_streams.lo Zend/zend_language_parser.lo
Zend/zend_language_scanner.lo Zend/zend_ini_parser.lo
Zend/zend_ini_sca
nner.lo Zend/zend_alloc.lo Zend/zend_compile.lo Zend/zend_constants.lo
Zend/zend_dynamic_array.lo Zend/zend_execute_API.lo Zend/zend
_highlight.lo Zend/zend_llist.lo Zend/zend_opcode.lo
Zend/zend_operators.lo Zend/zend_ptr_stack.lo Zend/zend_stack.lo
Zend/zend_vari
ables.lo Zend/zend.lo Zend/zend_API.lo Zend/zend_extensions.lo
Zend/zend_hash.lo Zend/zend_list.lo Zend/zend_indent.lo Zend/zend_bui
ltin_functions.lo Zend/zend_sprintf.lo Zend/zend_ini.lo
Zend/zend_qsort.lo Zend/zend_multibyte.lo Zend/zend_execute.lo
sapi/nsapi/ns
api.lo main/internal_functions.lo -lgd -lt1 -lttf -lX11 -lXpm -lpng -lz
-ljpeg -lbz2 -lz -lcrypt -lm -lnsl -lpthread -lcrypt  -o lib
php4.la

*** Warning: This library needs some functionality provided by
-lcrypt.
*** I have the capability to make that library automatically link in
when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

#22078 [NEW]: iconv is not recognized during ./configure

From: [EMAIL PROTECTED]
Operating system: OpenBSD 3.2 sparc64
PHP version:  4.2.3
PHP Bug Type: *General Issues
Bug description:  iconv is not recognized during ./configure

I reproduced this with iconv 1.8 & 1.7.
Tried the packages and compiling iconv myself. The outcome was identical.

./configure --with-zlib --with-gd --with-jpeg --with-png
--with-mysql=/usr/local/mysql --with-curl --with-gdbm --with-xmlrpc
--with-dom --with-dom-xslt --with-expat --with
-iconv=/usr/local/libiconv/ --with-iconv-dir=/usr/local/libiconv/



configure: error: Please specify the install prefix of iconv with
--with-iconv=

-- 
Edit bug report at http://bugs.php.net/?id=22078&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22078&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22078&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22078&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22078&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22078&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22078&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22078&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22078&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22078&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22078&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22078&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22078&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22078&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22078&r=gnused

#22073 [Opn->Fbk]: --with-mcrypt won't compile

2003-02-05 Thread derick

 ID:   22073
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: Red Hat Linux 8.0
 PHP Version:  4.3.0
 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

Very likely to be fixed in CVS.


Previous Comments:


[2003-02-05 11:14:00] [EMAIL PROTECTED]

Sorry, I forgot to answer you question about mcrypt version.

# libmcrypt-config --version
2.5.6



[2003-02-05 10:55:26] [EMAIL PROTECTED]

I am not using mcrypt. I am only using libmcrypt (as per the PHP
documentation). The version is 2.5.6

> When you are using the --with-mcrypt=../libmcrypt-2.5.6/, does it
still
try to open /usr/local/include/mcrypt.h?

Uh ... don't know. How do I find the answer for you?

I followed your suggestions, here is the result:

# cd /usr/src/php-4.3.0/
# rm config.cache 
# make clean
find . -name \*.lo -o -name \*.o | xargs rm -f
find . -name \*.la -o -name \*.a | xargs rm -f 
find . -name \*.so | xargs rm -f
find . -name .libs -a -type d|xargs rm -rf
rm -f libphp4.la sapi/cli/php libphp4.la modules/* libs/*
# ./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt  
[...]
Configuring extensions
[...]
checking for mcrypt support... yes
checking for mcrypt_module_open in -lmcrypt... no
checking for init_mcrypt in -lmcrypt... yes

# make
gcc  -Iext/ctype/ -I/usr/src/php-4.3.0/ext/ctype/ -DPHP_ATOM_INC
-I/usr/src/php-4.3.0/include -I/usr/src/php-4.3.0/main
-I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend -I/usr/local/include
-I/usr/src/php-4.3.0/ext/xml/expat  -I/usr/src/php-4.3.0/TSRM  -g -O2 
-c /usr/src/php-4.3.0/ext/ctype/ctype.c -o ext/ctype/ctype.o  && echo >
ext/ctype/ctype.lo
cc1: warning: changing search order for system directory
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system
directory
gcc  -Iext/mcrypt/ -I/usr/src/php-4.3.0/ext/mcrypt/ -DPHP_ATOM_INC
-I/usr/src/php-4.3.0/include -I/usr/src/php-4.3.0/main
-I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend -I/usr/local/include
-I/usr/src/php-4.3.0/ext/xml/expat  -I/usr/src/php-4.3.0/TSRM  -g -O2 
-c /usr/src/php-4.3.0/ext/mcrypt/mcrypt.c -o ext/mcrypt/mcrypt.o  &&
echo > ext/mcrypt/mcrypt.lo
cc1: warning: changing search order for system directory
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system
directory
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:229:1: warning: "MCRYPT_FAILED"
redefined
In file included from /usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:34:
/usr/local/include/mcrypt.h:31:1: warning: this is the location of the
previous definition
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c: In function
`zm_startup_mcrypt':
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:279: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:280: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: `MCRYPT_BLOWFISH_128'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: (Each undeclared identifier
is reported only once
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: for each function it
appears in.)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:282: `MCRYPT_BLOWFISH_192'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:283: `MCRYPT_BLOWFISH_256'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:284: `MCRYPT_BLOWFISH_448'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:285: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:286: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:287: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:288: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:289: `MCRYPT_IDEA' undeclared
(first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:290: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:291: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:292: warning: passing arg 3 of
`zend_register_long_constant' makes integer from

#22077 [NEW]: Compilation hangs on sha1.c when using -O2

From: [EMAIL PROTECTED]
Operating system: OpenBSD 3.2 sparc64
PHP version:  4.3.0
PHP Bug Type: Compile Failure
Bug description:  Compilation hangs on sha1.c when using -O2

Fix: use -O0 on sha1.c during compilation.

Error:
I was trying to compile php-4.3.0 on an Ultra-5 & an Ultra-10 (dmesg at
the
bottom). Both boxes run OpenBSD 3.2-sparc64. What happens is that the
compiler hangs on sha1.c. It seems as if there are way too many macro's
in
there. I removed the macro's and the file did compile. The macro's that
hang
the compiler are (php-4.3.0/ext/standard/sha1.c line 144):

/* FF, GG, HH, and II transformations for rounds 1, 2, 3, and 4.
 */
#define FF(a, b, c, d, e, w) { \
 (e) += F ((b), (c), (d)) + (w) + (php_uint32)(0x5A827999); \
 (e) += ROTATE_LEFT ((a), 5); \
 (b) = ROTATE_LEFT((b), 30); \
  }
#define GG(a, b, c, d, e, w) { \
 (e) += G ((b), (c), (d)) + (w) + (php_uint32)(0x6ED9EBA1); \
 (e) += ROTATE_LEFT ((a), 5); \
 (b) = ROTATE_LEFT((b), 30); \
  }
#define HH(a, b, c, d, e, w) { \
 (e) += H ((b), (c), (d)) + (w) + (php_uint32)(0x8F1BBCDC); \
 (e) += ROTATE_LEFT ((a), 5); \
 (b) = ROTATE_LEFT((b), 30); \
  }
#define II(a, b, c, d, e, w) { \
 (e) += I ((b), (c), (d)) + (w) + (php_uint32)(0xCA62C1D6); \
 (e) += ROTATE_LEFT ((a), 5); \
 (b) = ROTATE_LEFT((b), 30); \
  }

Note all the embedded macro's (F, G, H, I, ROTATE_LEFT). Anyway, has
anyone
run into this and figured out a fix?
I will try to compile the same code on Intel and see what happens.

I searched the web, mail archives and the php archives.

More details:
PHP requires quite a bit of lib's so I installed the following from the
ports:
curl-7.9.8.tgz
gdbm-1.8.0.tgz
libiconv-1.8.tgz
pkgconfig-0.12.0.tgz
libxml-2.4.24.tgz
jpeg-6b.tgz
png-1.2.4.tgz
gettext-0.10.40.tgz
gmake-3.79.1.tgz
expat-1.95.4.tgz
sablotron-0.96.tgz
libxslt-1.0.20.tgz

I compiled the following ones from source:
freetype2.1.3
imap-wu-2002 (coppied the headers manually to /usr/local/include)
libmcal-0.6 (coppied the headers manually to /usr/local/include)

I configured PHP as follows:
./configure --prefix=/usr/local/php --with-openssl --with-zlib
--enable-bcma
th --enable-calendar --with-curl --with-gdbm --with-dom --with-gd
--with-jpe
g-dir --with-png-dir=/usr/local --with-freetype-dir --enable-gd-native-ttf
-
-with-imap --with-mcal --with-mysql=/usr/local/mysql --enable-xslt
--with-ex
pat-dir=/usr/local --with-iconv=/usr/local --with-dom-xslt
--with-xslt-sablo
t=/usr/local --with-expat-dir=/usr/local --with-iconv-dir=/usr/local

Top after running overnight:
load averages:  1.15,  1.17,  1.16
09:41:52
15 processes:  2 running, 13 idle
CPU states: 98.8% user,  0.0% nice,  1.2% system,  0.0% interrupt,  0.0%
idle
Memory: Real: 15M/38M act/tot  Free: 207M  Swap: 3896K/256M used/tot
 Command not understood
  PID USERNAME PRI NICE  SIZE   RES STATE WAIT TIMECPU COMMAND
32291 root  640 8312K 8696K run   -  730:13 98.39% cc1
15610 root  280  240K 1520K run   -0:00  0.29% top
32651 root   20  792K  896K sleep select   0:07  0.00% sshd
23396 root   20  832K  864K idle  select   0:11  0.00% sshd
24835 root   20 1760K 1912K sleep select   0:00  0.00% sendmail
 2362 root   20  736K0K idle  select   0:02  0.00% sshd
18904 root  100 1992K  672K idle  wait 0:01  0.00% bash
 2455 root  100 1992K  816K sleep wait 0:01  0.00% bash
 1758 root   20  328K  688K idle  select   0:00  0.00% cron
17119 root   20  176K  640K sleep select   0:00  0.00% syslogd
17210 root   20  144K  624K idle  select   0:00  0.00% inetd
1 root  100  656K  104K idle  wait 0:00  0.00% init
19709 root   20  800K  424K idle  poll 0:00  0.00% dhclient
31498 root  100  264K 1088K idle  wait 0:00  0.00% gcc
 1579 root   30   72K0K idle  ttyin0:00  0.00% getty

Dmesg of ultra-5
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights
reserved.
Copyright (c) 1995-2002 OpenBSD. All rights reserved.
http://www.OpenBSD.org

OpenBSD 3.2 (GENERIC) #8: Thu Oct  3 20:00:17 MDT 2002
[EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC
total memory = 268435456
avail memory = 240558080
using 1638 buffers containing 13418496 of memory
bootpath: /pci@1f,0/pci@1,1/ide@3,0/disk@0,0
mainbus0 (root): SUNW,Ultra-5_10
cpu0 at mainbus0: SUNW,UltraSPARC-IIi @ 333 MHz, version 0 FPU
cpu0: physical 32K instruction (32 b/l), 16K data (32 b/l), 2048K
external
(64 b/l)
psycho0 at mainbus0 addr 0xfffc4000
SUNW,sabre: impl 0, version 0: ign 7c0 bus range 0 to 2; PCI bus 0
IOTDB: f66000 to fe6000
pci0 at psycho0
ppb0 at pci0 dev 1 function 1 "Sun Simba PCI-PCI" rev 0x13
pci1 at ppb0 bus 1
ebus0 at pci1 dev 1 function 0 "Sun PCIO Ebus2" rev 0x01
auxio0 at ebus0 addr 726000-726003, 7280

#22076 [NEW]: PHP 4.3.0 crashes on OpenBSD 3.2 sparc64 when zlib is linked

From: [EMAIL PROTECTED]
Operating system: OpenBSD 3.2 SPARC64
PHP version:  4.3.0
PHP Bug Type: Reproducible crash
Bug description:  PHP 4.3.0 crashes on OpenBSD 3.2 sparc64 when zlib is linked

I posted the following email on the OpenBSD list and no-one knew of this. I
guess it belongs here.

Email:
I am at a loss trying to get PHP 4.3.0 to work on sparc64 using OpenBSD
3.2-release. I have been messing around with this for quite a bit now and
I can't get the damned thing to work. What I did find out is that the
problems are caused by linking zlib (tried the shipped one and also the
latest source). When I tried to debug the issue gdb bombed on me as well.

Excerpt:
[root@sparc64 php-4.3.0]# gdb sapi/cgi/php
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are welcome to change it and/or distribute copies of it under certain
conditions. Type "show copying" to see the conditions. There is absolutely
no warranty for GDB.  Type "show warranty" for details. This GDB was
configured as "sparc64-unknown-openbsd3.2"...
(gdb) run
Starting program: /root/php-4.3.0/sapi/cgi/php 
Dwarf Error: Cannot find referent at offset 507.
(gdb) bt
Segmentation fault (core dumped)

Anyone any ideas?

I did get it compiled with other stuff as long as it does not require
zlib. Problem for me is that I need gd functionality which depends on
zlib. I searched the PHP site as well as the archives and google but to no
avail.

dmesg:
OpenBSD 3.2 (GENERIC) #8: Thu Oct  3 20:00:17 MDT 2002
 
[EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC
total memory = 134217728
avail memory = 115785728
using 819 buffers containing 6709248 of memory
bootpath: /pci@1f,0/pci@1,1/ide@3,0/disk@0,0
mainbus0 (root): SUNW,Ultra-5_10
cpu0 at mainbus0: SUNW,UltraSPARC-IIi @ 299.825 MHz, version 0 FPU
cpu0: physical 32K instruction (32 b/l), 16K data (32 b/l), 512K external
(64 b/l) psycho0 at mainbus0 addr 0xfffc4000
SUNW,sabre: impl 0, version 0: ign 7c0 bus range 0 to 2; PCI bus 0
IOTDB: 7c6000 to 846000
pci0 at psycho0
ppb0 at pci0 dev 1 function 1 "Sun Simba PCI-PCI" rev 0x11
pci1 at ppb0 bus 1
ebus0 at pci1 dev 1 function 0 "Sun PCIO Ebus2" rev 0x01
auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003,
72c000-72c003, 72f000-72f003 power at ebus0 addr 724000-724003 ipl 37 not
configured SUNW,pll at ebus0 addr 504000-504002 not configured sab0 at
ebus0 addr 40-40007f ipl 43: rev 3.2 sabtty0 at sab0 port 0 sabtty1 at
sab0 port 1 comkbd0 at ebus0 addr 3083f8-3083ff ipl 41: layout 34 wskbd0
at comkbd0: console keyboard com0 at ebus0 addr 3062f8-3062ff ipl 42,
mouse: ns16550a, 16 byte fifo lpt0 at ebus0 addr 3043bc-3043cb,
30015c-30015d, 70-7f ipl 34: polled fdthree at ebus0 addr
3023f0-3023f7, 706000-70600f, 72-720003 ipl 39 not configured clock0
at ebus0 addr 0-1fff: mk48t59: hostid 8093c4db flashprom at ebus0 addr
0-f not configured audioce0 at ebus0 addr 20-2000ff,
702000-70200f, 704000-70400f, 722000-722003 ipl 35 ipl 36: nvaddrs 0
audio0 at audioce0 hme0 at pci1 dev 1 function 1 "Sun HME" rev 0x01:
address 08:00:20:93:c4:db nsphy0 at hme0 phy 1: DP83840 10/100 media
interface, rev. 1
hme0: using ivec 3021 for interrupt
vgafb0 at pci1 dev 2 function 0 "ATI Mach64 GT" rev 0x9a wsdisplay0 at
vgafb0
wsdisplay0: screen 0 added (sun, sun emulation)
pciide0 at pci1 dev 3 function 0 "CMD Technology PCI0646" rev 0x03: DMA,
channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide0: using ivec 1820 for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA, 4103MB, 8894 cyl, 15 head, 63 sec, 8404830
sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0:  SCSI0
5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
ppb1 at pci0 dev 1 function 0 "Sun Simba PCI-PCI" rev 0x11
pci2 at ppb1 bus 2
siop0 at pci2 dev 1 function 0 "Symbios Logic 53c875" rev 0x14 using
on-board RAM ivec 10 scsibus1 at siop0: 16 targets siop1 at pci2 dev 1
function 1 "Symbios Logic 53c875" rev 0x14 using on-board RAM ivec 11
scsibus2 at siop1: 16 targets creator0 at mainbus0 addr 0xfebee000:
Creator3D, model SUNW,501-4788 wsdisplay1 at creator0: console (std, sun
emulation), using wskbd0 pcons at mainbus0 not configured No counter-timer
-- using %tick at 299MHz as system clock. root on wd0a rootdev=0xc00
rrootdev=0x1a00 rawdev=0x1a02

-- 
Edit bug report at http://bugs.php.net/?id=22076&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22076&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22076&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22076&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22076&r=needtrace
Try newer version:  http://bu

#19918 [Com]: no libphp4.so produced

2003-02-05 Thread benoit . bruckert

 ID:   19918
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Compile Failure
 Operating System: HP-UX 11.00
 PHP Version:  4.3.0
 New Comment:

OS : HP-UX11.00 (32 bits)
gcc 2.95.2
PHP 4.3.0.
apache 2.0.44

php config :
./configure --with-apxs=/home/apache2/bin/apxs
--without-mysql
--enable-track-vars
make
I have crypt warning about share libs !!
Then I changed the Make file and removed -lcrypt
make
--> OK no more warning
make install
--> OK
apachectl start 
--> no errors
I started then it works, (I got the phpinfo page),
What the lib crypt is made for ??? what functions are using it ?


Previous Comments:


[2003-01-22 12:44:34] [EMAIL PROTECTED]

i have the same probleme with PHP 4.3 + SAPI NSAPI on HP-UX 11!

/bin/sh libtool --silent --mode=link gcc -g -O2 -DZTS -prefer-pic 
-rpath /opt/php43/php-4.3.0/libs -avoid-version -module -L/usr/lo
cal/lib -L/opt/bzip2/lib -L/opt/jpeg-6/lib -L/opt/libpng/lib
-L/opt/xpm/lib -L/opt/freetype/lib -L/opt/T1/lib -L/opt/gd/lib  -R
/usr
/local/lib -R /opt/bzip2/lib -R /opt/jpeg-6/lib -R /opt/libpng/lib -R
/opt/xpm/lib -R /opt/freetype/lib -R /opt/T1/lib -R /opt/gd/li
b ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/bz2/bz2.lo
ext/ctype/ctype.lo ext/gd/gd.lo ext/gd/gdttf.lo ext/gd/gdcache.lo e
xt/overload/overload.lo ext/pcre/pcrelib/maketables.lo
ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo
ext/pcre/pcrelib/pcre.lo ex
t/pcre/php_pcre.lo ext/session/session.lo ext/session/mod_files.lo
ext/session/mod_mm.lo ext/session/mod_user.lo ext/standard/array.
lo ext/standard/base64.lo ext/standard/basic_functions.lo
ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo
ext/s
tandard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo
ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/
standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo
ext/standard/formatted_print.lo ext/standard/fsock.lo ext/sta
ndard/head.lo ext/standard/html.lo ext/standard/image.lo
ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo
ext/standard/
link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo
ext/standard/metaphone.lo ext/standard/microtime.lo ext/standa
rd/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo
ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo ex
t/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo
ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.l
o ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo
ext/standard/versioning.lo ext/standard/assert.lo ext/standard
/strnatcmp.lo ext/standard/levenshtein.lo
ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo
ext/standard/ftp_fopen_wra
pper.lo ext/standard/http_fopen_wrapper.lo
ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo
ext/standard/css.lo ext/standar
d/var_unserializer.lo ext/standard/ftok.lo ext/standard/aggregation.lo
ext/standard/sha1.lo ext/tokenizer/tokenizer.lo regex/regcomp
.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo TSRM/TSRM.lo
TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo mai
n/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo
main/fopen_wrappers.lo main/alloca.lo main/php_ini.lo main/SAPI
.lo main/rfc1867.lo main/php_content_types.lo main/strlcpy.lo
main/strlcat.lo main/mergesort.lo main/reentrancy.lo main/php_variable
s.lo main/php_ticks.lo main/streams.lo main/network.lo
main/php_open_temporary_file.lo main/php_logos.lo main/output.lo
main/memory_
streams.lo main/user_streams.lo Zend/zend_language_parser.lo
Zend/zend_language_scanner.lo Zend/zend_ini_parser.lo
Zend/zend_ini_sca
nner.lo Zend/zend_alloc.lo Zend/zend_compile.lo Zend/zend_constants.lo
Zend/zend_dynamic_array.lo Zend/zend_execute_API.lo Zend/zend
_highlight.lo Zend/zend_llist.lo Zend/zend_opcode.lo
Zend/zend_operators.lo Zend/zend_ptr_stack.lo Zend/zend_stack.lo
Zend/zend_vari
ables.lo Zend/zend.lo Zend/zend_API.lo Zend/zend_extensions.lo
Zend/zend_hash.lo Zend/zend_list.lo Zend/zend_indent.lo Zend/zend_bui
ltin_functions.lo Zend/zend_sprintf.lo Zend/zend_ini.lo
Zend/zend_qsort.lo Zend/zend_multibyte.lo Zend/zend_execute.lo
sapi/nsapi/ns
api.lo main/internal_functions.lo -lgd -lt1 -lttf -lX11 -lXpm -lpng -lz
-ljpeg -lbz2 -lz -lcrypt -lm -lnsl -lpthread -lcrypt  -o lib
php4.la

*** Warning: This library needs some functionality provided by
-lcrypt.
*** I have the capability to make that library automatically link in
when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: This library needs some functionality provided by
-lcrypt.
*** I have the capability to make that library automatically link in
when
*** you li

#19292 [Com]: random error: open_basedir restriction in effect. File is in wrong directory

2003-02-05 Thread birdman_

 ID:   19292
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: Apache related
 Operating System: linux
 PHP Version:  4.2.3,4.3.0
 New Comment:

Have/Had this problem on a Redhat7.1, Apache 1.3.27 and
- php 4.2.3
- php 4.3.0

Finally the solution was to include the '/usr/local/lib/php' to the
open_basedir ruleset, cause of PHP tries to look up the included files
there...somehow and although it's not there after all.

e.g. open_basedir = /wwwroot:/usr/local/lib/php


Previous Comments:


[2003-02-03 11:07:54] [EMAIL PROTECTED]

I have about the same problem, I use a restrictive open_basedir by
default, but turn it off for certain vhosts:

php_admin_value open_basedir / 

This has always worked for me in 4.2.3, but after upgrading to 4.3.0 I
get open_basedir errors (no changes to php.ini):

-->

Warning: Unknown(): open_basedir restriction in effect.
File(/var/www/hostname/root/admin/phpinfo.php) is not within the
allowed path(s): (/) in Unknown on line 0

Warning: Unknown(/var/www/hostname/root/admin/phpinfo.php): failed to
create stream: Operation not permitted in Unknown on line 0

Warning: Unknown(): Failed opening
'/var/www/hostname/root/admin/phpinfo.php' for inclusion
(include_path='.:/usr/local/lib/php') in Unknown on line 0

-->

This is persistent for me on FreeBSD 4.7-STABLE:

-->

Build Date  Feb 3 2003 14:35:44  
Configure Command  './configure' '--with-apxs=/usr/local/sbin/apxs'
'--with-config-file-path=/usr/local/etc' '--enable-versioning'
'--with-regex=system' '--without-gd' '--without-mysql'
'--with-gd=/usr/local' '--enable-gd-native-ttf'
'--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr/local' '--with-zlib' '--with-bz2=/usr'
'--with-mcrypt=/usr/local' '--with-mhash=/usr/local'
'--with-mysql=/usr/local' '--with-expat-dir=/usr/local'
'--with-ming=/usr/local' '--enable-trans-sid' '--prefix=/usr/local'
'i386-portbld-freebsd4.7'  

-->



[2003-01-30 09:33:52] [EMAIL PROTECTED]

Same problem, suse 8.1 , apache 1.3.26.
selfcompiled php 4.2.3 updated from 4.2.2



[2003-01-24 09:11:18] [EMAIL PROTECTED]

I use redhat8.0   and upgrade from php4.12 to php4.2.3

and the file have open_basedir restriction,  and after
all the include file is inside the basedir not outside



[2003-01-20 13:16:28] [EMAIL PROTECTED]

Same problem FreeBSD 4.7p3 PHP 4.3.0 PHP 4.2.3 Apache 1.3.27 (bug
20190)



[2003-01-17 13:57:47] [EMAIL PROTECTED]

The same probleme is in php4-STABLE-200301171630

Please correct that

Warning: Unknown(): open_basedir restriction in effect.
File(/home/ovh/www/forum/list.php) is not within the allowed path(s):
(/home/users/xiaoping) in Unknown on line 0

Warning: Unknown(/home/ovh/www/forum/list.php): failed to create
stream: Operation not permitted in Unknown on line 0

Warning: (null)() [function.include]: Failed opening
'/home/ovh/www/forum/list.php' for inclusion
(include_path='.:/upload/') in Unknown on line 0



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

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

#22056 [Fbk->Opn]: when using Command-Line-Interpreter getting sgementation fault on Exit

2003-02-05 Thread php

 ID:   22056
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: InterBase related
 Operating System: Linux (Kernel 2.4.20)
 PHP Version:  4.3.0
 New Comment:

Here's the backtrace requested:

#0  0x40742df0 in ?? ()
#1  0x0816c8ec in main (argc=2, argv=0xbb74) at
/usr/src/php4-STABLE-200302042030/sapi/cli/php_cli.c:820
#2  0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6


Previous Comments:


[2003-02-05 10:44:26] [EMAIL PROTECTED]

Please compile your PHP with --enable-debug flag and generate the
backtrace of the crash. Once you have the backtrace please post it
here.



[2003-02-04 17:05:23] [EMAIL PROTECTED]

installed supplied snapshot - 4.3.1-dev

Unfortunatly i get the same results!



[2003-02-04 15:36:02] [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





[2003-02-04 15:09:06] [EMAIL PROTECTED]

When executing a script from command line (php -f script.php) i get a
segmentation fault after successfully finishing the script.
This only happens, when using the ibase functions. Replacing them with
mysql everything works fine.
executing the script by calling it from a browser it works too.
This only happens, when using command-line-interface and
ibase-functions.

tried the following with same result:
- using ibase_prepare, ibase_execute instead of ibase_query
- explicit start and commit of transactions
- ibase_pconnect instead of ibase_connect

Here's the script i use:

http://gateway/accounting/ip.cgi";);
 $hnd=fopen("ip.cgi","r");
 If ($link=ibase_connect("bogus.gdb","xx","xx","WIN1250")) {
  while (!feof($hnd)) {
   If ($buf=fgets($hnd)) {
$src="";
$dst="";
$bytes="0";
$pack="0";
$buf=trim($buf);
if ($buf<>"") {
 list($src,$dst,$bytes,$pack,$rest)=split(" ",$buf,5);
 $sql="INSERT INTO AcctInfo(SRC,DST,Bytes,Packets) VALUES
('$src','$dst',$bytes,$pack)";
 ibase_query($link,$sql);
}
   }
  }
  ibase_close($link);
 }
 fclose($hnd);
 unlink("ip.cgi");
php?>




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

#22073 [Opn]: --with-mcrypt won't compile

 ID:   22073
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Compile Failure
 Operating System: Red Hat Linux 8.0
 PHP Version:  4.3.0
 New Comment:

Sorry, I forgot to answer you question about mcrypt version.

# libmcrypt-config --version
2.5.6


Previous Comments:


[2003-02-05 10:55:26] [EMAIL PROTECTED]

I am not using mcrypt. I am only using libmcrypt (as per the PHP
documentation). The version is 2.5.6

> When you are using the --with-mcrypt=../libmcrypt-2.5.6/, does it
still
try to open /usr/local/include/mcrypt.h?

Uh ... don't know. How do I find the answer for you?

I followed your suggestions, here is the result:

# cd /usr/src/php-4.3.0/
# rm config.cache 
# make clean
find . -name \*.lo -o -name \*.o | xargs rm -f
find . -name \*.la -o -name \*.a | xargs rm -f 
find . -name \*.so | xargs rm -f
find . -name .libs -a -type d|xargs rm -rf
rm -f libphp4.la sapi/cli/php libphp4.la modules/* libs/*
# ./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt  
[...]
Configuring extensions
[...]
checking for mcrypt support... yes
checking for mcrypt_module_open in -lmcrypt... no
checking for init_mcrypt in -lmcrypt... yes

# make
gcc  -Iext/ctype/ -I/usr/src/php-4.3.0/ext/ctype/ -DPHP_ATOM_INC
-I/usr/src/php-4.3.0/include -I/usr/src/php-4.3.0/main
-I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend -I/usr/local/include
-I/usr/src/php-4.3.0/ext/xml/expat  -I/usr/src/php-4.3.0/TSRM  -g -O2 
-c /usr/src/php-4.3.0/ext/ctype/ctype.c -o ext/ctype/ctype.o  && echo >
ext/ctype/ctype.lo
cc1: warning: changing search order for system directory
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system
directory
gcc  -Iext/mcrypt/ -I/usr/src/php-4.3.0/ext/mcrypt/ -DPHP_ATOM_INC
-I/usr/src/php-4.3.0/include -I/usr/src/php-4.3.0/main
-I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend -I/usr/local/include
-I/usr/src/php-4.3.0/ext/xml/expat  -I/usr/src/php-4.3.0/TSRM  -g -O2 
-c /usr/src/php-4.3.0/ext/mcrypt/mcrypt.c -o ext/mcrypt/mcrypt.o  &&
echo > ext/mcrypt/mcrypt.lo
cc1: warning: changing search order for system directory
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system
directory
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:229:1: warning: "MCRYPT_FAILED"
redefined
In file included from /usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:34:
/usr/local/include/mcrypt.h:31:1: warning: this is the location of the
previous definition
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c: In function
`zm_startup_mcrypt':
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:279: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:280: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: `MCRYPT_BLOWFISH_128'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: (Each undeclared identifier
is reported only once
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: for each function it
appears in.)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:282: `MCRYPT_BLOWFISH_192'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:283: `MCRYPT_BLOWFISH_256'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:284: `MCRYPT_BLOWFISH_448'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:285: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:286: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:287: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:288: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:289: `MCRYPT_IDEA' undeclared
(first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:290: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:291: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:292: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:293: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:294: `MCRYPT_RC2_128' undeclared
(first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:295: `MCRYPT_RC2_256' undecla

#19119 [Opn->Csd]: curl_exec called twice

 ID:   19119
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: Linux 2.4.7-10 (RedHat 7.2)
 PHP Version:  4.3.0-dev / 4.2.3-dev
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2002-10-27 18:54:24] [EMAIL PROTECTED]

not a bug a limitation - marked as a feature request...



[2002-09-25 09:55:39] [EMAIL PROTECTED]

sorry, misread



[2002-09-25 09:39:17] [EMAIL PROTECTED]

Not a bug in PHP -> bogus



[2002-09-09 11:19:49] [EMAIL PROTECTED]

current cURL extension limitation...  You can't reuse the
same handle...



[2002-08-27 14:22:23] [EMAIL PROTECTED]

Got the same results..




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

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

#19817 [Opn->Fbk]: ImageCreateFromGD2() doesnt recognize uncompressed .gd2 images

 ID:   19817
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Feature/Change Request
 Operating System: Darwin 6.1 (Mac 10.2.1)
 PHP Version:  4CVS-2002-10-08
 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:


[2002-10-29 21:40:12] [EMAIL PROTECTED]

This is more of a feature request.  As far as I know nobody is working
on it.  I certainly don't need this functionality.  Feel free to submit
a patch.



[2002-10-29 21:38:19] [EMAIL PROTECTED]

Problem still exists using latest CVS snap and GD 2.0.4. (I thought I
would mention it 'cause I have seen lots of GD work being done in
both.)



[2002-10-19 21:06:21] [EMAIL PROTECTED]

FYI: this bug still exists in the latest CVS snapshot.



[2002-10-11 06:15:54] [EMAIL PROTECTED]

Did test http://144.92.10.251/riverdata/images/uncompressed_med.gd2 and
got the following:

$ php 19817.php
Error from seek: 25

Warning: imagecreatefromgd2part()
[http://www.php.net/function.imagecreatefromgd2part]:
'uncompressed_med.gd2' is not a valid GD2 file in
/home/mfischer/src/php/bugs/gd/19817.php on line 7
/home/mfischer/src/php/bugs/gd/19817.php(7) : Warning -
imagecreatefromgd2part()
[http://www.php.net/function.imagecreatefromgd2part]:
'uncompressed_med.gd2' is not a valid GD2 file

Warning: imagecopy(): supplied argument is not a valid Image resource
in /home/mfischer/src/php/bugs/gd/19817.php on line 10
/home/mfischer/src/php/bugs/gd/19817.php(10) : Warning - imagecopy():
supplied argument is not a valid Image resource

Warning: imagedestroy(): supplied argument is not a valid Image
resource in /home/mfischer/src/php/bugs/gd/19817.php on line 11
/home/mfischer/src/php/bugs/gd/19817.php(11) : Warning -
imagedestroy(): supplied argument is not a valid Image resource
PNG

IHDR vpkIDATxí×1 À°Ïà¢$ [binary scumm]


The interesting thing I think is "Error from seek: 25" which actually
comes from the bundled libgd from libgd/gd_gd2.c from
gdImageCreateFromGd2PartCtx, line 584:

  if (gdSeek (in, dpos) != 0)
{
  printf ("Error from seek: %d\n", errno);
  goto fail2;
};


Error code 25 means "Inappropriate ioctl for device", no idea why this
happens though.

Maybe a problem related from mixing PHP Streams and native access to
FILE fd's ?



[2002-10-10 11:10:38] [EMAIL PROTECTED]

s, don't prove  to me that I need more sleep than I'm getting ;)

okay nm that bt request... 



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

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

#22073 [Fbk->Opn]: --with-mcrypt won't compile

 ID:   22073
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: Red Hat Linux 8.0
 PHP Version:  4.3.0
 New Comment:

I am not using mcrypt. I am only using libmcrypt (as per the PHP
documentation). The version is 2.5.6

> When you are using the --with-mcrypt=../libmcrypt-2.5.6/, does it
still
try to open /usr/local/include/mcrypt.h?

Uh ... don't know. How do I find the answer for you?

I followed your suggestions, here is the result:

# cd /usr/src/php-4.3.0/
# rm config.cache 
# make clean
find . -name \*.lo -o -name \*.o | xargs rm -f
find . -name \*.la -o -name \*.a | xargs rm -f 
find . -name \*.so | xargs rm -f
find . -name .libs -a -type d|xargs rm -rf
rm -f libphp4.la sapi/cli/php libphp4.la modules/* libs/*
# ./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt  
[...]
Configuring extensions
[...]
checking for mcrypt support... yes
checking for mcrypt_module_open in -lmcrypt... no
checking for init_mcrypt in -lmcrypt... yes

# make
gcc  -Iext/ctype/ -I/usr/src/php-4.3.0/ext/ctype/ -DPHP_ATOM_INC
-I/usr/src/php-4.3.0/include -I/usr/src/php-4.3.0/main
-I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend -I/usr/local/include
-I/usr/src/php-4.3.0/ext/xml/expat  -I/usr/src/php-4.3.0/TSRM  -g -O2 
-c /usr/src/php-4.3.0/ext/ctype/ctype.c -o ext/ctype/ctype.o  && echo >
ext/ctype/ctype.lo
cc1: warning: changing search order for system directory
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system
directory
gcc  -Iext/mcrypt/ -I/usr/src/php-4.3.0/ext/mcrypt/ -DPHP_ATOM_INC
-I/usr/src/php-4.3.0/include -I/usr/src/php-4.3.0/main
-I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend -I/usr/local/include
-I/usr/src/php-4.3.0/ext/xml/expat  -I/usr/src/php-4.3.0/TSRM  -g -O2 
-c /usr/src/php-4.3.0/ext/mcrypt/mcrypt.c -o ext/mcrypt/mcrypt.o  &&
echo > ext/mcrypt/mcrypt.lo
cc1: warning: changing search order for system directory
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system
directory
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:229:1: warning: "MCRYPT_FAILED"
redefined
In file included from /usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:34:
/usr/local/include/mcrypt.h:31:1: warning: this is the location of the
previous definition
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c: In function
`zm_startup_mcrypt':
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:279: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:280: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: `MCRYPT_BLOWFISH_128'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: (Each undeclared identifier
is reported only once
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: for each function it
appears in.)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:282: `MCRYPT_BLOWFISH_192'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:283: `MCRYPT_BLOWFISH_256'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:284: `MCRYPT_BLOWFISH_448'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:285: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:286: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:287: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:288: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:289: `MCRYPT_IDEA' undeclared
(first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:290: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:291: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:292: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:293: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:294: `MCRYPT_RC2_128' undeclared
(first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:295: `MCRYPT_RC2_256' undeclared
(first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:296: `MCRYPT_RC2_1024'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:297: `MCRYPT_RC4' undeclared
(fi

#22018 [Opn->Ana]: daylight savings time parameter works wrong

2003-02-05 Thread k . schroeder

 ID:   22018
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Analyzed
 Bug Type: Date/time related
 Operating System: Windows 2000 Server
 PHP Version:  4CVS-2003-02-02 (stable)
-Assigned To:  
+Assigned To:  k.schroeder


Previous Comments:


[2003-02-02 15:27:37] [EMAIL PROTECTED]

ext/standard/tests/time/003.phpt fails on W2k server:

diff:
008- 2000-05-29 13:00:00
008+ 2000-05-29 12:00:00
009- 2000-05-29 12:00:00
009+ 2000-05-29 11:00:00
014- 2000-04-29 13:00:00
014+ 2000-04-29 12:00:00
015- 2000-04-29 12:00:00
015+ 2000-04-29 11:00:00

coresponding lines:
echo date("Y-m-d H:i:s", mktime(12,0,0,3,+90,2000,0))."\n";
echo date("Y-m-d H:i:s", mktime(12,0,0,3,+90,2000,1))."\n";
echo date("Y-m-d H:i:s", mktime(12,0,0,5,-1,2000,0))."\n";
echo date("Y-m-d H:i:s", mktime(12,0,0,5,-1,2000,1))."\n";

this lines produce the expected result:
echo date("Y-m-d H:i:s", mktime(12,0,0,3,+90,2000,-1))."\n";
echo date("Y-m-d H:i:s", mktime(12,0,0,5,-90,2000,-1))."\n";
echo date("Y-m-d H:i:s", mktime(12,0,0,5,-90,2000,0))."\n";
echo date("Y-m-d H:i:s", mktime(12,0,0,5,-90,2000,1))."\n";
echo date("Y-m-d H:i:s", mktime(12,0,0,5,-1,2000,-1))."\n";





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

#22073 [Opn->Fbk]: --with-mcrypt won't compile

 ID:   22073
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: Red Hat Linux 8.0
 PHP Version:  4.3.0
 New Comment:

What is the version of mcrypt you are currently
running,(libmcrypt-config --version) should provide this information.
When you are using the --with-mcrypt=../libmcrypt-2.5.6/, does it still
try to open /usr/local/include/mcrypt.h?


Previous Comments:


[2003-02-05 10:45:02] [EMAIL PROTECTED]

I did both before submitting the report. I did a "make distclean" and
"rm config.cache". For every set of options or possible way of
compiling/configuring I always do both and yet get this error ...

Please re-open this bug.

Is there anything else you would like me to try?

Thanks



[2003-02-05 10:42:58] [EMAIL PROTECTED]

The fact that certain options appear cached during the configure phase
could be the problem. Before doing compile run 'make clean' or remove
config.cache. If the bug persists please re-open the bug report.



[2003-02-05 10:17:42] [EMAIL PROTECTED]

I also tried using minimal configure option but still got the same
error with any of the following:

./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt

./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt=/usr/local

./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt=../libmcrypt-2.5.6/



[2003-02-05 09:46:26] [EMAIL PROTECTED]

First off, the documentation on how to install mcrypt support for PHP
is severely lacking so I'm sorry if this is a stupid bug report. (I am
also submitting a documentation bug report to points this out :)

I asked on the newsgroups and tried the several different methods
suggested for installing mcrypt support but they all failed at one
stage or another.

The furthest I can get is to a PHP make, but that always fails.

I cleaned my system off all old installations and downloaded libmcrypt
2.5.6, did:

./configure
make && make install

with no errors:

To make sure all old files where gone and I have only the new
installation files:

[root@host110 php-4.3.0]# locate mcrypt.h
/usr/local/include/mcrypt.h
/usr/src/php-4.3.0/ext/mcrypt/php_mcrypt.h
/usr/src/libmcrypt-2.5.6/lib/mcrypt.h
/usr/src/libmcrypt-2.5.6/lib/mcrypt.h.in


I can ./configure PHP successfully but when I try and make I get this
very long error. is this a PHP bug or did I miss something along the
installation process:

./configure --with-pgsql=/usr/local/psql/ --without-mysql
--with-apache=../apache_1.3.27/ --enable-mbstring
--enable-mbstring-enc-trans --enable-mbregex --with-mcrypt

Works fine, giving:
Running system checks
[...]
checking for crypt.h... (cached) yes
[...]
checking for crypt... (cached) no
[...]
checking for crypt in -lcrypt... (cached) yes
[...]
Configuring extensions
[...]
checking for mcrypt support... yes
checking for mcrypt_module_open in -lmcrypt... (cached) no
checking for init_mcrypt in -lmcrypt... (cached) yes
[...]
checking for standard DES crypt... (cached) yes
checking for extended DES crypt... (cached) no
checking for MD5 crypt... (cached) yes
checking for Blowfish crypt... (cached) no

[root@host110 php-4.3.0]# make
gcc  -Iext/mcrypt/ -I/usr/src/php-4.3.0/ext/mcrypt/ -DPHP_ATOM_INC
-I/usr/src/php-4.3.0/include -I/usr/src/php-4.3.0/main
-I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend -I/usr/local/include
-I/usr/local/psql//include -I/usr/src/php-4.3.0/ext/xml/expat 
-I/usr/src/php-4.3.0/TSRM  -g -O2  -c
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c -o ext/mcrypt/mcrypt.o  && echo
> ext/mcrypt/mcrypt.lo
cc1: warning: changing search order for system directory
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system
directory
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:229:1: warning: "MCRYPT_FAILED"
redefined
In file included from /usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:34:
/usr/local/include/mcrypt.h:31:1: warning: this is the location of the
previous definition
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c: In function
`zm_startup_mcrypt':
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:279: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:280: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: `MCRYPT_BLOWFISH_128'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: (Each undeclared identifier
is reported only once
/usr/src/php-4.3.0/ext/mcrypt/mcr

#22073 [Fbk->Opn]: --with-mcrypt won't compile

 ID:   22073
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: Red Hat Linux 8.0
 PHP Version:  4.3.0
 New Comment:

I did both before submitting the report. I did a "make distclean" and
"rm config.cache". For every set of options or possible way of
compiling/configuring I always do both and yet get this error ...

Please re-open this bug.

Is there anything else you would like me to try?

Thanks


Previous Comments:


[2003-02-05 10:42:58] [EMAIL PROTECTED]

The fact that certain options appear cached during the configure phase
could be the problem. Before doing compile run 'make clean' or remove
config.cache. If the bug persists please re-open the bug report.



[2003-02-05 10:17:42] [EMAIL PROTECTED]

I also tried using minimal configure option but still got the same
error with any of the following:

./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt

./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt=/usr/local

./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt=../libmcrypt-2.5.6/



[2003-02-05 09:46:26] [EMAIL PROTECTED]

First off, the documentation on how to install mcrypt support for PHP
is severely lacking so I'm sorry if this is a stupid bug report. (I am
also submitting a documentation bug report to points this out :)

I asked on the newsgroups and tried the several different methods
suggested for installing mcrypt support but they all failed at one
stage or another.

The furthest I can get is to a PHP make, but that always fails.

I cleaned my system off all old installations and downloaded libmcrypt
2.5.6, did:

./configure
make && make install

with no errors:

To make sure all old files where gone and I have only the new
installation files:

[root@host110 php-4.3.0]# locate mcrypt.h
/usr/local/include/mcrypt.h
/usr/src/php-4.3.0/ext/mcrypt/php_mcrypt.h
/usr/src/libmcrypt-2.5.6/lib/mcrypt.h
/usr/src/libmcrypt-2.5.6/lib/mcrypt.h.in


I can ./configure PHP successfully but when I try and make I get this
very long error. is this a PHP bug or did I miss something along the
installation process:

./configure --with-pgsql=/usr/local/psql/ --without-mysql
--with-apache=../apache_1.3.27/ --enable-mbstring
--enable-mbstring-enc-trans --enable-mbregex --with-mcrypt

Works fine, giving:
Running system checks
[...]
checking for crypt.h... (cached) yes
[...]
checking for crypt... (cached) no
[...]
checking for crypt in -lcrypt... (cached) yes
[...]
Configuring extensions
[...]
checking for mcrypt support... yes
checking for mcrypt_module_open in -lmcrypt... (cached) no
checking for init_mcrypt in -lmcrypt... (cached) yes
[...]
checking for standard DES crypt... (cached) yes
checking for extended DES crypt... (cached) no
checking for MD5 crypt... (cached) yes
checking for Blowfish crypt... (cached) no

[root@host110 php-4.3.0]# make
gcc  -Iext/mcrypt/ -I/usr/src/php-4.3.0/ext/mcrypt/ -DPHP_ATOM_INC
-I/usr/src/php-4.3.0/include -I/usr/src/php-4.3.0/main
-I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend -I/usr/local/include
-I/usr/local/psql//include -I/usr/src/php-4.3.0/ext/xml/expat 
-I/usr/src/php-4.3.0/TSRM  -g -O2  -c
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c -o ext/mcrypt/mcrypt.o  && echo
> ext/mcrypt/mcrypt.lo
cc1: warning: changing search order for system directory
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system
directory
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:229:1: warning: "MCRYPT_FAILED"
redefined
In file included from /usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:34:
/usr/local/include/mcrypt.h:31:1: warning: this is the location of the
previous definition
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c: In function
`zm_startup_mcrypt':
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:279: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:280: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: `MCRYPT_BLOWFISH_128'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: (Each undeclared identifier
is reported only once
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: for each function it
appears in.)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:282: `MCRYPT_BLOWFISH_192'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:283: `MCRYPT_BLOWFISH_256'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:284: `MCRYPT_BLOWFISH_448'
undeclared (first use

#22056 [Opn->Fbk]: when using Command-Line-Interpreter getting sgementation fault on Exit

 ID:   22056
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: InterBase related
 Operating System: Linux (Kernel 2.4.20)
 PHP Version:  4.3.0
 New Comment:

Please compile your PHP with --enable-debug flag and generate the
backtrace of the crash. Once you have the backtrace please post it
here.


Previous Comments:


[2003-02-04 17:05:23] [EMAIL PROTECTED]

installed supplied snapshot - 4.3.1-dev

Unfortunatly i get the same results!



[2003-02-04 15:36:02] [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





[2003-02-04 15:09:06] [EMAIL PROTECTED]

When executing a script from command line (php -f script.php) i get a
segmentation fault after successfully finishing the script.
This only happens, when using the ibase functions. Replacing them with
mysql everything works fine.
executing the script by calling it from a browser it works too.
This only happens, when using command-line-interface and
ibase-functions.

tried the following with same result:
- using ibase_prepare, ibase_execute instead of ibase_query
- explicit start and commit of transactions
- ibase_pconnect instead of ibase_connect

Here's the script i use:

http://gateway/accounting/ip.cgi";);
 $hnd=fopen("ip.cgi","r");
 If ($link=ibase_connect("bogus.gdb","xx","xx","WIN1250")) {
  while (!feof($hnd)) {
   If ($buf=fgets($hnd)) {
$src="";
$dst="";
$bytes="0";
$pack="0";
$buf=trim($buf);
if ($buf<>"") {
 list($src,$dst,$bytes,$pack,$rest)=split(" ",$buf,5);
 $sql="INSERT INTO AcctInfo(SRC,DST,Bytes,Packets) VALUES
('$src','$dst',$bytes,$pack)";
 ibase_query($link,$sql);
}
   }
  }
  ibase_close($link);
 }
 fclose($hnd);
 unlink("ip.cgi");
php?>




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

#22073 [Opn->Fbk]: --with-mcrypt won't compile

 ID:   22073
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: Red Hat Linux 8.0
 PHP Version:  4.3.0
 New Comment:

The fact that certain options appear cached during the configure phase
could be the problem. Before doing compile run 'make clean' or remove
config.cache. If the bug persists please re-open the bug report.


Previous Comments:


[2003-02-05 10:17:42] [EMAIL PROTECTED]

I also tried using minimal configure option but still got the same
error with any of the following:

./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt

./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt=/usr/local

./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt=../libmcrypt-2.5.6/



[2003-02-05 09:46:26] [EMAIL PROTECTED]

First off, the documentation on how to install mcrypt support for PHP
is severely lacking so I'm sorry if this is a stupid bug report. (I am
also submitting a documentation bug report to points this out :)

I asked on the newsgroups and tried the several different methods
suggested for installing mcrypt support but they all failed at one
stage or another.

The furthest I can get is to a PHP make, but that always fails.

I cleaned my system off all old installations and downloaded libmcrypt
2.5.6, did:

./configure
make && make install

with no errors:

To make sure all old files where gone and I have only the new
installation files:

[root@host110 php-4.3.0]# locate mcrypt.h
/usr/local/include/mcrypt.h
/usr/src/php-4.3.0/ext/mcrypt/php_mcrypt.h
/usr/src/libmcrypt-2.5.6/lib/mcrypt.h
/usr/src/libmcrypt-2.5.6/lib/mcrypt.h.in


I can ./configure PHP successfully but when I try and make I get this
very long error. is this a PHP bug or did I miss something along the
installation process:

./configure --with-pgsql=/usr/local/psql/ --without-mysql
--with-apache=../apache_1.3.27/ --enable-mbstring
--enable-mbstring-enc-trans --enable-mbregex --with-mcrypt

Works fine, giving:
Running system checks
[...]
checking for crypt.h... (cached) yes
[...]
checking for crypt... (cached) no
[...]
checking for crypt in -lcrypt... (cached) yes
[...]
Configuring extensions
[...]
checking for mcrypt support... yes
checking for mcrypt_module_open in -lmcrypt... (cached) no
checking for init_mcrypt in -lmcrypt... (cached) yes
[...]
checking for standard DES crypt... (cached) yes
checking for extended DES crypt... (cached) no
checking for MD5 crypt... (cached) yes
checking for Blowfish crypt... (cached) no

[root@host110 php-4.3.0]# make
gcc  -Iext/mcrypt/ -I/usr/src/php-4.3.0/ext/mcrypt/ -DPHP_ATOM_INC
-I/usr/src/php-4.3.0/include -I/usr/src/php-4.3.0/main
-I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend -I/usr/local/include
-I/usr/local/psql//include -I/usr/src/php-4.3.0/ext/xml/expat 
-I/usr/src/php-4.3.0/TSRM  -g -O2  -c
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c -o ext/mcrypt/mcrypt.o  && echo
> ext/mcrypt/mcrypt.lo
cc1: warning: changing search order for system directory
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system
directory
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:229:1: warning: "MCRYPT_FAILED"
redefined
In file included from /usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:34:
/usr/local/include/mcrypt.h:31:1: warning: this is the location of the
previous definition
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c: In function
`zm_startup_mcrypt':
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:279: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:280: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: `MCRYPT_BLOWFISH_128'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: (Each undeclared identifier
is reported only once
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: for each function it
appears in.)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:282: `MCRYPT_BLOWFISH_192'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:283: `MCRYPT_BLOWFISH_256'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:284: `MCRYPT_BLOWFISH_448'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:285: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:286: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:287: warning: passing arg 3 of
`zend_register_long_constant'

#22065 [Opn->Fbk]: file() function

 ID:   22065
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: Windows 2000 server
 PHP Version:  4.3.0
 New Comment:

Do you have open_basedir or safe_mode enabled?


Previous Comments:


[2003-02-05 02:48:23] [EMAIL PROTECTED]

Error log fills with warnings abount the file() function.

Apache 2.0/34
Using php module version 4.3.0 rather than cgi.
Errors.log shows:-
[05-Feb-2003 08:33:45] PHP Warning:  file(d:/temp/ht1/050203.ht1) [function.file]: failed to
create stream: Permission denied in d:\Apache
Group\Apache2\htdocs\fa_tools_ht.php on line 103

Code:-
   if(file_exists($file1)==FALSE) die("File1 does not exist");
   if(is_readable($file1)==FALSE) die("File1 not readable");
   // parse files into arrays
   $file_array1=file($file1); //WARNING HERE

   if($file_array1==null) die("Permission denied to open file");




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

#22074 [NEW]: Fix for "output line too long" problem

2003-02-05 Thread lhecking

From: [EMAIL PROTECTED]
Operating system: Solaris
PHP version:  4.3.0
PHP Bug Type: Compile Failure
Bug description:  Fix for "output line too long" problem

Many users, including myself, have report compile failures on
Solaris due to the limitations of the native sed tool. All
reporters were pointed to GNU sed, but part of the problem is
that the sed test in php's configure is broken and declares
even the native Solaris sed "working".

Solution: upgrade to libtool 1.4.3, which includes a much
better test for sed. I.e. re-run aclocal, and copy ltmain.sh
over from PREFIX/share/libtool.

If this particular problem is the only reason of existence
for PHP_PROG_SED, this macro can safely be removed after
upgrading to libtool 1.4.3.

-- 
Edit bug report at http://bugs.php.net/?id=22074&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22074&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22074&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22074&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22074&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22074&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22074&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22074&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22074&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22074&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22074&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22074&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22074&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22074&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22074&r=gnused

#22073 [Com]: --with-mcrypt won't compile

 ID:   22073
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Compile Failure
 Operating System: Red Hat Linux 8.0
 PHP Version:  4.3.0
 New Comment:

I also tried using minimal configure option but still got the same
error with any of the following:

./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt

./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt=/usr/local

./configure --without-mysql --with-apache=../apache_1.3.27/
--with-mcrypt=../libmcrypt-2.5.6/


Previous Comments:


[2003-02-05 09:46:26] [EMAIL PROTECTED]

First off, the documentation on how to install mcrypt support for PHP
is severely lacking so I'm sorry if this is a stupid bug report. (I am
also submitting a documentation bug report to points this out :)

I asked on the newsgroups and tried the several different methods
suggested for installing mcrypt support but they all failed at one
stage or another.

The furthest I can get is to a PHP make, but that always fails.

I cleaned my system off all old installations and downloaded libmcrypt
2.5.6, did:

./configure
make && make install

with no errors:

To make sure all old files where gone and I have only the new
installation files:

[root@host110 php-4.3.0]# locate mcrypt.h
/usr/local/include/mcrypt.h
/usr/src/php-4.3.0/ext/mcrypt/php_mcrypt.h
/usr/src/libmcrypt-2.5.6/lib/mcrypt.h
/usr/src/libmcrypt-2.5.6/lib/mcrypt.h.in


I can ./configure PHP successfully but when I try and make I get this
very long error. is this a PHP bug or did I miss something along the
installation process:

./configure --with-pgsql=/usr/local/psql/ --without-mysql
--with-apache=../apache_1.3.27/ --enable-mbstring
--enable-mbstring-enc-trans --enable-mbregex --with-mcrypt

Works fine, giving:
Running system checks
[...]
checking for crypt.h... (cached) yes
[...]
checking for crypt... (cached) no
[...]
checking for crypt in -lcrypt... (cached) yes
[...]
Configuring extensions
[...]
checking for mcrypt support... yes
checking for mcrypt_module_open in -lmcrypt... (cached) no
checking for init_mcrypt in -lmcrypt... (cached) yes
[...]
checking for standard DES crypt... (cached) yes
checking for extended DES crypt... (cached) no
checking for MD5 crypt... (cached) yes
checking for Blowfish crypt... (cached) no

[root@host110 php-4.3.0]# make
gcc  -Iext/mcrypt/ -I/usr/src/php-4.3.0/ext/mcrypt/ -DPHP_ATOM_INC
-I/usr/src/php-4.3.0/include -I/usr/src/php-4.3.0/main
-I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend -I/usr/local/include
-I/usr/local/psql//include -I/usr/src/php-4.3.0/ext/xml/expat 
-I/usr/src/php-4.3.0/TSRM  -g -O2  -c
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c -o ext/mcrypt/mcrypt.o  && echo
> ext/mcrypt/mcrypt.lo
cc1: warning: changing search order for system directory
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system
directory
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:229:1: warning: "MCRYPT_FAILED"
redefined
In file included from /usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:34:
/usr/local/include/mcrypt.h:31:1: warning: this is the location of the
previous definition
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c: In function
`zm_startup_mcrypt':
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:279: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:280: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: `MCRYPT_BLOWFISH_128'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: (Each undeclared identifier
is reported only once
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: for each function it
appears in.)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:282: `MCRYPT_BLOWFISH_192'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:283: `MCRYPT_BLOWFISH_256'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:284: `MCRYPT_BLOWFISH_448'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:285: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:286: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:287: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:288: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a
cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:289: `MCRYPT_IDEA' undeclared
(first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:290: warning: passing arg

#22057 [Bgs]: fgets function failure

2003-02-05 Thread pollita

 ID:   22057
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Filesystem function related
 Operating System: win32
 PHP Version:  4.3.0
 New Comment:

Elazizli-

  Let's look at facts together shall we?

1) The behavior (output) of your script changed between 4.2.3 and 4.3.0
without having changed the content of the script or any other server
setting.  Yes, this implies a PHP bug.

2) fgets() is an extremely common function and there have been no
similar reports of it failing as you state.  This implies some quirk in
your setup.

3) Your script *HAS* been tested as thoroughly as possible given the
information you have provided.  It's not failing for anyone else.  This
enforces the conclusion in #2.

So we have a dilema.  Some facts point one way, some point another. 
This means its time for "Debugging 101", hence the questions.

If there's a bug, I'd love to fix it.  So would Ilia or Wez or Sniper,
or any of the others silently following this thread.  But we NEED you
to cooperate.  

Without meaningful feedback all we can do is guess, and everyone's
guess right now seems to be that there's some non presenting bug in
your script which just happened to work with 4.2.3, and that whatever
allowed that buggy code to opperate prior to 4.3.0 was fixed.

Provide *complete* scripts (not scripts that comment '$foo is defined
elsewhere' or 'I do blah later on').

Provide *exact* output.  "An Error Message" is non descript.  Is it a
PHP generated error message?  Is it a webserver generated error
message?  What *IS* the text of the error message?  Do it stop
execution or simply warn?

Looking forward to working with you to improve the quality of PHP.


Previous Comments:


[2003-02-05 03:33:10] [EMAIL PROTECTED]

http://bugs.php.net/how-to-report.php

I tried to ask what error you get..it would help a lot to
know that. Is it some PHP error message?

It's not easy to try guessing what you might mean so please
check your attitude. FYI: 99% of bug reports are actually
support questions which in the end just take our time
out of fixing the real bugs..




[2003-02-05 02:49:52] [EMAIL PROTECTED]

I said I just upgraded to 4.3.0 and kept all settings of server and PHP
same on Windows OS. fgets function stated to give error after upgrade
while working fine with older version. I believe the changes made in
version 4.3.0 regarding file functions are causing this error.

I have been trying to explain simðply, without bothering with script
codes, that fgets function doesn't return requested information in
4.3.0 while working fine in 4.2.3.

My server settings and code has been same for both PHP versions but new
one doesn't work.

Whose time has been wasted? Yours or mine?
>From the first message you didn't get what I meant: server/ php
settings and the code were same except version upgrade to 4.3.0. Yet it
didn't work. I wasted whole day to explain this to so-called experts. 
So why bother with more details. 

Your guys have been treating me as a "dummy guy" looking for manual
information and apparently can't understand basic english unless some
PHP code is sent with it. If something stops working in new version
although it isn't supposed to or intended to do so, THAT IS AN ERROR.
Instead of asking what you need you accused me. I don't have anymore
time to waste with people who have no respect for me.

You don't really even read my messages. Otherwise you wouldn't ask
about an error in my server settings etc. since I reported several
times that everything, including code, was same except upgrading to
4.3.0

The beloved PHP manual mentions only handling binaries better as a
change in fgets function in 4.3.0, not any case of returning wrong data
in this new version.



[2003-02-05 01:59:34] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


"response:"fbc" or something similar."

How about a real error report?
If you can't be bothered to spend the time to give us
precise details, why should we sit here guessing what
your problem is?

Are you sure that your web server isn't sending back data using the
chunked transfer encoding? (read the specs for HTTP 1.1!).

If your code doesn't handle chunked encoding, use HTTP 1.0 instead.

If you are *absolutely* 100% sure that your script isn't broken as far
as HTTP is concerned, how about giving us more details on the remote
server?  Is it somet

#21760 [Com]: socket_read PHP_NORMAL_READ problem

2003-02-05 Thread uce

 ID:   21760
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Sockets related
 Operating System: FreeBSD 4.7
 PHP Version:  4.3.0
 New Comment:

I believe this is caused by a comparison to an uninitialized buffer in
php_read (buffer emalloc'd in socket_read).

Patch:

--- php5/ext/sockets/sockets.c  2003-01-18 19:28:06.0 +
+++ php5-atropine/ext/sockets/sockets.c  2003-02-05 15:43:00.0
+
@@ -288,6 +288,7 @@
 
set_errno(0);
 
+   *t = 0;
while (*t != '\n' && *t != '\r' && n < maxlen) {
if (m > 0) {
t++;


Previous Comments:


[2003-01-19 23:18:44] [EMAIL PROTECTED]

$string = socket_read( $socket, 100, PHP_NORMAL_READ ); will return a
"\n" after several reads, and continue to return "\n" in an infinite
loop rather than the rest of the buffer.

The server it's reading from sends a large multi-line (lines terminated
with "\n") packet (~7500 bytes) in one write() call. After reading
through about half of it with the line above, socket_read will start
returning bad data about 10% - 20% of the time.




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

#22073 [NEW]: --with-mcrypt won't compile

From: [EMAIL PROTECTED]
Operating system: Red Hat Linux 8.0
PHP version:  4.3.0
PHP Bug Type: Compile Failure
Bug description:  --with-mcrypt won't compile

First off, the documentation on how to install mcrypt support for PHP is
severely lacking so I'm sorry if this is a stupid bug report. (I am also
submitting a documentation bug report to points this out :)

I asked on the newsgroups and tried the several different methods
suggested for installing mcrypt support but they all failed at one stage
or another.

The furthest I can get is to a PHP make, but that always fails.

I cleaned my system off all old installations and downloaded libmcrypt
2.5.6, did:

./configure
make && make install

with no errors:

To make sure all old files where gone and I have only the new installation
files:

[root@host110 php-4.3.0]# locate mcrypt.h
/usr/local/include/mcrypt.h
/usr/src/php-4.3.0/ext/mcrypt/php_mcrypt.h
/usr/src/libmcrypt-2.5.6/lib/mcrypt.h
/usr/src/libmcrypt-2.5.6/lib/mcrypt.h.in


I can ./configure PHP successfully but when I try and make I get this very
long error. is this a PHP bug or did I miss something along the
installation process:

./configure --with-pgsql=/usr/local/psql/ --without-mysql
--with-apache=../apache_1.3.27/ --enable-mbstring
--enable-mbstring-enc-trans --enable-mbregex --with-mcrypt

Works fine, giving:
Running system checks
[...]
checking for crypt.h... (cached) yes
[...]
checking for crypt... (cached) no
[...]
checking for crypt in -lcrypt... (cached) yes
[...]
Configuring extensions
[...]
checking for mcrypt support... yes
checking for mcrypt_module_open in -lmcrypt... (cached) no
checking for init_mcrypt in -lmcrypt... (cached) yes
[...]
checking for standard DES crypt... (cached) yes
checking for extended DES crypt... (cached) no
checking for MD5 crypt... (cached) yes
checking for Blowfish crypt... (cached) no

[root@host110 php-4.3.0]# make
gcc  -Iext/mcrypt/ -I/usr/src/php-4.3.0/ext/mcrypt/ -DPHP_ATOM_INC
-I/usr/src/php-4.3.0/include -I/usr/src/php-4.3.0/main
-I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend -I/usr/local/include
-I/usr/local/psql//include -I/usr/src/php-4.3.0/ext/xml/expat 
-I/usr/src/php-4.3.0/TSRM  -g -O2  -c
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c -o ext/mcrypt/mcrypt.o  && echo >
ext/mcrypt/mcrypt.lo
cc1: warning: changing search order for system directory
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system
directory
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:229:1: warning: "MCRYPT_FAILED"
redefined
In file included from /usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:34:
/usr/local/include/mcrypt.h:31:1: warning: this is the location of the
previous definition
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c: In function `zm_startup_mcrypt':
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:279: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:280: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: `MCRYPT_BLOWFISH_128'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: (Each undeclared identifier is
reported only once
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:281: for each function it appears
in.)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:282: `MCRYPT_BLOWFISH_192'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:283: `MCRYPT_BLOWFISH_256'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:284: `MCRYPT_BLOWFISH_448'
undeclared (first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:285: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:286: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:287: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:288: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:289: `MCRYPT_IDEA' undeclared
(first use in this function)
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:290: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:291: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:292: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:293: warning: passing arg 3 of
`zend_register_long_constant' makes integer from pointer without a cast
/usr/src/php-4.3.0/ext/mcrypt/mcrypt.c:294: `MCRY

#14245 [Com]: make install fails on apxs

2003-02-05 Thread gero . waldhausen

 ID:   14245
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Verified
 Bug Type: Compile Failure
 Operating System: AIX 4.3.3
 PHP Version:  4.3.0-dev
 New Comment:

hi folks,

i´m trying my best with apache 1.3.26 and php-4.2.2 and oracle817 but,
...

here is my typing:
./configure --prefix=/usr/local/php-4.2.2 --with-mhash
--with-mcrypt=/usr/local/lib with-pcre-regex --enable-track-vars
--enable-trans-id --enable-sockets --enable-with-zlibs --with-xml
--with-apxs=/usr/apache/bin/apxs --with-mm=/usr/local/mm-1.2.1
--enable-wddx --without-pear --with-mysql=no -with-oci8=/oracle/817_64

the result when i´m trying to make install is:
/usr/local/src/php-4.2.2/build/shtool mkdir -p "/usr/apache/libexec" &&
/usr/apache/bin/apxs -S LIBEXECDIR="/usr/apache/libexec" -i -a -n php4
libs/libphp4.so
[activating module `php4' in /etc/apache/httpd.conf]
cp libs/libphp4.so /usr/apache/libexec/libphp4.so
cp: Zugriff auf libs/libphp4.so nicht möglich
apxs:Break: Command failed with rc=2
*** Error code 1
make: Fatal error: Command failed for target `install-sapi'
Current working directory /usr/local/src/php-4.2.2
*** Error code 1
make: Fatal error: Command failed for target `install-recursive'


What am I doing wrong??


please help

gero


Previous Comments:


[2002-11-26 04:57:08] [EMAIL PROTECTED]

I have a workaround about this bag.
I have installed php 4.2.3 under Oracle AS9i on AIX 4.3.3.
The libphp4.so not is created by make because the libtool have a flag
set to no.
The libtool is created by configure; before you launch make, edit
libtool and set build_libtool_libs=yes.
After launched make, under .libs you find libphp4.so.0:move it under
libs as libphp4.so and run make install.
So, php as apache module work fine.



[2002-09-30 17:12:31] [EMAIL PROTECTED]

Same problem.  AIX 4.3.3.10, GCC 2.95, PHP 4.2.3, Gnu Make 3.79

**
Making install in .
make[1]: Entering directory `/oseda/php-4.2.3'
/oseda/php-4.2.3/build/shtool mkdir -p "/usr/local/apache/libexec" &&
/usr/local/apache/bin/apxs -S 

LIBEXECDIR="/usr/local/apache/libexec" -i -a -n php4 libs/libphp4.so
[activating module `php4' in /usr/local/apache/conf/httpd.conf]
cp libs/libphp4.so /usr/local/apache/libexec/libphp4.so
cp: libs/libphp4.so: A file or directory in the path name does not
exist.
apxs:Break: Command failed with rc=1
make[1]: *** [install-sapi] Error 1
make[1]: Leaving directory `/oseda/php-4.2.3'
make: *** [install-recursive] Error 1
**

The directory "libs" has libphp4.a and libphp4.la only, the directory
".libs" has libphp4.a, .exp, .lai and .so.0 in it.



[2002-07-11 11:23:31] [EMAIL PROTECTED]

reclassified



[2002-07-11 11:23:11] [EMAIL PROTECTED]

This is not fixed. But we know what the problem is and hope
to get it solved for 4.3.0 release.




[2002-07-11 04:38:59] [EMAIL PROTECTED]

There were a lot of fixes done to the build system, the best way to
check it is to try for yourself. I suggest you try the latest snapshot
@ http://snaps.php.net/php4-latest.tar.gz

Derick



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

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

#22070 [Ver]: trans_id: Hidden fields placed incorrectly

 ID:   22070
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Verified
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

Output from http://validator.w3.org: 
Line 7, column 115: document type does not allow element 
"input" here; missing one of "ins", "del", "h1", "h2", 
"h3", "h4", "h5", "h6", "p", "div", "address", "fieldset" 
start-tag 
 
  ...="f78cfab3aa4745920992c99cabedc75f" /> 
  ^ 


Previous Comments:


[2003-02-05 08:33:42] [EMAIL PROTECTED]

When using session.use_trans_sid, a hidden input field containing the
session name and ID is placed right after the  tag. Unfortually,
this makes the HTML invalid if you're using XHTML 1.1, strict XHTML
1.0, or strict HTML 4.0: All input fields (even hidden ones) must be
placed inside a block-level element such as  or .

The solution: When the parser discovers a form on the page, it should
place the hidden field containing the session name + ID right next to
one of the other input fields:

The original page:


  

  


After being processed by the parser:


  

  





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

#22070 [Opn->Ver]: trans_id: Hidden fields placed incorrectly

 ID:   22070
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Verified
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  4.3.0


Previous Comments:


[2003-02-05 08:33:42] [EMAIL PROTECTED]

When using session.use_trans_sid, a hidden input field containing the
session name and ID is placed right after the  tag. Unfortually,
this makes the HTML invalid if you're using XHTML 1.1, strict XHTML
1.0, or strict HTML 4.0: All input fields (even hidden ones) must be
placed inside a block-level element such as  or .

The solution: When the parser discovers a form on the page, it should
place the hidden field containing the session name + ID right next to
one of the other input fields:

The original page:


  

  


After being processed by the parser:


  

  





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

#22072 [NEW]: connection_status() always returning 0

2003-02-05 Thread neil

From: [EMAIL PROTECTED]
Operating system: FREEBSD 4.7-STABLE
PHP version:  4.3.0
PHP Bug Type: *General Issues
Bug description:  connection_status() always returning 0

This bug is effecting the connection_status() function in apache 2.x

Okay, getting back to a long standing bug, which we kind of come to the
conclusion last time that it may be a bug in apache 2.x because it works
in apache 1.

Well time has come on, I have submitted the bug to apache after they fixed
the incorrect bytes logged bug, and this is what they have come up with
:-

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16426

ok, I've grabbed the current php source and looked into sapi_apache2.c.
It's
definitely a php bug. Line 90 shows:

if (ap_pass_brigade(f->next, bb) != APR_SUCCESS) {
php_handle_aborted_connection();
}

which won't match in most cases. Also Line 252 and 498.
AFAICS mod_php should (additionally) check connection->aborted.

(marking this bug invalid again)

-- 
Edit bug report at http://bugs.php.net/?id=22072&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22072&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22072&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22072&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22072&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22072&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22072&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22072&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22072&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22072&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22072&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22072&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22072&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22072&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22072&r=gnused

#22071 [Opn->Bgs]: trans_sid: Incorrect query string parameters

 ID:   22071
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Session related
 Operating System: All, I suppose :)
 PHP Version:  4.3.0
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

arg_separator.output = "&" in php.ini 


Previous Comments:


[2003-02-05 08:48:43] [EMAIL PROTECTED]

session.use_trans_sid: In links that contain a query string, the parser
adds "&PHPSESSID=9292902". However, the "&" should be written as
"&" in order to make it valid HTML.




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

#22071 [NEW]: trans_sid: Incorrect query string parameters

2003-02-05 Thread jonas

From: [EMAIL PROTECTED]
Operating system: All, I suppose :)
PHP version:  4.3.0
PHP Bug Type: Session related
Bug description:  trans_sid: Incorrect query string parameters

session.use_trans_sid: In links that contain a query string, the parser
adds "&PHPSESSID=9292902". However, the "&" should be written as "&"
in order to make it valid HTML.
-- 
Edit bug report at http://bugs.php.net/?id=22071&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22071&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22071&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22071&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22071&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22071&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22071&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22071&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22071&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22071&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22071&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22071&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22071&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22071&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22071&r=gnused

#22070 [NEW]: trans_id: Hidden fields placed incorrectly

2003-02-05 Thread jonas

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.3.0
PHP Bug Type: Session related
Bug description:  trans_id: Hidden fields placed incorrectly

When using session.use_trans_sid, a hidden input field containing the
session name and ID is placed right after the  tag. Unfortually,
this makes the HTML invalid if you're using XHTML 1.1, strict XHTML 1.0,
or strict HTML 4.0: All input fields (even hidden ones) must be placed
inside a block-level element such as  or .

The solution: When the parser discovers a form on the page, it should
place the hidden field containing the session name + ID right next to one
of the other input fields:

The original page:


  

  


After being processed by the parser:


  

  

-- 
Edit bug report at http://bugs.php.net/?id=22070&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22070&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22070&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22070&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22070&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22070&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22070&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22070&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22070&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22070&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22070&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22070&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22070&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22070&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22070&r=gnused

#22041 [Opn->Bgs]: mb_substr produces "mojibake" on certain strings ...

ID: 22041
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: mbstring related
Operating System: Red Hat Linux 7.2
PHP Version: 4.3.0
New Comment:

First, let me mark this report as bogus, because it doesn't appear a
bug after all.

> But now makes me wonder what character set my data is in?? And I set
my

It's up to the browser you are using how posted form data are encoded
and submitted to a php script.

> Postgresql database to be EUC-JP, but since you say that could mean
more
> than one thing, I wonder which one PostgreSQL uses??

Inside PostgreSQL, "EUC-JP" encoded characters are handled in a
character-set independent way, Whilst it is treated as a name of a
charset - encoding mapping in mbstring.

Previous Comments:

[2003-02-05 07:55:59] [EMAIL PROTECTED]

Wow, thanks for the long answer! I didn't realize that EUC-JP was not a
single character set ...

I tried what you suggested and that fixed the problem ...

But now makes me wonder what character set my data is in?? And I set my
Postgresql database to be EUC-JP, but since you say that could mean
more than one thing, I wonder which one PostgreSQL uses??

Since I am so confused as to what format my data is in, I ended up
using the database's substr() function instead of PHP's ... I figure
that is safer ...

So I guess the is no problem with mb_substr() then ... just that even
though the DB says the data is in EUC-JP it really is in eucJP-win?

Thanks!

PS You can close the report if you agree that there is no error in
mb_substr()

PPS I love PHP's mb functions, thanks for your work. I just wish the
world would agree on ONE japanese encoding =) It would save me a lot of
headaches ...

[2003-02-05 07:47:27] [EMAIL PROTECTED]

Since mb_substr() internally converts input strings to the Unicode
character set representation, if it find such an "illegal" character
that is not supposed to be a member of the input character set, it
simply ends up returning wrong results. eucjp-win is prepared for
convenience so that users can handle strings whose components are
represented in CP932 character set and encoded in EUC-JP.

Practically, there are some EUC-JP variants because EUC-JP itself
originally represents just an encoding rather than a whole character
set.

I think this practice is quite confusing too, but please keep it in
your mind that an encoding doesn't always have a single corresponding
character set even though their names are the same. In this context, it
could be said EUC-JP is rather a name of an encoding and often mistaken
as a character set name, where the actual names of character sets which
EUC-JP _can_ represent are ISO646, JISX0201-1976, JISX0208-1990,
JISX0212-1990, JISX0213-2000, and so on.

Anyway, did you try it out?

[2003-02-04 21:20:49] [EMAIL PROTECTED]

Glad you could see the funny side of this bug report :) I did try very
hard to find a better example ... but couldn't get mb_substr to break
on anything else.

Why set internal encoding to eucJP-win? The data is from a database and
is in EUC-JP ...

When I entered the data into the DB if the were any illegal EUC-JP
characters it should have complained ...

And as you can see I can display the whole string as EUC-JP perfectly.
It's only *after* I use mb_substr() that the string becomes mojibake
...

Thanks!

[2003-02-04 07:36:19] [EMAIL PROTECTED]

LOL! It's indeed so OFFENSIVE I have no idea how to translate those
words to English. But perhaps you know what that means?

Ehm, first try setting the internal encoding to "eucJP-win".

[2003-02-04 05:28:48] [EMAIL PROTECTED]

First, sorry for any offensive japanese words. I can't read/write
japanese very well, and the error in mb_substr occurs on data from a
list of video titles ... I tried to find another less offensive example
but couldn't. I'm just posting this bug report in order to help ...

I am trying to use mb_substr on data I get from a postgreSQL DB and in
some cases mb_substr seems to cut the string in the middle of a
multibyte char .. which turns the "cut" char into mojibake ...

The DB is in EUC-JP and my internal encoding is set to EUC-JP in my
php.ini file ...

As you can see the last character of the string has been improperly cut
...

Here is my test program and output:

CODE:

substr;

echo "String: ";
echo $c ."";

$c = mb_substr($c, 0, 80);

echo " After cutting it ... ";
echo $c ."";
?>

OUPUT:

COMMENT2:
¥¢¥ó¥°¥ë¤Î¡ÖÄ¶-¸Ô´Ö¤Î¥¢¥ó¥°¥ë¡×¥·¥ê¡¼¥º£Ä£Ø¡¢Â³¡¹ÅÐ¾ì¡ª¤¿¤À¤ÎºÆÊÔ¤â¤

#22069 [Bgs]: $_GET==$_SESSION

 ID:   22069
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Session related
 Operating System: Win XP
 PHP Version:  4.3.0
 New Comment:

Too old PHP version..and DON'T abuse the super globals
like that, you're not supposed to add your own entries
in any other but the $_SESSION array!



Previous Comments:


[2003-02-05 07:47:25] [EMAIL PROTECTED]

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

Yes, when globals are on, $_GET $_POST $_FILES $_SESSION $_COOKIE are
the same global variable.



[2003-02-05 07:14:32] [EMAIL PROTECTED]

My ver of php is 4.3.0 RC 3, not RC 2



[2003-02-05 06:54:05] [EMAIL PROTECTED]



Php 4.3.0 RC 2, Apache 2, XP with register.globals = ON
if register.globals = OFF, it's ok.

My english is not very well ;)




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

#22041 [Opn]: mb_substr produces "mojibake" on certain strings ...

ID: 22041
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: mbstring related
Operating System: Red Hat Linux 7.2
PHP Version: 4.3.0
New Comment:

Wow, thanks for the long answer! I didn't realize that EUC-JP was not a
single character set ...

I tried what you suggested and that fixed the problem ...

But now makes me wonder what character set my data is in?? And I set my
Postgresql database to be EUC-JP, but since you say that could mean
more than one thing, I wonder which one PostgreSQL uses??

Since I am so confused as to what format my data is in, I ended up
using the database's substr() function instead of PHP's ... I figure
that is safer ...

So I guess the is no problem with mb_substr() then ... just that even
though the DB says the data is in EUC-JP it really is in eucJP-win?

Thanks!

PS You can close the report if you agree that there is no error in
mb_substr()

PPS I love PHP's mb functions, thanks for your work. I just wish the
world would agree on ONE japanese encoding =) It would save me a lot of
headaches ...

Previous Comments:

[2003-02-05 07:47:27] [EMAIL PROTECTED]

Practically, there are some EUC-JP variants because EUC-JP itself
originally represents just an encoding rather than a whole character
set.

Anyway, did you try it out?

[2003-02-04 21:20:49] [EMAIL PROTECTED]

Glad you could see the funny side of this bug report :) I did try very
hard to find a better example ... but couldn't get mb_substr to break
on anything else.

Why set internal encoding to eucJP-win? The data is from a database and
is in EUC-JP ...

When I entered the data into the DB if the were any illegal EUC-JP
characters it should have complained ...

And as you can see I can display the whole string as EUC-JP perfectly.
It's only *after* I use mb_substr() that the string becomes mojibake
...

Thanks!

[2003-02-04 07:36:19] [EMAIL PROTECTED]

LOL! It's indeed so OFFENSIVE I have no idea how to translate those
words to English. But perhaps you know what that means?

Ehm, first try setting the internal encoding to "eucJP-win".

[2003-02-04 05:28:48] [EMAIL PROTECTED]

I am trying to use mb_substr on data I get from a postgreSQL DB and in
some cases mb_substr seems to cut the string in the middle of a
multibyte char .. which turns the "cut" char into mojibake ...

The DB is in EUC-JP and my internal encoding is set to EUC-JP in my
php.ini file ...

As you can see the last character of the string has been improperly cut
...

Here is my test program and output:

CODE:

substr;

echo "String: ";
echo $c ."";

$c = mb_substr($c, 0, 80);

echo " After cutting it ... ";
echo $c ."";
?>

OUPUT:

AFTER cutting it ...
¥¢¥ó¥°¥ë¤Î¡ÖÄ¶-¸Ô´Ö¤Î¥¢¥ó¥°¥ë¡×¥·¥ê¡¼¥º£Ä£Ø¡¢Â³¡¹ÅÐ¾ì¡ª¤¿¤À¤ÎºÆÊÔ¤â¤Î¤Ç¤Ï¤¢¤ê¤Þ�

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

#22041 [Opn]: mb_substr produces "mojibake" on certain strings ...

ID: 22041
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: mbstring related
Operating System: Red Hat Linux 7.2
PHP Version: 4.3.0
New Comment:

Practically, there are some EUC-JP variants because EUC-JP itself
originally represents just an encoding rather than a whole character
set.

Anyway, did you try it out?

Previous Comments:

[2003-02-04 21:20:49] [EMAIL PROTECTED]

Glad you could see the funny side of this bug report :) I did try very
hard to find a better example ... but couldn't get mb_substr to break
on anything else.

Why set internal encoding to eucJP-win? The data is from a database and
is in EUC-JP ...

When I entered the data into the DB if the were any illegal EUC-JP
characters it should have complained ...

And as you can see I can display the whole string as EUC-JP perfectly.
It's only *after* I use mb_substr() that the string becomes mojibake
...

Thanks!

[2003-02-04 07:36:19] [EMAIL PROTECTED]

LOL! It's indeed so OFFENSIVE I have no idea how to translate those
words to English. But perhaps you know what that means?

Ehm, first try setting the internal encoding to "eucJP-win".

[2003-02-04 05:28:48] [EMAIL PROTECTED]

I am trying to use mb_substr on data I get from a postgreSQL DB and in
some cases mb_substr seems to cut the string in the middle of a
multibyte char .. which turns the "cut" char into mojibake ...

The DB is in EUC-JP and my internal encoding is set to EUC-JP in my
php.ini file ...

As you can see the last character of the string has been improperly cut
...

Here is my test program and output:

CODE:

substr;

echo "String: ";
echo $c ."";

$c = mb_substr($c, 0, 80);

echo " After cutting it ... ";
echo $c ."";
?>

OUPUT:

AFTER cutting it ...
¥¢¥ó¥°¥ë¤Î¡ÖÄ¶-¸Ô´Ö¤Î¥¢¥ó¥°¥ë¡×¥·¥ê¡¼¥º£Ä£Ø¡¢Â³¡¹ÅÐ¾ì¡ª¤¿¤À¤ÎºÆÊÔ¤â¤Î¤Ç¤Ï¤¢¤ê¤Þ�

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

#22069 [Opn->Bgs]: $_GET==$_SESSION

2003-02-05 Thread nicos

 ID:   22069
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Session related
 Operating System: Win XP
 PHP Version:  4.3.0
 New Comment:

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

Yes, when globals are on, $_GET $_POST $_FILES $_SESSION $_COOKIE are
the same global variable.


Previous Comments:


[2003-02-05 07:14:32] [EMAIL PROTECTED]

My ver of php is 4.3.0 RC 3, not RC 2



[2003-02-05 06:54:05] [EMAIL PROTECTED]



Php 4.3.0 RC 2, Apache 2, XP with register.globals = ON
if register.globals = OFF, it's ok.

My english is not very well ;)




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

#22064 [Opn]: mb_send_mail hard-coded to send text/plain

 ID:   22064
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: mbstring related
 Operating System: Red Hat Linux 7.2
 PHP Version:  4.3.0
 Assigned To:  moriyoshi
 New Comment:

Great. You can closed the report then =)


Previous Comments:


[2003-02-05 07:14:30] [EMAIL PROTECTED]

This work is in progress.
Stay tuned!






[2003-02-05 01:06:20] [EMAIL PROTECTED]

Feature request:

Currently mb_send_mail() is hard-coded to send a Content-type of
text/plain. Would it be possible to add a way to change this (being
able to set it to text/html would be very useful).

Either a parameter to mb_send_email or a function such as
mb_send_mail_set_content_type(string)?

Thanks!

Jc




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

#22069 [Opn]: $_GET==$_SESSION

2003-02-05 Thread me

 ID:   22069
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Session related
 Operating System: Win XP
 PHP Version:  4.3.0
 New Comment:

My ver of php is 4.3.0 RC 3, not RC 2


Previous Comments:


[2003-02-05 06:54:05] [EMAIL PROTECTED]



Php 4.3.0 RC 2, Apache 2, XP with register.globals = ON
if register.globals = OFF, it's ok.

My english is not very well ;)




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

#22064 [Opn]: mb_send_mail hard-coded to send text/plain

 ID:   22064
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: mbstring related
 Operating System: Red Hat Linux 7.2
 PHP Version:  4.3.0
-Assigned To:  
+Assigned To:  moriyoshi
 New Comment:

This work is in progress.
Stay tuned!





Previous Comments:


[2003-02-05 01:06:20] [EMAIL PROTECTED]

Feature request:

Currently mb_send_mail() is hard-coded to send a Content-type of
text/plain. Would it be possible to add a way to change this (being
able to set it to text/html would be very useful).

Either a parameter to mb_send_email or a function such as
mb_send_mail_set_content_type(string)?

Thanks!

Jc




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

#22069 [NEW]: $_GET==$_SESSION

2003-02-05 Thread me

From: [EMAIL PROTECTED]
Operating system: Win XP
PHP version:  4.3.0
PHP Bug Type: Session related
Bug description:  $_GET==$_SESSION



Php 4.3.0 RC 2, Apache 2, XP with register.globals = ON
if register.globals = OFF, it's ok.

My english is not very well ;)
-- 
Edit bug report at http://bugs.php.net/?id=22069&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22069&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22069&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22069&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22069&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22069&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22069&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22069&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22069&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22069&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22069&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22069&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22069&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22069&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22069&r=gnused

#12802 [Com]: gethostbyname/gethostbyaddr timeout

2003-02-05 Thread sergi

 ID:   12802
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Linux (N/A)
 PHP Version:  4.0CVS-2001-08-16
 New Comment:

Is this bug still open? I think it's a really important bug and can
cause very long retards when the DNS lookup doesn't respond or some DNS
server is unreacheable.


Previous Comments:


[2001-08-16 21:03:38] [EMAIL PROTECTED]

I propose creating a timeout argument on the gethostbyname and
gethostbyaddr.  I have a script that uses these, and if my internet
connection goes down it takes 1:30-2:00 minutes for 3 gethostbyname's
to timeout.  This is way to long, and it would help if I could specify
a timeout.




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

#22068 [NEW]: Access $_SESSION

2003-02-05 Thread AchimWinkelmann

From: [EMAIL PROTECTED]
Operating system: Windows XP
PHP version:  4.3.0
PHP Bug Type: Session related
Bug description:  Access $_SESSION

The manual says at topic XCIII. SESSION HANDLING FUNCTIONS under headline
EXAMPLES within the NOTE, 'you do not need to use the global keyword for
$_SESSION'. 

In fact you 'may not use the global keyword' when accessing $_SESSION from
within a function, otherwise a different global variable seems to be
created/accessed (PHP 4.3.0, WinXP)!

Maybe it is no bug, but I miss any sematically sense.
-- 
Edit bug report at http://bugs.php.net/?id=22068&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22068&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22068&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22068&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22068&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22068&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22068&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22068&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22068&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22068&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22068&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22068&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22068&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22068&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22068&r=gnused

#22047 [Com]: PHP pollutes the namespace w/ (what looks like) its grammar tokens

2003-02-05 Thread john

 ID:   22047
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Wont fix
 Bug Type: *General Issues
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

In order to avoid breaking backward compatibility with existing
scripts, would it not be possible to allow pre-defined constants to be
hidden when a constant is defined in a script with the same name?  As
long as a script doesn't need to use both the pre-defined constants,
and the new ones, (which a script designed for an old PHP version
should not need to do anyway), I can't think of any reason why that
wouldn't be an almost perfect solution - problems would only occur if a
script assumed that a constant which was not pre-defined, but not
defined in the script, evaluated to it's own name.


Previous Comments:


[2003-02-05 01:00:19] [EMAIL PROTECTED]

> A notice is fine,

redefinition of a constant being only a NOTICE?  
you can't be serious!



[2003-02-05 00:49:18] [EMAIL PROTECTED]

How's changing a NOTICE into a WARNING going to break
anything, anyway?

diff -ur a/Zend/zend_constants.c b/Zend/zend_constants.c
--- a/Zend/zend_constants.c 2002-10-09 16:17:53.0 +0200
+++ b/Zend/zend_constants.c 2003-02-05 07:46:35.0 +0100
@@ -265,7 +265,7 @@
if (!(c->flags & CONST_PERSISTENT)) {
zval_dtor(&c->value);
}
-   zend_error(E_NOTICE,"Constant %s already defined",
lowercase_name);
+   zend_error(E_WARNING, "Constant %s already defined",
lowercase_name);
ret = FAILURE;
}
free_alloca(lowercase_name);



[2003-02-04 12:46:48] [EMAIL PROTECTED]

Guys, if this is how you deal with backwards
compatibility issues, then I'm scared.

I've been maintaining a big PHP project that's about
1MB of very clean code and I need to keep it alive.
This particular bug gave me quite a bit of a headache.
I've provided valid arguments on why a (trivial) change
should be made, and you seem to not really care.  That's
not giving me nice prospects into the future, is it?

Come on, we're talking about constants here!
If a constant is redefined by a program, then
that program is broken by definition and needs
to be told on an appropriate level.



[2003-02-04 12:31:13] [EMAIL PROTECTED]

It's fine as it is -> wont fix.



[2003-02-04 11:48:17] [EMAIL PROTECTED]

A NOTICE definitely is NOT sufficient.

Remember many setups running older PHP software set
"error_reporting = E_ALL & ~E_NOTICE", because the
amount of notices on undefined array indices and
undefined variables can be quite overwhelming --
and it is precisely these setups that are likely
to be bitten by this problem.

Redefinition of a constant should be a WARNING,
I must insist.



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

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

#22067 [Opn->Csd]: Win32 Build reports Link Failure on load

2003-02-05 Thread derick

 ID:   22067
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: *Compile Issues
 Operating System: Win95
 PHP Version:  4.3.0
 New Comment:

Windows 95 is no longer supported as of PHP 4.3.0, this is added in the
docs, but not yet online.

Derick


Previous Comments:


[2003-02-05 04:09:30] [EMAIL PROTECTED]

The win32 build does not run under Win95 environment.
Citing Kernel32 export cancello missing. That is a win98+ export. Win95
build needed.




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

#22067 [NEW]: Win32 Build reports Link Failure on load

2003-02-05 Thread treehouse

From: [EMAIL PROTECTED]
Operating system: Win95
PHP version:  4.3.0
PHP Bug Type: *Compile Issues
Bug description:  Win32 Build reports Link Failure on load

The win32 build does not run under Win95 environment.
Citing Kernel32 export cancello missing. That is a win98+ export. Win95
build needed.
-- 
Edit bug report at http://bugs.php.net/?id=22067&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22067&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22067&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22067&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22067&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22067&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22067&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22067&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22067&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22067&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22067&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22067&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22067&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22067&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22067&r=gnused

#21938 [Fbk->Opn]: Wrong error line numbers

2003-02-05 Thread arne . brachhold

 ID:   21938
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Windows 2000
 PHP Version:  4.3.0
 New Comment:

It shows the correct line on short scripts like yours.
But when I create a script, write 20 times

if(isset($blubb)) {


}

ans then blubb(); which is now on line 88, it tells me the error is on
line 66. As longer the script is as higher is the difference.

Sorry at the moment i don't have the time to test this with the CGI
Binary. But i can do this on weekend.


Previous Comments:


[2003-02-04 18:19:09] [EMAIL PROTECTED]

Using PHP 4.3.1-dev and running this script:



What line is the error reported on? (using PHP CLI binary)
And what about with PHP CGI binary ?

For me, it says the error is on line 3, which is correct.



[2003-01-30 05:41:12] [EMAIL PROTECTED]

Sorry, this doesn't really help. The numbers are nearer to the right
position now, but not correct.

Displayed: ..in Line 125
Correct Position: 138



[2003-01-29 07:04:03] [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

Ilia fixed something like this just few days ago, iirc.




[2003-01-29 06:17:07] [EMAIL PROTECTED]

What I did:
=

Made a script like this:



What should happen?

This error:

Fatal error: Call to undefined function: blubb() in foo.php on line 3

What happend?

This error:

Fatal error: Call to undefined function: blubb() in foo.php on line 2


As you see the line number is incorrect. It should be 3 instead of 2.
As longer the script is as longer are the differences betweeen the
correct and displayed line number.
This happens with all errors, warnings ans so on.

this happends since the upgrade of PHP to PHP 4.3.

System: Windows 2000 Server / Apache/1.3.24
Version: PHP 4.3 Windows Binary with unmodified php.ini-dist



[2003-01-29 06:02:45] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.




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

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

#22066 [Opn->Fbk]: GD 2.0.11 with php 4.3.0

 ID:   22066
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
-Bug Type: Compile Failure
+Bug Type: GD related
 Operating System: Solaris 2.7
 PHP Version:  4.3.0
 New Comment:

What was the full configure line used?



Previous Comments:


[2003-02-05 03:36:43] [EMAIL PROTECTED]

configure is pass with --with-gd  but make is fail as per follow .
Kindly advice asap.

error---

Undefined   first referenced
 symbol in file
gdImageColorMatch   ext/gd/gd.lo
gdImageCreateFromGifext/gd/gd.lo
gdImageRotate   ext/gd/gd.lo
gdImageCreateFromGifCtx ext/gd/gd.lo
ld: fatal: Symbol referencing errors. No output written to
sapi/cli/php
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `sapi/cli/php'






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

#22066 [NEW]: GD 2.0.11 with php 4.3.0

2003-02-05 Thread khin-shein . khin

From: [EMAIL PROTECTED]
Operating system: Solaris 2.7
PHP version:  4.3.0
PHP Bug Type: Compile Failure
Bug description:  GD 2.0.11 with php 4.3.0

configure is pass with --with-gd  but make is fail as per follow . Kindly
advice asap.

error---

Undefined   first referenced
 symbol in file
gdImageColorMatch   ext/gd/gd.lo
gdImageCreateFromGifext/gd/gd.lo
gdImageRotate   ext/gd/gd.lo
gdImageCreateFromGifCtx ext/gd/gd.lo
ld: fatal: Symbol referencing errors. No output written to sapi/cli/php
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `sapi/cli/php'


-- 
Edit bug report at http://bugs.php.net/?id=22066&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22066&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22066&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22066&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22066&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22066&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22066&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22066&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22066&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22066&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22066&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22066&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22066&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22066&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22066&r=gnused

#22057 [Csd->Bgs]: fgets function failure