[PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/cgi cgi_main.c

[Andi Gutmans]

At 09:14 AM 5/1/2001 +0200, Sebastian Bergmann wrote:
>Sterling Hughes wrote:
> > sterlingMon Apr 30 20:48:27 2001 EDT
> >
> >   Modified files:
> > /php4/sapi/cgi  cgi_main.c
> >   Log:
> >   fix for bug 6491, http://www.php.net/bugs.php?id=6491, removes a
> >   bit of (what I think is) broken logic.
>
>cgi_main.c
>D:\Programme\MS Visual Studio\Projekte\php\php4\sapi\cgi\cgi_main.c(151)
>: warni
>ng C4101: 'pi' : Unreferenced local variable

OK I removed it.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10556 Updated: php does not work with php_mcrypt.dll

[derick]

ID: 10556
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: mcrypt related
PHP Version: 4.0.4
Assigned To: 
Comments:

Please try the lastest 4.0.5 release from www.php.net as soon as it's posted on the 
site.
You probably tried the 4.0.2 module from the site your mentioned with a 4.0.4 release. 
And these could be quite incompatible.

Previous Comments:
---

[2001-04-30 02:00:09] [EMAIL PROTECTED]
I am using a windows 98 machine.
I have installed php 4.0.4 using the easy installer for windows. I downloaded the 
php_mcrypt.dll file fromhttp://www.multimedia.uni-greifswald.de/~php4.
When i tried to run the test program I got the following error. unable to load 
php_mcrypt.dll.The other dll's like php_gd.dll are working.Please help me out.




---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10556&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10518 Updated: mcrypt_generic is padding input when using cfb and ofb modes

[derick]

ID: 10518
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Assigned
Status: Closed
Bug Type: mcrypt related
PHP Version: 4.0.4pl1
Assigned To: derick
Comments:

I applied your fix in CVS. Thanks!

Previous Comments:
---

[2001-04-28 12:39:48] [EMAIL PROTECTED]
Same bug also in php_mcrypt_do_crypt, here's the new patch:

--- php-4.0.4pl1/ext/mcrypt/mcrypt.cWed Nov 22 22:40:15 2000
+++ php-4.0.4pl1-sk/ext/mcrypt/mcrypt.c Sat Apr 28 18:44:09 2001
@@ -498,7 +498,7 @@
convert_to_string_ex (data);
 
/* Check blocksize */
-   if (mcrypt_enc_is_block_algorithm (td) == 1) { /* It's a block algorithm */
+   if (mcrypt_enc_is_block_mode (td) == 1) { /* It's a block algorithm */
block_size = mcrypt_enc_get_block_size (td);
data_size = (((Z_STRLEN_PP(data) - 1) / block_size) + 1) * block_size;
data_s = emalloc (data_size);
@@ -539,7 +539,7 @@
convert_to_string_ex (data);
 
/* Check blocksize */
-   if (mcrypt_enc_is_block_algorithm (td) == 1) { /* It's a block algorithm */
+   if (mcrypt_enc_is_block_mode (td) == 1) { /* It's a block algorithm */
block_size = mcrypt_enc_get_block_size (td);
data_size = (((Z_STRLEN_PP(data) - 1) / block_size) + 1) * block_size;
data_s = emalloc (data_size);
@@ -1280,7 +1280,7 @@
}
 
/* Check blocksize */
-   if (mcrypt_enc_is_block_algorithm (td) == 1) { /* It's a block algorithm */
+   if (mcrypt_enc_is_block_mode (td) == 1) { /* It's a block algorithm */
block_size = mcrypt_enc_get_block_size (td);
data_size = (((Z_STRLEN_PP(data) - 1) / block_size) + 1) * block_size;
data_s = emalloc (data_size);

---

[2001-04-26 19:39:06] [EMAIL PROTECTED]
thx, will look into this soon

---

[2001-04-26 18:28:36] [EMAIL PROTECTED]
When encrypting using a block cipher and cfb or ofb mode the 
mcrypt_generic/mdecrypt_generic function
still pad the input to a multiple of the underlying algorithm's block size. Input 
should not be padded when used with 
cfb or ofb mode.


Script showing the bug:

$key   = pack("H*", 
"");
$iv= pack("H*", "");
$plain = pack("H*", "");
$handle = mcrypt_module_open(MCRYPT_TWOFISH, "", MCRYPT_MODE_CFB, "");
mcrypt_generic_init($handle, $key, $iv);
$crypted = mcrypt_generic($handle, $plain);
mcrypt_generic_end($handle);
print bin2hex($plain)."nn";
print bin2hex($crypted)."nn";


Proposed patch:

--- mcrypt/mcrypt.c Wed Nov 22 22:40:15 2000
+++ mcrypt-sk/mcrypt.c  Fri Apr 27 00:25:16 2001
@@ -498,7 +498,7 @@
convert_to_string_ex (data);
 
/* Check blocksize */
-   if (mcrypt_enc_is_block_algorithm (td) == 1) { /* It's a block algorithm */
+   if (mcrypt_enc_is_block_mode (td) == 1) { /* It's a block algorithm */
block_size = mcrypt_enc_get_block_size (td);
data_size = (((Z_STRLEN_PP(data) - 1) / block_size) + 1) * block_size;
data_s = emalloc (data_size);
@@ -539,7 +539,7 @@
convert_to_string_ex (data);
 
/* Check blocksize */
-   if (mcrypt_enc_is_block_algorithm (td) == 1) { /* It's a block algorithm */
+   if (mcrypt_enc_is_block_mode (td) == 1) { /* It's a block algorithm */
block_size = mcrypt_enc_get_block_size (td);
data_size = (((Z_STRLEN_PP(data) - 1) / block_size) + 1) * block_size;
data_s = emalloc (data_size);

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10518&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #8889 Updated: Memory is not being freed.

[andi]

ID: 8889
Updated by: andi
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Performance problem
PHP Version: 4.0.4
Assigned To: 
Comments:

The main problem is that once the system's standard C library allocates heap space 
(with the sbrk() system call) it will never return that memory to the system.
PHP can't solve this problem. If you do find certain things in the future which take 
up much more memory than they should please open a new bug report and we will check 
into it.

Previous Comments:
---

[2001-04-30 14:31:27] [EMAIL PROTECTED]
I am talking about nearly endless amounts.  I saw Apache processes with as much as 
14MB of memory in use.

Brian.

---

[2001-04-29 19:59:56] [EMAIL PROTECTED]
What kind of sizes are we talking about here?  the Zend memory manager holds a memory 
cache, but we're talking at around 1MB per process max.

---

[2001-01-26 18:45:45] [EMAIL PROTECTED]
Ok, this is just like what is described in 
http://marc.theaimsgroup.com/?l=php-dev&m=97923602322593&w=2 which contains a hacked 
up solution.  It looks like it should be able to turn into a usable end solution.

---

[2001-01-24 13:21:13] [EMAIL PROTECTED]
Hi guys,

I do not have much information.  I know that my Apache processes memory is growing by 
the minute.  If I start a separate server on another port and serve only static pages 
and files through it, those process do not grow.

I have tried what I remembered of gdb but have not come up with anything.  I know I 
need to attach to a process and it seems I can `gdb {pid}` but that gives me nothing.  
How can I get some info for you guys?  I do have --enable-debug.

thanks,

Brian.
Phorum.org

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8889&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

[John Hamlik]

I was kinda hoping the fast-cgi version would enable the best of both
worlds; however, I have been unable to get it to work under apache at
this point.  Any comments ?

-Original Message-
From: Brian Foddy [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 30, 2001 9:18 PM
To: Andi Gutmans; Brian Moon; John Hamlik; [EMAIL PROTECTED]; Rod K
Subject: RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
freed.


That sounds like it would work also.  People would have
to build PHP for both modules and CGI, but if they
are willing to do that...
Works for me.

Brian

On Mon, 30 Apr 2001 23:53:16 -0400, Rod K wrote:

>Couldn't one just run a cgi and module version simultaneously?  Set an
add
>type directive to pass an extension, say .cphp, to the cgi instead of
the
>module.  Then those scripts that use extensive memory could be extended
with
>.cphp???
>
>-Original Message-
>From: Brian Foddy [mailto:[EMAIL PROTECTED]]
>Sent: Monday, April 30, 2001 11:56 PM
>To: Andi Gutmans; Brian Moon; John Hamlik; [EMAIL PROTECTED]
>Subject: RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
>freed.
>
>
>Perhaps another possible solution is this...
>For those 1 in 300 web hits that the developer knows is
>going to use gobs of memory and assuming they can't
>be re-engineered to use less (through temp files, etc),
>create a simple function that is callable in PHP that
>will cause the parent apache process to exit (if it doesn't
>exist already) It will be immediately replaced by another much smaller
>version ready to handle the remaining 299 web hits.
>
>This gives the performance benefit for most hits of
>the apache module, but the memory benefits of the
>cgi behavior.
>
>But before I'd do that, I'd make sure the big page
>can't be re-engineered first.
>
>Brian
>
>On Mon, 30 Apr 2001 18:42:59 -0700, John Hamlik wrote:
>
>>I too have experienced this problem and can reproduce, I just changed
to
>>the cgi version instead to eliminate the problem, which I would agree,
>>it is.  I have one page on a site of hundreds of pages that produces
the
>>large process, 30MB+ and this is on a heavily used server with more
than
>>300 processes.  So if I don't run the cgi-version the server will
crash
>>in a matter of time as the memory is not freed and eventually will
swap
>>itself to death.  So while the cgi-version is slightly slower, I have
>>reliability.
>>
>>John Hamlik
>>
>>-Original Message-
>>From: Brian Moon [mailto:[EMAIL PROTECTED]]
>>Sent: Monday, April 30, 2001 3:20 PM
>>To: [EMAIL PROTECTED]; Andi Gutmans
>>Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
>>freed.
>>
>>
>>But the reverse side of this is that I might have one script out of
1000
>>that needs that much memory.  But since 20 of my httpd processes have
>>run
>>that script, they all have that much memory and are not going to let
it
>>go
>>no matter what.
>>
>>I basically sounds like a flaw that memory can not be freed.  Reuse in
>>the
>>same process is not free memory, it is reused memory.  And it sounds
>>like
>>there is nothing that the PHP team can do about it.
>>
>>Brian Moon
>>--
--
>>-
>>Phorum Dev Team - http://phorum.org
>>Making better forums with PHP
>>--
--
>>-
>>
>>Look for my presentation at ApacheCon 2001.
>>"Caching Dynamic Web Content to Increase Dependability and
Performance"
>>http://www.apachecon.com/
>>
>>
>>
>>- Original Message -
>>From: "Andi Gutmans" <[EMAIL PROTECTED]>
>>To: "Brian Moon" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>>Sent: Monday, April 30, 2001 5:02 PM
>>Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
>>freed.
>>
>>
>>> At 04:59 PM 4/30/2001 -0500, Brian Moon wrote:
>>> >This is the answer I had previously received.  IMHO, this sucks.
We
>>don't
>>> >do SQL queries on our production site.  It is all cached.  So, SQL
is
>>not
>>> >the problem.  It is most likely because of the storage of large
>>arrays or
>>> >something of that nature.
>>>
>>> Well maybe you should try and see what in your script is taking up
>>lots of
>>> memory.
>>>
>>>
>>> >I guess we will continue to use MaxRequestsPerChild until one day
the
>>people
>>> >that wrote that memory allocation system get a clue.
>>>
>>> They are very clue full. A program which uses X MB of memory is very
>>likely
>>> to use X MB of memory again at a later time. For example, how does
it
>>help
>>> you if your 14 MB were shrunk back to 10 MB on each request. The
next
>>> request would probably make it grow back to 14 MB.
>>> There might be some memory management libraries that shrink the
memory
>>back
>>> but I doubt you can gain much from it especially as memory
>>fragmentation
>>> can severally limit the amount of memory you can reclaim and because
>>of
>>the
>>> point I made before, it's probably just not worth it.
>>>
>>> If you can find a case where you really

[PHP-DEV] Bug #10572: https takes forever and a day when curl is enabled

[Clement . Ong]

From: [EMAIL PROTECTED]
Operating system: Linux Red Hat 7.0
PHP version:  4.0.5
PHP Bug Type: cURL related
Bug description:  https takes forever and a day when curl is enabled 

I am experiencing the same problem(https takes a long time to return when curl is 
enabled with php) as noted in 

http://www.php.net/bugs.php?id=10195

after I built our production machine. All the software components and their versions 
are the same on both machines.

When I did a uname on the server that is working with https and curl enabled I get 

localhost.localdomain 2.2.16-22 #1 Tue Aug 22 16:16:55 EDT 2000 i586 unknown

on the server that is not working it is :-

localhost.localdomain 2.2.16-22 #1 Tue Aug 22 16:17:40 EDT 2000 i686 unknown

Could the differerent instruction set be causing the problem, i686 compared to i586?

I've downloaded the latest build(April 30th) but the make fails with problems with 
curl headers.

Does anyone know what is this happening?

cheers,

Clement








-- 
Edit Bug report at: http://bugs.php.net/?id=10572&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10566 Updated: don't work properly fopen

[sniper]

ID: 10566
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Analyzed
Bug Type: Filesystem function related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

I can reproduce this on Linux too.
If file exists in ftp, you can not overwrite it or
add to it.

--Jani


Previous Comments:
---

[2001-04-30 17:11:25] [EMAIL PROTECTED]
this scrip don't work properly:
(only the first time, that's ok)
ftp://usr:pass@localhost/administrador/servicios5.inc","w";);
fputs($file,"Algo");
fclose($file);
?>

this the warning:

Warning: File already exists in generaservicios.inc on line 1

Warning: fopen("ftp://...@localhost/administrador/servicios5.inc","w";) - File exists 
in generaservicios.inc on line 1

Warning: Supplied argument is not a valid File-Handle resource in generaservicios.inc 
on line 2

Warning: Supplied argument is not a valid File-Handle resource in generaservicios.inc 
on line 97


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10566&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10497 Updated: Not connect with MySql

[sniper]

ID: 10497
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Filesystem function related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

There is already open bug report from you about
this same problem: #10566


--Jani


Previous Comments:
---

[2001-04-30 14:50:05] [EMAIL PROTECTED]
this script don't work   

ftp://user:password@localhost/administrador/servicios.inc","w";);
fputs($file,"Algo");
fclose($file);
?>

---

[2001-04-30 14:49:20] [EMAIL PROTECTED]
this script don't work   

ftp://user:password@localhost/administrador/servicios.inc","w";);
fputs($file,"Algo");
fclose($file);
?>

---

[2001-04-29 04:57:52] [EMAIL PROTECTED]
The error message 'Maximum execution time of 30 seconds exceeded' doesn't need to be 
related to MySQL, as it just says that your script's running time is longer than 
allowed.

Do you get, apart from that, any error message that indicates a relation to MySQL?

On first look your code looks okay, could it be that your query just consumes much 
time?


---

[2001-04-25 16:52:29] [EMAIL PROTECTED]
this is the error:
 
Fatal error: Maximum execution time of 30 seconds exceeded in D:Mis 
DocumentosWebtempok.php on line 2
 
and this is the script in php:
 



ok. thanks.


---

[2001-04-25 16:27:44] [EMAIL PROTECTED]
user feedback:

this is the error:
 
Fatal error: Maximum execution time of 30 seconds exceeded in D:Mis 
DocumentosWebtempok.php on line 2
 
and this is the script:
 




please, use the web interface for future updates

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10497&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #9530 Updated: Apache will not start with PayFlow Pro SDK

[jdonagher]

ID: 9530
Updated by: jdonagher
Reported By: [EMAIL PROTECTED]
Old-Status: Assigned
Status: Closed
Bug Type: Verisign Payflow Pro related
PHP Version: 4.0.4pl1
Assigned To: [EMAIL PROTECTED]
Comments:

Support for version 3 is now present in the CVS version of 
PHP. Note: You will need to do this in your script for the 
time being:
#putenv('PFPRO_CERT_PATH=/path/to/verisign/sdk/certs');

Please try the CVS version if you can; if the segfaulting 
persists please compile with debugging on (--enable-debug) 
and send me a backtrace, and you're full Apache and PHP 
configure lines, and re-open this bug.



Previous Comments:
---

[2001-04-25 02:34:24] [EMAIL PROTECTED]
As a sidenote, commenting out the pfpro_version function 
will not solve the problem. There are other features that 
the v3 SDK implements which this extension does not. The 
extension does need some work.


---

[2001-04-25 02:32:21] [EMAIL PROTECTED]
Since I work on this extension for my company, work on 
this will progress when Verisign converts our account from 
v2 to v3. I've received notification of this; it will be 
within the next couple weeks.


---

[2001-03-04 17:45:53] [EMAIL PROTECTED]
I believe the problem is that we are using the V3 of the pfpro sdk and that php is on 
V2.11.  Are there any plans to include V3 support in the near future?

---

[2001-03-02 16:23:34] [EMAIL PROTECTED]
To reproduce:
1) ./configure --with-apxs=/usr/local/apache1317/bin/apxs
--with-mysql=/usr/local/mysql --enable-debug=no
--enable-track-vars=yes --with-gdbm --enable-ftp --with-xml
--with-curl --with-openssl --with-pfpro --with-zlib=/usr/lib

NOTE 1: I have placed the path to the pfpro lib and it did not make a difference.

NOTE 2: I have also configured it with only pfpro to verify that it was not any other 
modules and it did not make a difference.

2) make
This is the result
root@server5:/usr/local/phpApache/php-4.0.4pl1# make > make.out
pfpro.c: In function `php_if_pfpro_version':
pfpro.c:129: warning: initialization makes pointer from integer without a
cast
root@server5:/usr/local/phpApache/php-4.0.4pl1#

NOTE: I sent the output into make.out so I could just see the errors.

3) make install
4) cd to apache install dir and run configtest.  It will give the following result:
root@server5:/usr/local/phpApache/php-4.0.4pl1# ../../apache/bin/apachectl
conf
igtest
Syntax error on line 213 of /usr/local/apache1317/conf/httpd.conf:
Cannot load /usr/local/apache1317/libexec/libphp4.so into server:
/usr/local/apache1317/libexec/libphp4.so: undefined symbol: PNVersion
root@server5:/usr/local/phpApache/php-4.0.4pl1#

I believe the error is in the ext/pfpro.c code (../php-4.0.4pl1/ext/pfpro/pfpro.c)
/* {{{ proto string pfpro_version()
   Returns the version of the Payflow Pro library */
PHP_FUNCTION(pfpro_version)
{
if (ZEND_NUM_ARGS() != 0) {
WRONG_PARAM_COUNT;
}

RETURN_STRING(PNVersion(), 1);
}

I have gone in and commented out all the lines in pfpro.c and php_pfpro.h that 
referenced the pfpro version function.  Doing this and repeating the above steps 
allowed me to get apache up and running but it would seg fault at times so this is not 
a very good solution.  I have not submitted a gdb because I can't get it start without 
my commented changes.  Additionally, if I don't build it wil pfpro it configs, makes, 
and runs fine.


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9530&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10571 Updated:

[nigglefish]

ID: 10571
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Other web server
Description: 

I am running a Xitami (v2.4c1) server on win2000.
I used the install shield to install PHP 4.0.4.
All the filters and stuff seem to be set up right in Xitami. I have installed and used 
PHP 3 with the same server and followed the same steps to configure it for PHP 4.
I have set the "doc_root" in the php.ini file to "C:\Nigel\VWS".

However, when I run a script nothing happens: I get a blank browser screen. Setting 
the "display_startup_errors" in the php.ini file I get the message:
"Fatal error: Unable to open C:\Nigel\VWS\ in Unknown on line 0"

I tried commenting out the "doc_root" setting in the php.ini file and I get the same 
error only it's pointing to the cgi-bin directory of Xitami (even though I have told 
it to use "c:\Nigel\VSM\" for files). 
I tried pointing the "doc_root" to the complete path of the php script file including 
it's filename and that worked and processed the file normally... every time the server 
started up php for any page.

I really am stumped. Thanks in advance.


Previous Comments:
---

[2001-05-01 01:02:02] [EMAIL PROTECTED]
I am running a Xitami (v2.4c1) server on win2000.
I used the install shield to install PHP 4.0.4.
All the filters and stuff seem to be set up right in Xitami. I have installed and used 
PHP 3 with the same server and followed the same steps to configure it for PHP 4.
I have set the "doc_root" in the php.ini file to "C:NigelVWS".

However, when I run a script nothing happens: I get a blank browser screen. Setting 
the "display_startup_errors" in the php.ini file I get the message:
"Fatal error: Unable to open C:NigelVWS in Unknown on line 0"

I tried commenting out the "doc_root" setting in the php.ini file and I get the same 
error only it's pointing to the cgi-bin directory of Xitami (even though I have told 
it to use "c:NigelVSM" for files). 
I tried pointing the "doc_root" to the complete path of the php script file including 
it's filename and that worked and processed the file normally... every time the server 
started up php for any page.

I really am stumped. Thanks in advance.


---

[2001-05-01 00:45:21] [EMAIL PROTECTED]
Not enough information.

See http://www.php.net/bugs-dos-and-donts.php

-Chris

---

[2001-05-01 00:32:46] [EMAIL PROTECTED]


---


Full Bug description available at: http://bugs.php.net/?id=10571


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10571 Updated:

[nigglefish]

ID: 10571
User Update by: [EMAIL PROTECTED]
Old-Status: Bogus
Status: Open
Bug Type: Other web server
Description: 

I am running a Xitami (v2.4c1) server on win2000.
I used the install shield to install PHP 4.0.4.
All the filters and stuff seem to be set up right in Xitami. I have installed and used 
PHP 3 with the same server and followed the same steps to configure it for PHP 4.
I have set the "doc_root" in the php.ini file to "C:\Nigel\VWS".

However, when I run a script nothing happens: I get a blank browser screen. Setting 
the "display_startup_errors" in the php.ini file I get the message:
"Fatal error: Unable to open C:\Nigel\VWS\ in Unknown on line 0"

I tried commenting out the "doc_root" setting in the php.ini file and I get the same 
error only it's pointing to the cgi-bin directory of Xitami (even though I have told 
it to use "c:\Nigel\VSM\" for files). 
I tried pointing the "doc_root" to the complete path of the php script file including 
it's filename and that worked and processed the file normally... every time the server 
started up php for any page.

I really am stumped. Thanks in advance.


Previous Comments:
---

[2001-05-01 00:45:21] [EMAIL PROTECTED]
Not enough information.

See http://www.php.net/bugs-dos-and-donts.php

-Chris

---

[2001-05-01 00:32:46] [EMAIL PROTECTED]


---


Full Bug description available at: http://bugs.php.net/?id=10571


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10571 Updated:

[cnewbill]

ID: 10571
Updated by: cnewbill
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Other web server
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

Not enough information.

See http://www.php.net/bugs-dos-and-donts.php

-Chris

Previous Comments:
---

[2001-05-01 00:32:46] [EMAIL PROTECTED]


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10571&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10571:

[nigglefish]

From: [EMAIL PROTECTED]
Operating system: win2000
PHP version:  4.0.4pl1
PHP Bug Type: Other web server
Bug description:  




-- 
Edit Bug report at: http://bugs.php.net/?id=10571&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

[Brian Foddy]

That sounds like it would work also.  People would have
to build PHP for both modules and CGI, but if they
are willing to do that...
Works for me.

Brian

On Mon, 30 Apr 2001 23:53:16 -0400, Rod K wrote:

>Couldn't one just run a cgi and module version simultaneously?  Set an add
>type directive to pass an extension, say .cphp, to the cgi instead of the
>module.  Then those scripts that use extensive memory could be extended with
>.cphp???
>
>-Original Message-
>From: Brian Foddy [mailto:[EMAIL PROTECTED]]
>Sent: Monday, April 30, 2001 11:56 PM
>To: Andi Gutmans; Brian Moon; John Hamlik; [EMAIL PROTECTED]
>Subject: RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
>freed.
>
>
>Perhaps another possible solution is this...
>For those 1 in 300 web hits that the developer knows is
>going to use gobs of memory and assuming they can't
>be re-engineered to use less (through temp files, etc),
>create a simple function that is callable in PHP that
>will cause the parent apache process to exit (if it doesn't
>exist already) It will be immediately replaced by another much smaller
>version ready to handle the remaining 299 web hits.
>
>This gives the performance benefit for most hits of
>the apache module, but the memory benefits of the
>cgi behavior.
>
>But before I'd do that, I'd make sure the big page
>can't be re-engineered first.
>
>Brian
>
>On Mon, 30 Apr 2001 18:42:59 -0700, John Hamlik wrote:
>
>>I too have experienced this problem and can reproduce, I just changed to
>>the cgi version instead to eliminate the problem, which I would agree,
>>it is.  I have one page on a site of hundreds of pages that produces the
>>large process, 30MB+ and this is on a heavily used server with more than
>>300 processes.  So if I don't run the cgi-version the server will crash
>>in a matter of time as the memory is not freed and eventually will swap
>>itself to death.  So while the cgi-version is slightly slower, I have
>>reliability.
>>
>>John Hamlik
>>
>>-Original Message-
>>From: Brian Moon [mailto:[EMAIL PROTECTED]]
>>Sent: Monday, April 30, 2001 3:20 PM
>>To: [EMAIL PROTECTED]; Andi Gutmans
>>Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
>>freed.
>>
>>
>>But the reverse side of this is that I might have one script out of 1000
>>that needs that much memory.  But since 20 of my httpd processes have
>>run
>>that script, they all have that much memory and are not going to let it
>>go
>>no matter what.
>>
>>I basically sounds like a flaw that memory can not be freed.  Reuse in
>>the
>>same process is not free memory, it is reused memory.  And it sounds
>>like
>>there is nothing that the PHP team can do about it.
>>
>>Brian Moon
>>
>>-
>>Phorum Dev Team - http://phorum.org
>>Making better forums with PHP
>>
>>-
>>
>>Look for my presentation at ApacheCon 2001.
>>"Caching Dynamic Web Content to Increase Dependability and Performance"
>>http://www.apachecon.com/
>>
>>
>>
>>- Original Message -
>>From: "Andi Gutmans" <[EMAIL PROTECTED]>
>>To: "Brian Moon" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>>Sent: Monday, April 30, 2001 5:02 PM
>>Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
>>freed.
>>
>>
>>> At 04:59 PM 4/30/2001 -0500, Brian Moon wrote:
>>> >This is the answer I had previously received.  IMHO, this sucks.  We
>>don't
>>> >do SQL queries on our production site.  It is all cached.  So, SQL is
>>not
>>> >the problem.  It is most likely because of the storage of large
>>arrays or
>>> >something of that nature.
>>>
>>> Well maybe you should try and see what in your script is taking up
>>lots of
>>> memory.
>>>
>>>
>>> >I guess we will continue to use MaxRequestsPerChild until one day the
>>people
>>> >that wrote that memory allocation system get a clue.
>>>
>>> They are very clue full. A program which uses X MB of memory is very
>>likely
>>> to use X MB of memory again at a later time. For example, how does it
>>help
>>> you if your 14 MB were shrunk back to 10 MB on each request. The next
>>> request would probably make it grow back to 14 MB.
>>> There might be some memory management libraries that shrink the memory
>>back
>>> but I doubt you can gain much from it especially as memory
>>fragmentation
>>> can severally limit the amount of memory you can reclaim and because
>>of
>>the
>>> point I made before, it's probably just not worth it.
>>>
>>> If you can find a case where you really think PHP is using much too
>>much
>>> memory let me know and we can try and check together if there's a way
>>to
>>> improve the situation.
>>> Andi
>>>
>>>
>>
>>
>>--
>>PHP Development Mailing List 
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>To contact the list administrators, e-mail: [EMAIL PROTECTED]
>>
>>
>>--
>>PHP Development Mailing List 

RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

[Rod K]

Couldn't one just run a cgi and module version simultaneously?  Set an add
type directive to pass an extension, say .cphp, to the cgi instead of the
module.  Then those scripts that use extensive memory could be extended with
.cphp???

-Original Message-
From: Brian Foddy [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 30, 2001 11:56 PM
To: Andi Gutmans; Brian Moon; John Hamlik; [EMAIL PROTECTED]
Subject: RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
freed.


Perhaps another possible solution is this...
For those 1 in 300 web hits that the developer knows is
going to use gobs of memory and assuming they can't
be re-engineered to use less (through temp files, etc),
create a simple function that is callable in PHP that
will cause the parent apache process to exit (if it doesn't
exist already) It will be immediately replaced by another much smaller
version ready to handle the remaining 299 web hits.

This gives the performance benefit for most hits of
the apache module, but the memory benefits of the
cgi behavior.

But before I'd do that, I'd make sure the big page
can't be re-engineered first.

Brian

On Mon, 30 Apr 2001 18:42:59 -0700, John Hamlik wrote:

>I too have experienced this problem and can reproduce, I just changed to
>the cgi version instead to eliminate the problem, which I would agree,
>it is.  I have one page on a site of hundreds of pages that produces the
>large process, 30MB+ and this is on a heavily used server with more than
>300 processes.  So if I don't run the cgi-version the server will crash
>in a matter of time as the memory is not freed and eventually will swap
>itself to death.  So while the cgi-version is slightly slower, I have
>reliability.
>
>John Hamlik
>
>-Original Message-
>From: Brian Moon [mailto:[EMAIL PROTECTED]]
>Sent: Monday, April 30, 2001 3:20 PM
>To: [EMAIL PROTECTED]; Andi Gutmans
>Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
>freed.
>
>
>But the reverse side of this is that I might have one script out of 1000
>that needs that much memory.  But since 20 of my httpd processes have
>run
>that script, they all have that much memory and are not going to let it
>go
>no matter what.
>
>I basically sounds like a flaw that memory can not be freed.  Reuse in
>the
>same process is not free memory, it is reused memory.  And it sounds
>like
>there is nothing that the PHP team can do about it.
>
>Brian Moon
>
>-
>Phorum Dev Team - http://phorum.org
>Making better forums with PHP
>
>-
>
>Look for my presentation at ApacheCon 2001.
>"Caching Dynamic Web Content to Increase Dependability and Performance"
>http://www.apachecon.com/
>
>
>
>- Original Message -
>From: "Andi Gutmans" <[EMAIL PROTECTED]>
>To: "Brian Moon" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>Sent: Monday, April 30, 2001 5:02 PM
>Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
>freed.
>
>
>> At 04:59 PM 4/30/2001 -0500, Brian Moon wrote:
>> >This is the answer I had previously received.  IMHO, this sucks.  We
>don't
>> >do SQL queries on our production site.  It is all cached.  So, SQL is
>not
>> >the problem.  It is most likely because of the storage of large
>arrays or
>> >something of that nature.
>>
>> Well maybe you should try and see what in your script is taking up
>lots of
>> memory.
>>
>>
>> >I guess we will continue to use MaxRequestsPerChild until one day the
>people
>> >that wrote that memory allocation system get a clue.
>>
>> They are very clue full. A program which uses X MB of memory is very
>likely
>> to use X MB of memory again at a later time. For example, how does it
>help
>> you if your 14 MB were shrunk back to 10 MB on each request. The next
>> request would probably make it grow back to 14 MB.
>> There might be some memory management libraries that shrink the memory
>back
>> but I doubt you can gain much from it especially as memory
>fragmentation
>> can severally limit the amount of memory you can reclaim and because
>of
>the
>> point I made before, it's probably just not worth it.
>>
>> If you can find a case where you really think PHP is using much too
>much
>> memory let me know and we can try and check together if there's a way
>to
>> improve the situation.
>> Andi
>>
>>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]
>




--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact 

RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

[Brian Foddy]

Perhaps another possible solution is this...
For those 1 in 300 web hits that the developer knows is
going to use gobs of memory and assuming they can't
be re-engineered to use less (through temp files, etc),
create a simple function that is callable in PHP that
will cause the parent apache process to exit (if it doesn't
exist already) It will be immediately replaced by another much smaller
version ready to handle the remaining 299 web hits.

This gives the performance benefit for most hits of
the apache module, but the memory benefits of the
cgi behavior.

But before I'd do that, I'd make sure the big page
can't be re-engineered first.

Brian

On Mon, 30 Apr 2001 18:42:59 -0700, John Hamlik wrote:

>I too have experienced this problem and can reproduce, I just changed to
>the cgi version instead to eliminate the problem, which I would agree,
>it is.  I have one page on a site of hundreds of pages that produces the
>large process, 30MB+ and this is on a heavily used server with more than
>300 processes.  So if I don't run the cgi-version the server will crash
>in a matter of time as the memory is not freed and eventually will swap
>itself to death.  So while the cgi-version is slightly slower, I have
>reliability.
>
>John Hamlik
>
>-Original Message-
>From: Brian Moon [mailto:[EMAIL PROTECTED]]
>Sent: Monday, April 30, 2001 3:20 PM
>To: [EMAIL PROTECTED]; Andi Gutmans
>Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
>freed.
>
>
>But the reverse side of this is that I might have one script out of 1000
>that needs that much memory.  But since 20 of my httpd processes have
>run
>that script, they all have that much memory and are not going to let it
>go
>no matter what.
>
>I basically sounds like a flaw that memory can not be freed.  Reuse in
>the
>same process is not free memory, it is reused memory.  And it sounds
>like
>there is nothing that the PHP team can do about it.
>
>Brian Moon
>
>-
>Phorum Dev Team - http://phorum.org
>Making better forums with PHP
>
>-
>
>Look for my presentation at ApacheCon 2001.
>"Caching Dynamic Web Content to Increase Dependability and Performance"
>http://www.apachecon.com/
>
>
>
>- Original Message -
>From: "Andi Gutmans" <[EMAIL PROTECTED]>
>To: "Brian Moon" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>Sent: Monday, April 30, 2001 5:02 PM
>Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
>freed.
>
>
>> At 04:59 PM 4/30/2001 -0500, Brian Moon wrote:
>> >This is the answer I had previously received.  IMHO, this sucks.  We
>don't
>> >do SQL queries on our production site.  It is all cached.  So, SQL is
>not
>> >the problem.  It is most likely because of the storage of large
>arrays or
>> >something of that nature.
>>
>> Well maybe you should try and see what in your script is taking up
>lots of
>> memory.
>>
>>
>> >I guess we will continue to use MaxRequestsPerChild until one day the
>people
>> >that wrote that memory allocation system get a clue.
>>
>> They are very clue full. A program which uses X MB of memory is very
>likely
>> to use X MB of memory again at a later time. For example, how does it
>help
>> you if your 14 MB were shrunk back to 10 MB on each request. The next
>> request would probably make it grow back to 14 MB.
>> There might be some memory management libraries that shrink the memory
>back
>> but I doubt you can gain much from it especially as memory
>fragmentation
>> can severally limit the amount of memory you can reclaim and because
>of
>the
>> point I made before, it's probably just not worth it.
>>
>> If you can find a case where you really think PHP is using much too
>much
>> memory let me know and we can try and check together if there's a way
>to
>> improve the situation.
>> Andi
>>
>>
>
>
>-- 
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
>-- 
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]
>




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #10570: PHP 4.0.5 - Cannot connect to mySQL database

[Steve Meyers]

I had the same problem when I first compiled 4.0.5, using the built-in MySQL
libraries.  I changed my configure line to use --with-mysql=/usr/local/mysql
and it worked fine after that.  I had the same problem on two different
boxes.  Seems kind of odd that they didn't catch this one...

<[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> From: [EMAIL PROTECTED]
> Operating system: RedHat 6.2
> PHP version:  4.0.4pl1
> PHP Bug Type: MySQL related
> Bug description:  PHP 4.0.5 - Cannot connect to mySQL database
>
> I compiled and installed php 4.0.5.  Then I could not establish any
connections to the mySQL database we have.  If we switch back to php4.0.4pl1
we have no problem.
>
> PHP 4.0.5 was compiled both with and without mysql config flags.
>
>
> --
> Edit Bug report at: http://bugs.php.net/?id=10570&edit=1
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] RE: PHP 4.0.5 is out

[Tyson Lloyd Thwaites]

Woohoo!

Thanks guys for adding sybase_get_last_message() support!

I only just discovered that I needed it yesterday, and then
the new version comes out with the function implemented. Nice!

Thanks guys for all the good werke.

Tyson Lloyd Thwaites
I.T&e Limited



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9433 Updated: ErrorDocument 404 pointing to PHP file

[justin]

ID: 9433
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache related
Description: ErrorDocument 404 pointing to PHP file

To make this more understandable (people emailed me with questions which weren't 
posted in the report).  This scenario does work on lynx and it can not be a browser or 
apache server error because it works perfectly with 4.0.1pl2 and earlier.  Are there 
any modifications I can make in the php sources before compiling to meet my need if 
you would prefer to not modify the current php source on this feature?

Previous Comments:
---

[2001-02-28 19:42:15] [EMAIL PROTECTED]
No response?

---

[2001-02-24 17:17:08] [EMAIL PROTECTED]
If this were the case, then why does it react differently with PHP version 4.0.1pl2 
and 4.0.2?

---

[2001-02-24 16:51:21] [EMAIL PROTECTED]
Adding to this, lynx reports a 404 then continues to load the correct page.  I guess 
lynx reports a 404 if the file is not found then proceeds to the page specified for 
that error.

---

[2001-02-24 16:43:48] [EMAIL PROTECTED]
No, lynx reports a 404 error also.

---

[2001-02-23 22:34:31] [EMAIL PROTECTED]
Apache 1.3.12


I wrote a script that redirects a person to a different page based on the REQUEST_URI 
and HTTP_HOST apache variables.  Ever since PHP 4.0.2, Internet Explorer started 
reporting 404 errors instead of going to the appropriate page.  What is even more 
mysterious is that it is the IE 404 error page, not the server wide page nor the 
default 404 error page for the site.  To top it all off, it works for Opera as well as 
Netscape.  I think this must be caused by the way PHP handles headers and the way IE 
interprets them, because I can put PHP version 4.0.1pl2 on and it will work great even 
with IE, then any versions afterwards cause an error.  An example page is at 
http://test.jwdx.com I have also added header("Status: 404 Not Found") as stated in 
other bug reports.  I would not blame this on PHP except for the fact that different 
versions respond differently with all other circumstances remaining the same.

--Justin Bachus

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=9433


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

[John Hamlik]

I too have experienced this problem and can reproduce, I just changed to
the cgi version instead to eliminate the problem, which I would agree,
it is.  I have one page on a site of hundreds of pages that produces the
large process, 30MB+ and this is on a heavily used server with more than
300 processes.  So if I don't run the cgi-version the server will crash
in a matter of time as the memory is not freed and eventually will swap
itself to death.  So while the cgi-version is slightly slower, I have
reliability.

John Hamlik

-Original Message-
From: Brian Moon [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 30, 2001 3:20 PM
To: [EMAIL PROTECTED]; Andi Gutmans
Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
freed.


But the reverse side of this is that I might have one script out of 1000
that needs that much memory.  But since 20 of my httpd processes have
run
that script, they all have that much memory and are not going to let it
go
no matter what.

I basically sounds like a flaw that memory can not be freed.  Reuse in
the
same process is not free memory, it is reused memory.  And it sounds
like
there is nothing that the PHP team can do about it.

Brian Moon

-
Phorum Dev Team - http://phorum.org
Making better forums with PHP

-

Look for my presentation at ApacheCon 2001.
"Caching Dynamic Web Content to Increase Dependability and Performance"
http://www.apachecon.com/



- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Brian Moon" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, April 30, 2001 5:02 PM
Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
freed.


> At 04:59 PM 4/30/2001 -0500, Brian Moon wrote:
> >This is the answer I had previously received.  IMHO, this sucks.  We
don't
> >do SQL queries on our production site.  It is all cached.  So, SQL is
not
> >the problem.  It is most likely because of the storage of large
arrays or
> >something of that nature.
>
> Well maybe you should try and see what in your script is taking up
lots of
> memory.
>
>
> >I guess we will continue to use MaxRequestsPerChild until one day the
people
> >that wrote that memory allocation system get a clue.
>
> They are very clue full. A program which uses X MB of memory is very
likely
> to use X MB of memory again at a later time. For example, how does it
help
> you if your 14 MB were shrunk back to 10 MB on each request. The next
> request would probably make it grow back to 14 MB.
> There might be some memory management libraries that shrink the memory
back
> but I doubt you can gain much from it especially as memory
fragmentation
> can severally limit the amount of memory you can reclaim and because
of
the
> point I made before, it's probably just not worth it.
>
> If you can find a case where you really think PHP is using much too
much
> memory let me know and we can try and check together if there's a way
to
> improve the situation.
> Andi
>
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10570: PHP 4.0.5 - Cannot connect to mySQL database

[pablo]

From: [EMAIL PROTECTED]
Operating system: RedHat 6.2
PHP version:  4.0.4pl1
PHP Bug Type: MySQL related
Bug description:  PHP 4.0.5 - Cannot connect to mySQL database

I compiled and installed php 4.0.5.  Then I could not establish any connections to the 
mySQL database we have.  If we switch back to php4.0.4pl1 we have no problem.  

PHP 4.0.5 was compiled both with and without mysql config flags.


-- 
Edit Bug report at: http://bugs.php.net/?id=10570&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] CVS Account Request

[CVS Account Request]

Full name: Oliwier Ptak
Email: [EMAIL PROTECTED]
ID: aleczapka
Purpose: Translating PHP Manula into Polish - and c\'mon guys if you don\'t wanna have 
it just drop me a msg.. this is a third time I try...

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Rui Hirokawa]

I am also one of the authors of ext/iconv module.
iconv module is only for encoding translation but
jstring (renaming to mbstring) is for general multibyte string 
handling fucntions.
The encoding translation is one of functionalities of mbstring.
I think rather iconv module should be merged into mbstring in the future.

On Mon, 30 Apr 2001 19:53:11 +0300
Alexander Bokovoy <[EMAIL PROTECTED]> wrote:

> On Mon, Apr 30, 2001 at 10:47:21PM +0900, Rui Hirokawa wrote:
> > 
> > On Mon, 30 Apr 2001 15:37:14 +0300
> > Andi Gutmans <[EMAIL PROTECTED]> wrote:
> > 
> > > At 09:35 PM 4/30/2001 +0900, Rui Hirokawa wrote:
> > > 
> > > >Andi,
> > > >
> > > >We have plan to add ext/jstring which is a japanese string extension module
> > > >to php-4.0.6.
> > > >Is there any problem to add this module on CVS tree now ?
> > > 
> > > No I don't see a problem with this but please do it quickly. 4.0.6 has 
> > > already gone a long way since we started RC'ing 4.0.5 and I would like to 
> > > start RC'ing it pretty soon. You should probably also copy 
> > > dotnet/EXPERIMENTAL to your directory until it becomes completely stable.
> > 
> > I did.
> > 
> > > 
> > > By the way, do you think jstring is the right name? Is it only for Japanese?
> > 
> > It includes some functions for japanese,but some functions are not 
> > only for japanese.
> > For example, this module supports encoding conversion functionality between
> > Unicode and some other encodings like ISO-8859-X.
> > Currently, it includes encoding conversion filter for japanese and ISO-8859-X,
> > but it is relatively easy task to add another conversion filter for some other
> > language.
> > 
> > I believe this module is small step for PHP internationalization.
> > I think the name 'jstring' is right name now because it is existing
> > for japanese string function now.
> > But  'i18n' or 'wchar' or 'i18n-ja' are also the candidate for the name.
> It would be very good to join this features with existing iconv extension
> rather than generate new extensions.


-- 
--
Rui Hirokawa <[EMAIL PROTECTED]>
maintainer of japanese PHP manual <[EMAIL PROTECTED]>

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] php.ini location

[Zeev Suraski]

Nope

At 02:25 1/5/2001, Sean R. Bright wrote:
>This wasn't the case with the 4.0.5 branch was it?
>
> > -Original Message-
> > From: Mike Robinson [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, April 30, 2001 6:29 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [PHP-DEV] php.ini location
> >
> >
> >
> > > [Andi Gutmans <[EMAIL PROTECTED]>]
> > > > Hi,
> > > >
> > > > The default location of php.ini in the current CVS seems to be
> > > > /usr/local/etc. Didn't we say we're saving this one for
> > 4.1.x? I just
> > > > got bitten by this and I bet there will be a huge amount
> > of people who
> > > > will too.
> > >
> > > I'll change it back.
> > >
> > >  - Stig
> > >
> >
> >
> > Phew.
> > :>
> >
> > Mike Robinson
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail:
> > [EMAIL PROTECTED]
> >
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10569: xslt_error handling

[msopacua]

From: [EMAIL PROTECTED]
Operating system: BSD
PHP version:  4.0.4pl1
PHP Bug Type: Sablotron XSL
Bug description:  xslt_error handling

Hi,

again - the error handling issue.
I read the closed bugs and am surprised at the speed at which they are closed.

First of all - a documentation issue:
xslt_set_error_handler isn't documented. Thank you for mentioning it briefly, and then 
letting me figure out the arguments the called function needs.

Secondly - dying with a Fatal error, DOES occur, when the error handler isn't set! 
Even when using @xslt_process.

Try this one:
http://www.w3.org/1999/XSL/Transform";>





  












';

$xmlData = '

Learning German
Sterling Hughes

Essential phrases:

Können Sie mir sagen, wo die Toilette ist?
Ein grosses Bier, bitte!
Noch eins, bitte.

';
function xsl_error($errno, $errstr)
{
echo "\$errorstr: $errstr";
return false;
}
//xslt_set_error_handler("xsl_error");
if (@xslt_process($xslData, $xmlData, $result)) {
echo "Here is the brilliant in-depth article on learning";
echo " German: ";
echo "\n";
echo $result;
} else {
echo "There was an error that occurred in the XSL transformation...\n";
echo "\tError number: " . xslt_errno() . "\n";
echo "\tError string: " . xslt_error() . "\n";
//exit;
}
?>



You won't see the closing body and html tags.

Uncommenting the xslt_set_error_handler() will. The errorstr output, however - is 
numeric.
So can we at least have updated documentation on how to trap errors? And how 
xslt_set_error_handler() must be used?



-- 
Edit Bug report at: http://bugs.php.net/?id=10569&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] php.ini location

[Sean R. Bright]

This wasn't the case with the 4.0.5 branch was it?

> -Original Message-
> From: Mike Robinson [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 30, 2001 6:29 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] php.ini location
> 
> 
> 
> > [Andi Gutmans <[EMAIL PROTECTED]>]
> > > Hi,
> > > 
> > > The default location of php.ini in the current CVS seems to be
> > > /usr/local/etc. Didn't we say we're saving this one for 
> 4.1.x? I just
> > > got bitten by this and I bet there will be a huge amount 
> of people who
> > > will too.
> > 
> > I'll change it back.
> > 
> >  - Stig
> > 
> 
> 
> Phew.
> :>
> 
> Mike Robinson
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: 
> [EMAIL PROTECTED]
> 

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Bug #10567: Your PHP 4.05 Zip file is missing 88 bytes!

[James Moore]

This seems definiatly to be the case.. (I would build one but on a 56k its
going to take a few hours before its upthere)

- James

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 30 April 2001 23:18
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] Bug #10567: Your PHP 4.05 Zip file is missing 88
> bytes!
>
>
> From: [EMAIL PROTECTED]
> Operating system: Win 32
> PHP version:  4.0.4pl1
> PHP Bug Type: *General Issues
> Bug description:  Your PHP 4.05 Zip file is missing 88 bytes!
>
> Your PHP 4.05 Windows 32 ZIP file, complete install, appears to
> be bad. After downloading, I am told it is missing 88 bytes of
> data and is unusable.
>
>
> --
> Edit Bug report at: http://bugs.php.net/?id=10567&edit=1
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10071 Updated: print and echo dont work for string of size >65k

[andi]

ID: 10071
Updated by: andi
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Scripting Engine problem
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

Fixed in latest CVS. By the way, size_t on Windows is 32bit so the 64KB limit must be 
some internal buffer size of the Standard C I/O library of Windows.

Previous Comments:
---

[2001-03-29 23:29:00] [EMAIL PROTECTED]
If you try to print (or echo) a variable string with size larger than 65k, It does not 
work.
The reason of this is that the engine uses fwrite function with str_length (in this 
case say it is 155000) so fwrite fails because it uses size_t which is defined as 
unsigned int (limited to 65k).



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10071&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10568: error using ODBC

[hpincheira]

From: [EMAIL PROTECTED]
Operating system: Win 98
PHP version:  4.0.4pl1
PHP Bug Type: ODBC related
Bug description:  error using ODBC

Hello:  
  
I am using a database called " RECITAL ".  I am trying to connect myself using ODBC.  
When executing the command: odbc_exec($connect, $query) I can revise the connection 
from the database and indeed her ago.  But then treatment of consenting to the data 
using any function ODBC, for example:   
  
odbc_result_all($connect, BGCOLOR = ' #AAFFAA ' border=3 width=30% bordercolordark = ' 
#FF '");  
---  
  
  
 and it throws me this error:  
  
-  
Warning: Not tuples available at this result index in programa/apache c:/archivos 
group/apache/htdocs/b.html on line 7  
-  
  
I need to know if they can help me with this.  
  
thank you.  
  
  
(the table if it exists, some fields is: nlocal,ncontr)  
  
This is the program php:  
---  
  
 
  
  
  
---


-- 
Edit Bug report at: http://bugs.php.net/?id=10568&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] php.ini location

[Mike Robinson]

> [Andi Gutmans <[EMAIL PROTECTED]>]
> > Hi,
> > 
> > The default location of php.ini in the current CVS seems to be
> > /usr/local/etc. Didn't we say we're saving this one for 4.1.x? I just
> > got bitten by this and I bet there will be a huge amount of people who
> > will too.
> 
> I'll change it back.
> 
>  - Stig
> 


Phew.
:>

Mike Robinson

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10539 Updated: still - unresolved reference to compress

[dtalk]

ID: 10539
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Compile Failure
Description: still - unresolved reference to compress

Thanks for your response. Info you requested is below.  I'm afraid I don't know what 
to look for in this case, so let me know if you need anything else. -d

Output of 'ldd /usr/local/mysql-3.23.37/lib/mysql/libmysqlclient.so':

libcrypt_i.so.1 =>   /usr/lib/libcrypt_i.so.1
libgen.so.1 =>   /usr/lib/libgen.so.1
libsocket.so.1 =>/usr/lib/libsocket.so.1
libnsl.so.1 =>   /usr/lib/libnsl.so.1
libm.so.1 => /usr/lib/libm.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 =>/usr/lib/libdl.so.1
libmp.so.2 =>/usr/lib/libmp.so.2
/usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1

I verified that all these libraries are present.

config.log info:

Run 1:
 ./configure --with-mysql=/usr/local/mysql-3.23.37 --with -apache=../apache_1.3.
19 --enable-track-vars --with-imap=../imap-2001.BETA.SNAP-0104241750 --enable-sy
svsem --enable-sysvshm

Prodiced this in config.log 
configure:49857: checking whether to include zlib support
No other messages related to zlib.

Run 2:
 ./configure --with-mysql=/usr/local/mysql-3.23.37 --with -apache=../apache_1.3.
19 --enable-track-vars --with-imap=../imap-2001.BETA.SNAP-0104241750 --enable-sy
svsem --enable-sysvshm --with-zlib=/usr/local/zlib-1.1.3

aborts with:
configure: error: Zlib module requires zlib >= 1.0.9.

and this in config.log:

configure:49857: checking whether to include zlib support
configure:50058: checking for gzgets in -lz
configure:50077: gcc -o conftest -g -O2  -D_POSIX_PTHREAD_SEMANTICS -DSUPPORT_UT
F8 -DXML_BYTE_ORDER=21 -L/usr/local/zlib-1.1.3/lib  -R/usr/ucblib -L/usr/ucblib 
-R/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 -L/usr/local/lib/gcc-lib/sp
arc-sun-solaris2.8/2.95.2 -R/usr/local/src/www/imap-2001.BETA.SNAP-0104241750/c-
client -L/usr/local/src/www/imap-2001.BETA.SNAP-0104241750/c-client -R/usr/local
/mysql-3.23.37/lib/mysql -L/usr/local/mysql-3.23.37/lib/mysql conftest.c -lz  -l
mysqlclient -lcrypt -lresolv -lresolv -lm -ldl -lnsl -lsocket  -lsocket -lgcc 1>
&5
Undefined   first referenced
 symbol in file
 uncompress  /usr/local/mysql-3.23.37/lib/mysql/libmysql
c
 lient.so
 compress/usr/local/mysql-3.23.37/lib/mysql/libmysql
c
 lient.so
 ld: fatal: Symbol referencing errors. No output written to conftest
 collect2: ld returned 1 exit status
 configure: failed program was:
 #line 50066 "configure"

Tried editing configure, change line # 14725 to:
 14725  LIBS="$LIBS -lz"
Get same result as Run #2 above.



Previous Comments:
---

[2001-04-29 22:23:04] [EMAIL PROTECTED]
What does 
'ldd /usr/local/mysql-3.23.37/lib/mysql/libmysqlclient.so'
output?

What is in config.log about zlib??

--Jani


---

[2001-04-28 13:33:01] [EMAIL PROTECTED]
Solaris 8 / gcc.  Unresolved symbol errors during php
configure.  I have seen lots of information about this,
but none of the fixes I've encountered have worked.  I have:

- tried adding -lz to LTLIBRARY_LDFLAGS in Makefile
- tried adding --with-zlib-dir=/usr/local/zlib-1.1.3
- tried adding --with-zlib, or --with-zlib=/usr/local/zlib-1.1.3
- changed LIBS="-$LIBS -lz" in configure
- tried installing zlib to system location (--prefix=/usr)
- obtained latest CVS tree and built, with same results.

Output of debug.log follows.  Thank you -David

--

CONFIGURE:   './configure' '--with-mysql=/usr/local/mysql-3.23.37' 
'--with-apache=../apache_1.3.19' '--enable-tr
ack-vars' '--with-imap=../imap-2001.BETA.SNAP-0104241750' '--enable-sysvsem' 
'--enable-sysvshm' '--with-config-f
ile-path=/etc/apache' '--with-zlib'
CC: gcc
CFLAGS: -g -O2
CPPFLAGS:-D_POSIX_PTHREAD_SEMANTICS
CXX:
CXXFLAGS:   
INCLUDES:-I/usr/local/src/www/apache_1.3.19/src/include 
-I/usr/local/src/www/apache_1.3.19/src/os/unix  -I$(
top_builddir)/Zend -I/usr/local/src/www/imap-2001.BETA.SNAP-0104241750/c-client 
-I/usr/local/mysql-3.23.37/inclu
de/mysql
LDFLAGS: -R/usr/ucblib -L/usr/ucblib 
-R/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 -L/usr/local/lib/g
cc-lib/sparc-sun-solaris2.8/2.95.2 
-R/usr/local/src/www/imap-2001.BETA.SNAP-0104241750/c-client -L/usr/local/src
/www/imap-2001.BETA.SNAP-0104241750/c-client -R/usr/local/mysql-3.23.37/lib/mysql 
-L/usr/local/mysql-3.23.37/lib
/mysql
LIBS:   -lmysqlclient -lresolv -lresolv -lm -ldl -lcrypt -lnsl -lsocket  -lsocket 
-lgcc
DLIBS:  -lc-client 
SAPI:   apache
PHP_RPATHS:  /usr/ucblib /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/

[PHP-DEV] Bug #10567: Your PHP 4.05 Zip file is missing 88 bytes!

[ahulse]

From: [EMAIL PROTECTED]
Operating system: Win 32
PHP version:  4.0.4pl1
PHP Bug Type: *General Issues
Bug description:  Your PHP 4.05 Zip file is missing 88 bytes!

Your PHP 4.05 Windows 32 ZIP file, complete install, appears to be bad. After 
downloading, I am told it is missing 88 bytes of data and is unusable.


-- 
Edit Bug report at: http://bugs.php.net/?id=10567&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

[Brian Moon]

But the reverse side of this is that I might have one script out of 1000
that needs that much memory.  But since 20 of my httpd processes have run
that script, they all have that much memory and are not going to let it go
no matter what.

I basically sounds like a flaw that memory can not be freed.  Reuse in the
same process is not free memory, it is reused memory.  And it sounds like
there is nothing that the PHP team can do about it.

Brian Moon
-
Phorum Dev Team - http://phorum.org
Making better forums with PHP
-

Look for my presentation at ApacheCon 2001.
"Caching Dynamic Web Content to Increase Dependability and Performance"
http://www.apachecon.com/



- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Brian Moon" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, April 30, 2001 5:02 PM
Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.


> At 04:59 PM 4/30/2001 -0500, Brian Moon wrote:
> >This is the answer I had previously received.  IMHO, this sucks.  We
don't
> >do SQL queries on our production site.  It is all cached.  So, SQL is not
> >the problem.  It is most likely because of the storage of large arrays or
> >something of that nature.
>
> Well maybe you should try and see what in your script is taking up lots of
> memory.
>
>
> >I guess we will continue to use MaxRequestsPerChild until one day the
people
> >that wrote that memory allocation system get a clue.
>
> They are very clue full. A program which uses X MB of memory is very
likely
> to use X MB of memory again at a later time. For example, how does it help
> you if your 14 MB were shrunk back to 10 MB on each request. The next
> request would probably make it grow back to 14 MB.
> There might be some memory management libraries that shrink the memory
back
> but I doubt you can gain much from it especially as memory fragmentation
> can severally limit the amount of memory you can reclaim and because of
the
> point I made before, it's probably just not worth it.
>
> If you can find a case where you really think PHP is using much too much
> memory let me know and we can try and check together if there's a way to
> improve the situation.
> Andi
>
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

[Andi Gutmans]

At 04:59 PM 4/30/2001 -0500, Brian Moon wrote:
>This is the answer I had previously received.  IMHO, this sucks.  We don't
>do SQL queries on our production site.  It is all cached.  So, SQL is not
>the problem.  It is most likely because of the storage of large arrays or
>something of that nature.

Well maybe you should try and see what in your script is taking up lots of 
memory.


>I guess we will continue to use MaxRequestsPerChild until one day the people
>that wrote that memory allocation system get a clue.

They are very clue full. A program which uses X MB of memory is very likely 
to use X MB of memory again at a later time. For example, how does it help 
you if your 14 MB were shrunk back to 10 MB on each request. The next 
request would probably make it grow back to 14 MB.
There might be some memory management libraries that shrink the memory back 
but I doubt you can gain much from it especially as memory fragmentation 
can severally limit the amount of memory you can reclaim and because of the 
point I made before, it's probably just not worth it.

If you can find a case where you really think PHP is using much too much 
memory let me know and we can try and check together if there's a way to 
improve the situation.
Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

[Brian Moon]

This is the answer I had previously received.  IMHO, this sucks.  We don't
do SQL queries on our production site.  It is all cached.  So, SQL is not
the problem.  It is most likely because of the storage of large arrays or
something of that nature.

I guess we will continue to use MaxRequestsPerChild until one day the people
that wrote that memory allocation system get a clue.

Brian Moon
-
Phorum Dev Team - http://phorum.org
Making better forums with PHP
-

Look for my presentation at ApacheCon 2001.
"Caching Dynamic Web Content to Increase Dependability and Performance"
http://www.apachecon.com/



- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Brian Moon" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, April 30, 2001 2:54 PM
Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.


> Memory is never returned to the system with libc memory allocation.
> When you need memory it enlarges the address space it is using. Freeing
> memory won't make it shrink its address space.
> All I can suggest is to write your scripts in a way that if it deals with
> many SQL queries free a query before you do the next. This way the maximum
> size of your scripts memory space will hopefully be smaller.
>
> Andi
>
> At 02:37 PM 4/30/2001 -0500, Brian Moon wrote:
> >The big problem is that the memory is never returned to the system.  The
> >Apache process holds on to it until it dies.
> >
> >Brian Moon
> >-
> >Phorum Dev Team - http://phorum.org
> >Making better forums with PHP
> >-
> >
> >Look for my presentation at ApacheCon 2001.
> >"Caching Dynamic Web Content to Increase Dependability and Performance"
> >http://www.apachecon.com/
> >
> >
> >
> >- Original Message -
> >From: "Andi Gutmans" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> >Sent: Monday, April 30, 2001 1:45 PM
> >Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
freed.
> >
> >
> > > 14MB of memory in use isn't necessarily that much. Some of that memory
> > > might be in shared libraries (shared across the Apache processes). Are
you
> > > doing any big SQL queries in those scripts?
> > > Do you have time to do some tests and let us know if things improve?
> > >
> > > Andi
> > >
> > > At 06:31 PM 4/30/2001 +, [EMAIL PROTECTED] wrote:
> > > >ID: 8889
> > > >User Update by: [EMAIL PROTECTED]
> > > >Status: Open
> > > >Bug Type: Performance problem
> > > >Description: Memory is not being freed.
> > > >
> > > >I am talking about nearly endless amounts.  I saw Apache processes
with
> >as
> > > >much as 14MB of memory in use.
> > > >
> > > >Brian.
> > > >
> > > >Previous Comments:
> > >
> >
>---
> > > >
> > > >[2001-04-29 19:59:56] [EMAIL PROTECTED]
> > > >What kind of sizes are we talking about here?  the Zend memory
manager
> > > >holds a memory cache, but we're talking at around 1MB per process
max.
> > > >
> > >
> >
>---
> > > >
> > > >[2001-01-26 18:45:45] [EMAIL PROTECTED]
> > > >Ok, this is just like what is described in
> > > >http://marc.theaimsgroup.com/?l=php-dev&m=97923602322593&w=2 which
> > > >contains a hacked up solution.  It looks like it should be able to
turn
> > > >into a usable end solution.
> > > >
> > >
> >
>---
> > > >
> > > >[2001-01-24 13:21:13] [EMAIL PROTECTED]
> > > >Hi guys,
> > > >
> > > >I do not have much information.  I know that my Apache processes
memory
> >is
> > > >growing by the minute.  If I start a separate server on another port
and
> > > >serve only static pages and files through it, those process do not
grow.
> > > >
> > > >I have tried what I remembered of gdb but have not come up with
> > > >anything.  I know I need to attach to a process and it seems I can
`gdb
> > > >{pid}` but that gives me nothing.  How can I get some info for you
> > > >guys?  I do have --enable-debug.
> > > >
> > > >thanks,
> > > >
> > > >Brian.
> > > >Phorum.org
> > > >
> > >
> >
>---
> > > >
> > > >
> > > >Full Bug description available at: http://bugs.php.net/?id=8889
> > > >
> > > >
> > > >--
> > > >PHP Development Mailing List 
> > > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >For additional commands, e-mail: [EMAIL PROTECTED]
> > > >To contact the list administrators, e-mail:
[EMAIL PROTECTED]
> > >
> > >
>
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [E

Re: [PHP-DEV] 4.0.6

[Andi Gutmans]

At 05:56 AM 5/1/2001 +0900, [EMAIL PROTECTED] wrote:

>On Mon, 30 Apr 2001 18:27:26 +0300
>Andi Gutmans wrote:
>
> > At 12:23 AM 5/1/2001 +0900, Rui Hirokawa wrote:
> >
> > >On Mon, 30 Apr 2001 17:26:58 +0300
> > >Andi Gutmans <[EMAIL PROTECTED]> wrote:
> > >
> > > > At 10:01 PM 4/29/2001 -0400, Sterling Hughes wrote:
> > > > >ext/wchar (wide character support?)
> > > > >ext/mstring (multibyte string functions)
> > > > >ext/jpstring (japanese string functions)
> > > >
> > > > I'd make mstring -> mbstring.
> > > > The question is if it's worth splitting this up into more than one
> > > > extension. Probably not.
> > > > So we should probably be picking out of wchar, mbstring, jpstring.
> > > > Rui, what do you think?
> > >
> > >I prefer unified approach is better for php-i18n than splitting
> > >some modules.
> > >I think mbstring is better, although this module also
> > >supports single-byte encoding like ISO-8859-X.
> > >Some people might say 'wchar' is better choise,
> > >because this module converts string to wide character internally.
> > >
> > >If someone want to add some other encoding support,
> > >he should add mbfilter_xx.c mbfilter_xx.h where xx means some
> > >specific language like ja (japanese).
> > >
> > >Anyway, because I am not original author of this module,
> > >I must discuss to Mr. Tsukada ,the original author of jstring
> > >about renaming the module.
> >
> > OK. I think wchar or mbstring are both good. jstring will just confuse 
> people.
> >
>
>I think mbstring is nice.

Sounds good.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0.5 is out

[Zeev Suraski]

After a very long QA process, PHP 4.0.5 has finally been officially 
released.  This is a maintenance version, with a lot of bug fixes from PHP 
4.0.4pl1.  Other than that, there aren't too many new features in this 
release, so it's mostly recommended for people that were experiencing one 
(or more) of the bugs that were fixed.  Note that PHP 4.0.6 is also planned 
for the near future, featuring mostly bug fixes;  This may affect your 
upgrade considerations.

Notable features:
- High performance output compression support and improved output buffering
- Experimental FastCGI module
- A lot of PEAR work
- Significantly improved thread safety (users of multithreaded servers 
should definitely upgrade if they have earlier versions of PHP)

Full list of changes is available at http://www.php.net/ChangeLog-4.php, 
and is also attached at the end of this letter.  Thanks goes to the PHP QA 
team, which worked a lot to make sure that this release works as well as 
expected, and beyond.  Special thanks to Mr. J, which managed to survive 
the long and thrilling QA process without getting a heart attack :)

Zeev

30 Apr 2001, Version 4.0.5
- IMPORTANT: removed /F modifier handling from preg_replace(). Instead
   one should use new preg_replace_callback() function. (Andrei)
- Added new php.ini directive: arg_separator.input which is used to tell
   PHP which characters are considered as argument separators in URLs.
   Renamed php.ini directive: arg_separator -> arg_separator.output (Jani)
- Added FastCGI SAPI module. (Ben Mansell)
- Added array_reduce(), which allows iterative reduction of an array
   to a single value via a callback function. (Andrei)
- The imageloadfont function of the gd extension should be not platform
   dependent after this fix. ([EMAIL PROTECTED])
- Fixed a compatibility problem in some file functions (fgets, fputs, fread,
   fwrite). The ANSI standard says that if a file is opened in read/write
   mode, fseek() should be called before switching from reading to writing
   and vice versa. ([EMAIL PROTECTED])
- Fixed argument checking for call_user_func* functions and allowed
   specifying array($obj, 'method') syntax for call_user_func_array. (Andrei)
- Fixed parent::method() to also work with runtime bindings.
   (Zeev, Zend Engine)
- Implemented high-performance zlib-based output compression - see
   zlib.output_compression INI directive. (Zeev)
- Improved ob_gzhandler() to support chunked output buffering - it's
   recommended to use it with 4KB chunks. (Zeev)
- Fixed chunked output buffering. (Zeev)
- Forced call_user_method() and call_user_method_array() to take the
   object argument by reference. (Andrei)
- Fixed binding of ROWIDs in OCI8. (Thies)
- Added PEAR/Cache as a generic Caching System. (Sebastian, PEAR/Cache)
- Added IMAP quota support (imap_set_quota, imap_get_quota), enabled/added via
   c-client2000. (kalowsky)
- Upgraded PCRE to version 3.4. (Andrei)
- Added array_search which works similar to in_array but returns
   the key instead of a boolean. ([EMAIL PROTECTED])
- Fixed pgsql transaction support. (Stig, PEAR/DB)
- Added new object VARIANT() to encapsulate values for use with
   the COM and DOTNET module. Therefore it is now possible to pass
   values by reference, convert php values to extended variant types (currency,
   date, idispatch, iunknown, ...) and define the codepage that should
   be used for unicode - conversion.
- Improved overall speed of IRCG, added URL handling to message scanner.
   (Sascha)
- Fixed some modules to allow using output-buffering. (Thies)
- Added the chroot() function. (Derick)
- PostgreSQL now does a rollback at the end of a request on every
   persistent connection. This is done by doing an "empty" transaction
   on the connection. This was advised by someone from the PostgreSQL
   core-team. (Thies)
- Fixed PostgeSQL pg_connect() bug. We would sometimes close the default
   link by accident. (Patch by: [EMAIL PROTECTED])
- Improved OCI8 dead-session detection. (Patch by: George Schlossnagle)
- Fixed get_meta_tags() multiline bug #4556. (Sean)
- Prefer random() over *rand48(). (JimJag)
- Sped up WDDX serialization 2x. (Andrei)
- Added a new parameter to mail() which appends aditional command line
   parameters to the mail program. (Derick)
- Added Udm_Clear_Search_Limits mnoGoSearch extension function. (gluke)
- Fixed mnogosearch protos. Fixed mnogosearch functions return values.
   A bug with capital letters break search has been fixed. (gluke)
- Static methods can now be called via call_user_method_* functions, e.g.
   call_user_method('method', 'class'), and also array('class', 'method')
   constructs (for array_walk(), for example). (Andrei, Zend Engine)
- microtime() under Windows now returns accurate values. (James)
- Added PREG_SPLIT_DELIM_CAPTURE flag to preg_split() that allows for Perl-like
   functionality of capturing parenthesized delimiter expression. (Andrei)
- Fixed strip_tags() to not strip a lone > character. (Rasmus)
-

[PHP-DEV] Bug #10538 Updated: mcrypt_generic_init truncates key/iv upon first '\0'

[derick]

ID: 10538
Updated by: derick
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: mcrypt related
PHP Version: 4.0.4pl1
Assigned To: derick
Comments:

It's fixed in CVS as you say (and it is fixed in 4.0.5 too BTW_

Previous Comments:
---

[2001-04-30 05:43:16] [EMAIL PROTECTED]
Seems to be a duplicate of Bug #8839 and it is already fixed in CVS.

---

[2001-04-28 12:50:42] [EMAIL PROTECTED]
Same happens in mcrypt_ecb, mcrypt_cbc, mcrypt_cfb and mcrypt_ofb too.


Script showing the bug:



The two ciphertexts should NOT be the same as the key is different.


Proposed patch (also fixes a possible memory access problem, but only for the 
mcrypt_generic_init function, the I didn't fully understand php_mcrypt_do_crypt yet, 
when I do I will update the patch, see also Bug #10518):

--- php-4.0.4pl1/ext/mcrypt/mcrypt.cWed Nov 22 22:40:15 2000
+++ php-4.0.4pl1-sk/ext/mcrypt/mcrypt.c Sat Apr 28 18:53:07 2001
@@ -463,14 +463,22 @@
Z_STRLEN_PP(key), key_size);
php_error (E_NOTICE, dummy);
}
-   strncpy (key_s, Z_STRVAL_PP(key), key_size);
+   if (Z_STRLEN_PP(key) > key_size) {
+   memcpy (key_s, Z_STRVAL_PP(key), key_size);
+   } else {
+   memcpy (key_s, Z_STRVAL_PP(key), Z_STRLEN_PP(key));
+   }
 
if (Z_STRLEN_PP(iv) != iv_size) {
sprintf (dummy, "iv size incorrect; supplied length: %d, needed: %d", 
Z_STRLEN_PP(iv), iv_size);
php_error (E_WARNING, dummy);
}
-   strncpy (iv_s, Z_STRVAL_PP(iv), iv_size);
+   if (Z_STRLEN_PP(iv) > iv_size) {
+   memcpy (iv_s, Z_STRVAL_PP(iv), iv_size);
+   } else {
+   memcpy (iv_s, Z_STRVAL_PP(iv), Z_STRLEN_PP(iv));
+   }
 
RETVAL_LONG (mcrypt_generic_init (td, key_s, key_size, iv_s));
efree (iv_s);

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10538&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10566: don't work properly fopen

[erick]

From: [EMAIL PROTECTED]
Operating system: Windows NT/ Unix FreeBSD
PHP version:  4.0.4pl1
PHP Bug Type: Filesystem function related
Bug description:  don't work properly fopen

this scrip don't work properly:
(only the first time, that's ok)
ftp://usr:pass@localhost/administrador/servicios5.inc","w";);
fputs($file,"Algo");
fclose($file);
?>

this the warning:

Warning: File already exists in generaservicios.inc on line 1

Warning: fopen("ftp://...@localhost/administrador/servicios5.inc","w";) - File exists 
in generaservicios.inc on line 1

Warning: Supplied argument is not a valid File-Handle resource in generaservicios.inc 
on line 2

Warning: Supplied argument is not a valid File-Handle resource in generaservicios.inc 
on line 97



-- 
Edit Bug report at: http://bugs.php.net/?id=10566&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10565: mysql_real_connect dumps core, fix included

[glen]

From: [EMAIL PROTECTED]
Operating system: SCO OpenServer 5.0.6
PHP version:  4.0.4pl1
PHP Bug Type: MySQL related
Bug description:  mysql_real_connect dumps core, fix included

** This is a problem in MySql.  This report provides a code
modification to compensate for the MySql problem. **

Under SCO OpenServer 5.0.6, Apache 1.3.19, PHP 4.0.4 PL 1,
and MySql 3.23.36 (precompiled MySQL for OpenServer 5.0.x),
calls to mysql_real_connect will silently dump core if
mysql_init was not allowed to *allocate* the memory for the
MySQL structure.

To function properly, mysql_init must be passed NULL, thus
allowing it to allocate and manage the memory.  If you use
a previously malloc()'ed or static structure, MySQL will 
dump core on connect.

We find this problem to be present in MySQL, and can 
duplicate it using a C code stub.  The problem, of course,
also exists in PHP, causing a core dump there as well,
since PHP pre-malloc()'s its own structure.

Here is a DIFF for ext/mysql/php_mysql.c which fixes the
problem for us.  It's ugly, and hack-y, but it works.  FYI.

198c198
<   efree(link);
---
>   /* efree(link); */
456c456
<   mysql = (MYSQL *) malloc(sizeof(MYSQL));
---
>   /* mysql = (MYSQL *) malloc(sizeof(MYSQL)); */
458c458
<   mysql_init(mysql);
---
>   mysql = mysql_init(NULL);
542c542
<   mysql = (MYSQL *) emalloc(sizeof(MYSQL));
---
>   /* mysql = (MYSQL *) emalloc(sizeof(MYSQL)); */
544c544
<   mysql_init(mysql);
---
>   mysql = mysql_init(NULL);



-- 
Edit Bug report at: http://bugs.php.net/?id=10565&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[tsukada]

On Mon, 30 Apr 2001 18:27:26 +0300
Andi Gutmans wrote:

> At 12:23 AM 5/1/2001 +0900, Rui Hirokawa wrote:
> 
> >On Mon, 30 Apr 2001 17:26:58 +0300
> >Andi Gutmans <[EMAIL PROTECTED]> wrote:
> >
> > > At 10:01 PM 4/29/2001 -0400, Sterling Hughes wrote:
> > > >ext/wchar (wide character support?)
> > > >ext/mstring (multibyte string functions)
> > > >ext/jpstring (japanese string functions)
> > >
> > > I'd make mstring -> mbstring.
> > > The question is if it's worth splitting this up into more than one
> > > extension. Probably not.
> > > So we should probably be picking out of wchar, mbstring, jpstring.
> > > Rui, what do you think?
> >
> >I prefer unified approach is better for php-i18n than splitting
> >some modules.
> >I think mbstring is better, although this module also
> >supports single-byte encoding like ISO-8859-X.
> >Some people might say 'wchar' is better choise,
> >because this module converts string to wide character internally.
> >
> >If someone want to add some other encoding support,
> >he should add mbfilter_xx.c mbfilter_xx.h where xx means some
> >specific language like ja (japanese).
> >
> >Anyway, because I am not original author of this module,
> >I must discuss to Mr. Tsukada ,the original author of jstring
> >about renaming the module.
> 
> OK. I think wchar or mbstring are both good. jstring will just confuse people.
> 

I think mbstring is nice.

 Takuya Tsukada



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #7016 Updated: Error when starting iPlanet

[sniper]

ID: 7016
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: iPlanet related
PHP Version: 4.0.2
Assigned To: 
Comments:

status -> feedback

Previous Comments:
---

[2001-04-30 04:43:38] [EMAIL PROTECTED]
Try the following obj.conf entry, and see if it fixes your problem.  Apart from this 
change, you should follow the manual entry for the rest of the obj.conf

Init fn="load-modules" shlib="/path/to/server4/bin/libphp4.so" 
funcs="php4_init,php4_close,php4_execute,php4_auth_trans"
Init fn="php4_init" LateInit="yes" 

---

[2000-11-03 21:01:15] [EMAIL PROTECTED]
reclassified

---

[2000-10-04 12:41:54] [EMAIL PROTECTED]
This is the error I got when restarting iPlanet via command line after installing PHP4 
w/o any errors showing up:

conf_init: Error running init function load-modules: dlopen of 
/usr/netscape/server/bin/libphp4.so failed (ld.so.1: ns-httpd: fatal: relocation 
error: file /usr/netscape/server/bin/libphp4.so: symbol __pure_virtual: referenced 
symbol not found)

Can you give me an ideas on what's going on here? Thanks.






We're using the GCC2.95.2 also. After configure, make and make install, these are  the 
steps I did:

1. add the ff line in mime.types
type=magnus-internal/x-httpd-phpexts=php

2. edit obj.conf
# note place following two lines after mime types init!
Init fn="load-modules" funcs="php4_init,php4_close,php4_execute,php4_auth_trans" 
shlib="/usr/netscape/server/bin/libphp4.so"
Init fn=php4_init errorString="Failed to initialize PHP!"


.
.
. # NOTE this next line should happen after all 'ObjectType' and before all 'AddLog' 
lines
Service fn="php4_execute" type="magnus-internal/x-httpd-php"
.
.




ObjectType fn="force-type" type="magnus-internal/x-httpd-php"
Service fn=php4_execute



Are these correct?

Thanks,
Lester




---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=7016&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10453 Updated: mod_auth_mysql and php4.0.5pl1

[sniper]

ID: 10453
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Apache related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

You have to use the external mysql client libraries
when you have some other modules in Apache that use
mysql. ie. configure --with-mysql=/path/to/mysql
(remember to delete config.cache first!)
And do 'make clean' after configure.

There is no bugs in PHP regarding this issue. 
I myself use mod_auth_mysql with latest PHP (4.0.5) 
without any problems.

Ask further questions on [EMAIL PROTECTED]

--Jani


Previous Comments:
---

[2001-04-30 04:09:04] [EMAIL PROTECTED]
I am using mysql and the mod_auth_mysql for a long time with
older versions of php without problem.
All mysql-Operations still work as before.

It seems to me that the autorization information
(name/passwd) don't get passsed over ...

I tried to recompile with different paths in all modules
but it did not work upto now. So I still use an older php module...

---

[2001-04-23 07:16:51] [EMAIL PROTECTED]
What was your configure line? You need to give the dir to
your mysql libraries of you use other modules for apache
that use MySQL.

Like (Example):
./configure --with-mysql=/usr/local

---

[2001-04-23 07:16:35] [EMAIL PROTECTED]
What was your configure line? You need to give the dir to
your mysql libraries of you use other modules for apache
that use MySQL.

Like (Example):
./configure --with-mysql=/usr/local

---

[2001-04-23 06:47:48] [EMAIL PROTECTED]
I recompiled my Apache as follows:

apache_1.3.19  
php-4.0.4pl1
mysql-3.22.26a
mod_auth_mysql-2.20

Is there any known bug in the interoperability of these modules?

php works fine, but the mod_auth_mysql module gives
an internal error AFTER login:

Could not load complete page - and nothing shows up.

Regards,
Rupert Mohr

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10453&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10557 Updated: php does not work with php_mcrypt.dll

[sniper]

ID: 10557
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Duplicate
Status: Bogus
Bug Type: mcrypt related
PHP Version: 4.0.4
Assigned To: 
Comments:

submitted twice (#10556)


Previous Comments:
---

[2001-04-30 02:02:51] [EMAIL PROTECTED]
I am using a windows 98 machine.
I have installed php 4.0.4 using the easy installer for windows. I downloaded the 
php_mcrypt.dll file fromhttp://www.multimedia.uni-greifswald.de/~php4.
When i tried to run the test program I got the following error. unable to load 
php_mcrypt.dll.The other dll's like php_gd.dll are working.Please help me out.




---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10557&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

[Andi Gutmans]

Memory is never returned to the system with libc memory allocation.
When you need memory it enlarges the address space it is using. Freeing 
memory won't make it shrink its address space.
All I can suggest is to write your scripts in a way that if it deals with 
many SQL queries free a query before you do the next. This way the maximum 
size of your scripts memory space will hopefully be smaller.

Andi

At 02:37 PM 4/30/2001 -0500, Brian Moon wrote:
>The big problem is that the memory is never returned to the system.  The
>Apache process holds on to it until it dies.
>
>Brian Moon
>-
>Phorum Dev Team - http://phorum.org
>Making better forums with PHP
>-
>
>Look for my presentation at ApacheCon 2001.
>"Caching Dynamic Web Content to Increase Dependability and Performance"
>http://www.apachecon.com/
>
>
>
>- Original Message -
>From: "Andi Gutmans" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>Sent: Monday, April 30, 2001 1:45 PM
>Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
>
>
> > 14MB of memory in use isn't necessarily that much. Some of that memory
> > might be in shared libraries (shared across the Apache processes). Are you
> > doing any big SQL queries in those scripts?
> > Do you have time to do some tests and let us know if things improve?
> >
> > Andi
> >
> > At 06:31 PM 4/30/2001 +, [EMAIL PROTECTED] wrote:
> > >ID: 8889
> > >User Update by: [EMAIL PROTECTED]
> > >Status: Open
> > >Bug Type: Performance problem
> > >Description: Memory is not being freed.
> > >
> > >I am talking about nearly endless amounts.  I saw Apache processes with
>as
> > >much as 14MB of memory in use.
> > >
> > >Brian.
> > >
> > >Previous Comments:
> >
> >---
> > >
> > >[2001-04-29 19:59:56] [EMAIL PROTECTED]
> > >What kind of sizes are we talking about here?  the Zend memory manager
> > >holds a memory cache, but we're talking at around 1MB per process max.
> > >
> >
> >---
> > >
> > >[2001-01-26 18:45:45] [EMAIL PROTECTED]
> > >Ok, this is just like what is described in
> > >http://marc.theaimsgroup.com/?l=php-dev&m=97923602322593&w=2 which
> > >contains a hacked up solution.  It looks like it should be able to turn
> > >into a usable end solution.
> > >
> >
> >---
> > >
> > >[2001-01-24 13:21:13] [EMAIL PROTECTED]
> > >Hi guys,
> > >
> > >I do not have much information.  I know that my Apache processes memory
>is
> > >growing by the minute.  If I start a separate server on another port and
> > >serve only static pages and files through it, those process do not grow.
> > >
> > >I have tried what I remembered of gdb but have not come up with
> > >anything.  I know I need to attach to a process and it seems I can `gdb
> > >{pid}` but that gives me nothing.  How can I get some info for you
> > >guys?  I do have --enable-debug.
> > >
> > >thanks,
> > >
> > >Brian.
> > >Phorum.org
> > >
> >
> >---
> > >
> > >
> > >Full Bug description available at: http://bugs.php.net/?id=8889
> > >
> > >
> > >--
> > >PHP Development Mailing List 
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
> >


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10070 Updated: incorrect ob_gzhandler implementation

[jmoore]

ID: 10070
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Zlib Related
PHP Version: 4.0 Latest CVS (29/03/2001)
Assigned To: 
Comments:

This should have been resolved with various patches that have been added recently, 
please test with latest CVS and reopen if this is not the case. (Although once again 
can we really write workarounds for every browser that breaks the standards?)

- James

Previous Comments:
---

[2001-04-02 00:53:35] [EMAIL PROTECTED]
IIRC, it advertises both, so it shouldn't be an issue. I
don't have a windows box around to make sure with... 


---

[2001-03-30 19:45:38] [EMAIL PROTECTED]
Just to clarify a bit more, and see if a workaround is
worthwhile:

Currently, if both gzip and deflate are present in the
Accept-Encoding, we will prefer the gzip.

The only good reason for a workaround in the code is if
a widespread browser presents deflate only, and then
proceeds to break.  Do these broken versions of IE present
Accept-Encoding: deflate _only_ ?  And which versions are
they?

Anil

---

[2001-03-30 14:59:49] [EMAIL PROTECTED]
If a browser breaks RFCs -> not our problem. 
Closed.

--Jani


---

[2001-03-30 13:07:42] [EMAIL PROTECTED]
Applied a patch to add Vary: headers if we add a Content-Encoding: header.

Regarding the browser compatibility with Deflate, I think we should just leave it like 
it is.  _They_ break the RFC; encourage people to upgrade to modern, non-broken 
browsers instead ?

---

[2001-03-29 21:21:53] [EMAIL PROTECTED]
ob_gzhandler doesn't appear to set a Vary: header on
responses, which means that proxy caches could store a
compressed version of the resource and serve it to clients
which can't handle the encoding. This is very difficult to
debug for Web sites, and should be fixed ASAP.

For an example of the proper headers to send, see the PHP at:
  http://www.mnot.net/cgi_buffer/

Also, in my experience, some versions of MSIE don't handle
deflate compession correctly, even though their
Accept-Encoding claims they do. It might be better to avoid
deflate altogether, as gzip support is pretty much the
unwritten standard.

Cheers,

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10070&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

[Brian Moon]

The big problem is that the memory is never returned to the system.  The
Apache process holds on to it until it dies.

Brian Moon
-
Phorum Dev Team - http://phorum.org
Making better forums with PHP
-

Look for my presentation at ApacheCon 2001.
"Caching Dynamic Web Content to Increase Dependability and Performance"
http://www.apachecon.com/



- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, April 30, 2001 1:45 PM
Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.


> 14MB of memory in use isn't necessarily that much. Some of that memory
> might be in shared libraries (shared across the Apache processes). Are you
> doing any big SQL queries in those scripts?
> Do you have time to do some tests and let us know if things improve?
>
> Andi
>
> At 06:31 PM 4/30/2001 +, [EMAIL PROTECTED] wrote:
> >ID: 8889
> >User Update by: [EMAIL PROTECTED]
> >Status: Open
> >Bug Type: Performance problem
> >Description: Memory is not being freed.
> >
> >I am talking about nearly endless amounts.  I saw Apache processes with
as
> >much as 14MB of memory in use.
> >
> >Brian.
> >
> >Previous Comments:
>
>---
> >
> >[2001-04-29 19:59:56] [EMAIL PROTECTED]
> >What kind of sizes are we talking about here?  the Zend memory manager
> >holds a memory cache, but we're talking at around 1MB per process max.
> >
>
>---
> >
> >[2001-01-26 18:45:45] [EMAIL PROTECTED]
> >Ok, this is just like what is described in
> >http://marc.theaimsgroup.com/?l=php-dev&m=97923602322593&w=2 which
> >contains a hacked up solution.  It looks like it should be able to turn
> >into a usable end solution.
> >
>
>---
> >
> >[2001-01-24 13:21:13] [EMAIL PROTECTED]
> >Hi guys,
> >
> >I do not have much information.  I know that my Apache processes memory
is
> >growing by the minute.  If I start a separate server on another port and
> >serve only static pages and files through it, those process do not grow.
> >
> >I have tried what I remembered of gdb but have not come up with
> >anything.  I know I need to attach to a process and it seems I can `gdb
> >{pid}` but that gives me nothing.  How can I get some info for you
> >guys?  I do have --enable-debug.
> >
> >thanks,
> >
> >Brian.
> >Phorum.org
> >
>
>---
> >
> >
> >Full Bug description available at: http://bugs.php.net/?id=8889
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] php.ini location

[Stig Sæther Bakken]

[Andi Gutmans <[EMAIL PROTECTED]>]
> Hi,
> 
> The default location of php.ini in the current CVS seems to be
> /usr/local/etc. Didn't we say we're saving this one for 4.1.x? I just
> got bitten by this and I bet there will be a huge amount of people who
> will too.

I'll change it back.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10497 Updated: Not connect with MySql

[erick]

ID: 10497
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Filesystem function related
Description: Not connect with MySql

this script don't work   

ftp://user:password@localhost/administrador/servicios.inc","w";);
fputs($file,"Algo");
fclose($file);
?>

Previous Comments:
---

[2001-04-30 14:49:20] [EMAIL PROTECTED]
this script don't work   

ftp://user:password@localhost/administrador/servicios.inc","w";);
fputs($file,"Algo");
fclose($file);
?>

---

[2001-04-29 04:57:52] [EMAIL PROTECTED]
The error message 'Maximum execution time of 30 seconds exceeded' doesn't need to be 
related to MySQL, as it just says that your script's running time is longer than 
allowed.

Do you get, apart from that, any error message that indicates a relation to MySQL?

On first look your code looks okay, could it be that your query just consumes much 
time?


---

[2001-04-25 16:52:29] [EMAIL PROTECTED]
this is the error:
 
Fatal error: Maximum execution time of 30 seconds exceeded in D:Mis 
DocumentosWebtempok.php on line 2
 
and this is the script in php:
 



ok. thanks.


---

[2001-04-25 16:27:44] [EMAIL PROTECTED]
user feedback:

this is the error:
 
Fatal error: Maximum execution time of 30 seconds exceeded in D:Mis 
DocumentosWebtempok.php on line 2
 
and this is the script:
 




please, use the web interface for future updates

---

[2001-04-25 15:56:20] [EMAIL PROTECTED]
ah, right:

this worked in 4.0.3 but doesn't work in 4.0.4 pl1, right?

what error message do you get?

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=10497


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10497 Updated: Not connect with MySql

[erick]

ID: 10497
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Old-Bug Type: MySQL related
Bug Type: Filesystem function related
Description: Not connect with MySql

this script don't work   

ftp://user:password@localhost/administrador/servicios.inc","w";);
fputs($file,"Algo");
fclose($file);
?>

Previous Comments:
---

[2001-04-29 04:57:52] [EMAIL PROTECTED]
The error message 'Maximum execution time of 30 seconds exceeded' doesn't need to be 
related to MySQL, as it just says that your script's running time is longer than 
allowed.

Do you get, apart from that, any error message that indicates a relation to MySQL?

On first look your code looks okay, could it be that your query just consumes much 
time?


---

[2001-04-25 16:52:29] [EMAIL PROTECTED]
this is the error:
 
Fatal error: Maximum execution time of 30 seconds exceeded in D:Mis 
DocumentosWebtempok.php on line 2
 
and this is the script in php:
 



ok. thanks.


---

[2001-04-25 16:27:44] [EMAIL PROTECTED]
user feedback:

this is the error:
 
Fatal error: Maximum execution time of 30 seconds exceeded in D:Mis 
DocumentosWebtempok.php on line 2
 
and this is the script:
 




please, use the web interface for future updates

---

[2001-04-25 15:56:20] [EMAIL PROTECTED]
ah, right:

this worked in 4.0.3 but doesn't work in 4.0.4 pl1, right?

what error message do you get?

---

[2001-04-25 15:54:35] [EMAIL PROTECTED]
please report bugs in English. 

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=10497


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

[Andi Gutmans]

14MB of memory in use isn't necessarily that much. Some of that memory 
might be in shared libraries (shared across the Apache processes). Are you 
doing any big SQL queries in those scripts?
Do you have time to do some tests and let us know if things improve?

Andi

At 06:31 PM 4/30/2001 +, [EMAIL PROTECTED] wrote:
>ID: 8889
>User Update by: [EMAIL PROTECTED]
>Status: Open
>Bug Type: Performance problem
>Description: Memory is not being freed.
>
>I am talking about nearly endless amounts.  I saw Apache processes with as 
>much as 14MB of memory in use.
>
>Brian.
>
>Previous Comments:
>---
>
>[2001-04-29 19:59:56] [EMAIL PROTECTED]
>What kind of sizes are we talking about here?  the Zend memory manager 
>holds a memory cache, but we're talking at around 1MB per process max.
>
>---
>
>[2001-01-26 18:45:45] [EMAIL PROTECTED]
>Ok, this is just like what is described in 
>http://marc.theaimsgroup.com/?l=php-dev&m=97923602322593&w=2 which 
>contains a hacked up solution.  It looks like it should be able to turn 
>into a usable end solution.
>
>---
>
>[2001-01-24 13:21:13] [EMAIL PROTECTED]
>Hi guys,
>
>I do not have much information.  I know that my Apache processes memory is 
>growing by the minute.  If I start a separate server on another port and 
>serve only static pages and files through it, those process do not grow.
>
>I have tried what I remembered of gdb but have not come up with 
>anything.  I know I need to attach to a process and it seems I can `gdb 
>{pid}` but that gives me nothing.  How can I get some info for you 
>guys?  I do have --enable-debug.
>
>thanks,
>
>Brian.
>Phorum.org
>
>---
>
>
>Full Bug description available at: http://bugs.php.net/?id=8889
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

[brian]

ID: 8889
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
Description: Memory is not being freed.

I am talking about nearly endless amounts.  I saw Apache processes with as much as 
14MB of memory in use.

Brian.

Previous Comments:
---

[2001-04-29 19:59:56] [EMAIL PROTECTED]
What kind of sizes are we talking about here?  the Zend memory manager holds a memory 
cache, but we're talking at around 1MB per process max.

---

[2001-01-26 18:45:45] [EMAIL PROTECTED]
Ok, this is just like what is described in 
http://marc.theaimsgroup.com/?l=php-dev&m=97923602322593&w=2 which contains a hacked 
up solution.  It looks like it should be able to turn into a usable end solution.

---

[2001-01-24 13:21:13] [EMAIL PROTECTED]
Hi guys,

I do not have much information.  I know that my Apache processes memory is growing by 
the minute.  If I start a separate server on another port and serve only static pages 
and files through it, those process do not grow.

I have tried what I remembered of gdb but have not come up with anything.  I know I 
need to attach to a process and it seems I can `gdb {pid}` but that gives me nothing.  
How can I get some info for you guys?  I do have --enable-debug.

thanks,

Brian.
Phorum.org

---


Full Bug description available at: http://bugs.php.net/?id=8889


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] ODBC Build

[James Moore]

Can you please look at the patch in bug http://www.php.net/bugs.php?id=10563
and commit it if its needed/comment on the bug.

thanks

- James
--
James Moore
[EMAIL PROTECTED]
http://www.perl.com/search/index.php - we must be doing somthing right



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Imap SSL support (Bug #10330)

[J. Jones]

On Mon, Apr 30, 2001 at 01:22:32PM -0500, J. Jones wrote:
> 
> make slx SPECIALAUTHENTICATORS=ssl EXTRACFLAGS=/path/to/openssl/includes/
> 

Whoops! make that

make slx SPECIALAUTHENTICATORS=ssl EXTRACFLAGS=-I/path/to/openssl/includes/

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Imap SSL support (Bug #10330)

[J. Jones]

The imap module fails with the following (perhaps only when building
against imap-2000*):

php_imap.c: In function `php_minit_imap':
php_imap.c:450: `auth_ssl' undeclared (first use in this function)
php_imap.c:450: (Each undeclared identifier is reported only once
php_imap.c:450: for each function it appears in.)

The solution is to rebuild the imap c-client library with something
resembling

make slx SPECIALAUTHENTICATORS=ssl EXTRACFLAGS=/path/to/openssl/includes/

This just failed for me on 4.0.5-RC8 and imap-2000c.  I never built imap
in this manner previously, and the php-imap module has never failed on
releases prior to the 4.0.5-RC's, as they don't look for an auth_ssl
function in the c-client library.

Thanks!
Jeremy

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Troubles with DL'ed module

[Brian Foddy]

I'm going to try and build it statically first.  I don't have
any problem posting the code (its already avail on sourceforge
but you will need some proprietary libraries to build it).

The MINIT and/or RINIT is the constants are initialized.

You've given me some to go on, I'll work with it for
a day or so first.  Thanks,
Brian


Andi Gutmans wrote:
> 
> Sounds like some kind of memory corruption. With these kind of problems
> even the order of statements can make a difference. Do you want to post
> those two functions and we can take a look at them? Also are your RINIT() &
> MINIT() functions doing anything? Maybe they are causing problems?
> 
> Andi
> 
> At 11:17 AM 4/30/2001 -0500, Brian Foddy wrote:
> 
> >One more strange behavior I just saw.
> >
> >Take this little script:
> > >phpinfo ();
> >
> >
> >$tux = tux_tpalloc (TUX_FML32, "", 5000);
> >print $tux;
> >
> >
> >tux_tpfree ($tux);
> >print $tux;
> >
> >?>
> >
> >
> >The tux_tpalloc and tux_free are new functions in my module.
> >If I comment out everything but the phpinfo () and hit
> >a fresh start of the web server, it will not core.  My module
> >is loaded because I see it in the phpinfo output.  After that
> >I can uncomment the rest of the script and it will NOT core.
> >
> >However if I just run this script right away from a fresh
> >restart, it will coredump.
> >
> >Very strange...
> >Brian
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] If Interested..

[Billy Rose]

Here's the URL's if anyone wants to have a look...

http://www.billyrose.org/verity.c
http://www.billyrose.org/php_verity.h
http://www.billyrose.org/REFERENCE

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] XML/EXPAT patches for empty elements

[Vadka]

Hi!
The problem is: expat parser produces no reports on the score of situation
when the document contains   etc. tags where there is
no data and end tag. So, the workaround was to add a new function to
expat, which is called by the PHP parser every time for empty entries when
the end tag
handler function launches (BEFORE THE END TAG HANDLER!!). This avoids
the situation of  in resulting HTML.

I've uploaded patches for current PHP(CVS) and expat(CVS) versions to
http://www.legko.ru/Soft target=Soft>http://www.legko.ru/Soft


Have a nice day!





-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #9964 Updated: Unresolved symbols

[dbeu]

ID: 9964
Updated by: dbeu
Reported By: [EMAIL PROTECTED]
Old-Status: Analyzed
Status: Closed
Bug Type: Compile Failure
PHP Version: 4.0 Latest CVS (24/03/2001)
Assigned To: 
Comments:

fixed in cvs

Previous Comments:
---

[2001-04-03 17:50:53] [EMAIL PROTECTED]
com linkage still seems to be broken (external modules like dotnet fail to link).
can someone familiar with them please have a look at it?

---

[2001-03-26 01:47:39] [EMAIL PROTECTED]
I was trying to build with php.dsw workspace.
phpts.dsw compiles right up.  Must have neglected to read the instructions.  Leaving 
this ticket open, because I think php4.dsw should be removed from the distribution, 
unless it serves some other purpose.

---

[2001-03-24 01:12:25] [EMAIL PROTECTED]
Trying to build php from recent cvs snaps php4-200103231245 and one from a day 
earlier.

Compile is smooth, except for a few unresolved symbols:

Linking...
   Creating library ..Debug/php4nts_debug.lib and object ..Debug/php4nts_debug.exp
internal_functions_win32.obj : error LNK2001: unresolved external symbol 
_VARIANT_module_entry
COM.obj : error LNK2001: unresolved external symbol _php_char_to_OLECHAR
COM.obj : error LNK2001: unresolved external symbol _php_OLECHAR_to_char
COM.obj : error LNK2001: unresolved external symbol _php_pval_to_variant
COM.obj : error LNK2001: unresolved external symbol _php_variant_to_pval
..Debugphp4nts_debug.dll : fatal error LNK1120: 5 unresolved externals
Error executing link.exe.

php4nts_debug.dll - 6 error(s), 0 warning(s)

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9964&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] I have libtool version 1.4 and buildconf script refuses to run

[Mark]

I have libtool version 1.4 and buildconf script refuses to run, it says:

lexington# ./buildconf
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: automake version 1.4 (ok)
buildconf: libtool version 1.4 found.
   You need libtool version 1.3.3 or newer installed
   to build PHP from CVS.
make: *** [buildmk.stamp] Error 1


This has got to be a bug, any suggestions on a work-around?

-Mark




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] RE: RE: Question

[Billy Rose]

It is a front end to the Verity K2 Search Engine toolkit so that PHP script can run 
Verity searches.

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Question

[Alexander Feldman]

What is doing your extension?

-- alex

On Mon, 30 Apr 2001, Billy Rose wrote:

> I have developed an extension, and am wondering to whom or where I submit it for 
>review?
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Question

[Billy Rose]

I have developed an extension, and am wondering to whom or where I submit it for 
review?

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10564: feof bug isn't fixed in windows versions.

[tarik_rahmanovic]

From: [EMAIL PROTECTED]
Operating system: win NT 4.0
PHP version:  4.0.4pl1
PHP Bug Type: *Function Specific
Bug description:  feof bug isn't fixed in windows versions.


while (!feof($sock)) {
echo fgets ($sock, 128);
}
fclose ($sock);


This hangs forever, even though remote end closes connection
within 120 miliseconds.  this is a known bug (discussed on the list), but the fix 
apperently didn't make it into the prepackaged windows release.  Please do let me know 
when this is fixed, for i need it more than i need cocaine (and i really really need 
cocaine) thank you.




-- 
Edit Bug report at: http://bugs.php.net/?id=10564&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10526 Updated: Possible problem with query

[cardinal]

ID: 10526
Updated by: cardinal
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: MySQL related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

User feedback:

Well, I'm not sure where the error message is comming from.  It is an error being 
generated by either PHP or MySQL.  I have figured out a way around the error, so it 
can be closed - but I never figured out what was causing the error.  It is definately 
something that should be looked into because someone else may have more problems in 
the future.  


Previous Comments:
---

[2001-04-29 22:23:04] [EMAIL PROTECTED]
I can't locate any error message in PHP that says "Query was empty".  Is it an error 
being displayed by your script, or one that your script calls upon?

This can probably be closed.

---

[2001-04-27 11:37:08] [EMAIL PROTECTED]
 Okay, I think I found a bug so please don't chew my 
head off if I'm wrong.
 I have written a short script to convert an excel 
spreadsheet into MySQL.  Text format of course.
 I try to create a table using these lines:

$query = "CREATE TABLE test3 (Sales_Number varchar(255), 
Sales_Name varchar(255), Location varchar(255), Amount 
varchar(255))";
$result = mysql_query ($query);

 It creates the table, but it stops the script with 
this error message:

Query was empty

 I have never seen this error message before, and I 
don't think the query is empty because it does create the 
table...

 If you want me to email you the script for further 
analysis, please let me know.

Matthew Grigajtis
  


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10526&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10563: missing #defines for ODBC

[jareds]

From: [EMAIL PROTECTED]
Operating system: Linux 2.4.2
PHP version:  4.0 Latest CVS (30/04/2001)
PHP Bug Type: Compile Problem
Bug description:  missing #defines for ODBC

php4/main/build-defs.h.in is missing 3 #define's for ODBC to compile correctly.  (From 
looking at the CVS mailing list, it looks like they were included in a mega-patch that 
was rejected.)

Here's a diff that fixes the problem.  The problem is that PHP_ODBC_INCLUDE, 
PHP_ODBC_LFLAGS, and PHP_ODBC_LIBS are undefined.

diff -r1.5 build-defs.h.in
51a52,54
> #define PHP_ODBC_INCLUDE  "@ODBC_INCLUDE@"
> #define PHP_ODBC_LFLAGS   "@ODBC_LFLAGS@"
> #define PHP_ODBC_LIBS "@ODBC_LIBS@"

My configure line is as follows:

./configure --with-apxs --with-custom-odbc=/usr/local/odbc --with-openssl --with-gd 
--disable-debug

Please feel free to contact me if you need any more information...


-- 
Edit Bug report at: http://bugs.php.net/?id=10563&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10562: undefined symbol alloca while building apache

[ian . palfrey]

From: [EMAIL PROTECTED]
Operating system: AIX 4.3.3
PHP version:  4.0.4pl1
PHP Bug Type: Compile Failure
Bug description:  undefined symbol alloca while building apache

I trying to build Apache 1.3.19 with PHP4 and Oracle 8.1.7.
I've now loaded the latest version of PHP4 from snaps.php.net as 4.0.4pl1 didn't 
detect Oracle 8 correctly and built this OK with:-

cd php4-200104270145
export ORACLE_HOME=/o8/product/8.1.7
./configure --without-mysql 
--with-oracle 
--with-apache=../apache_1.3.19 --enable-track-vars
make
make install

It thens fails when I try to link it into Apache with:-

cd ../apache_1.3.19
./configure --activate-module=src/php4/libphp4.a
make

make returns the following error about alloca

cc  -DAIX=43 -DUSE_PTHREAD_SERIALIZED_ACCEPT 
  -U__STR__ -DAIX_BIND_PROCESSOR 
  -qnogenpcomp -qnousepcomp -I/ora4/test/php4-200104270145 
  -I/ora4/test/php4-200104270145/main 
  -I/ora4/test/php4-200104270145/main 
  -I/ora4/test/php4-200104270145/Zend 
  -I/ora4/test/php4-200104270145/Zend 
  -I/ora4/test/php4-200104270145/TSRM
  -I/ora4/test/php4-200104270145/TSRM 
  -I/ora4/test/php4-200104270145 -DUSE_EXPAT 
  -I./lib/expat-lite 
  -DNO_DL_NEEDED 
  -ma `./apaci` -lm -lpthread
  -o httpd buildmark.o modules.o  modules/php4/libphp4.a  
modules/standard/libstandard.a  main/libmain.a  ./os/unix/libos.a  ap/libap.a  
lib/expat-lite/libexpat.a  
  -R/o8/product/8.1.7/lib  
  -L/o8/product/8.1.7/lib 
  -Lmodules/php4 -L../modules/php4 
  -L../../modules/php4 -lmodphp4   
  -ldl -lld -lbsd_r -lm -lodm -ldl -lcrypt -lbind -lm 
  -ldl -lclntsh  
ld: 0706-027 The -R /o8/product/8.1.7/lib flag is ignored.
ld: 0711-317 ERROR: Undefined symbol: .alloca
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
make: 1254-004 The error code from the last command is 8.


Stop.


I've read elsewhere on bug 9079 that alloca() is not part of 4.3.3 so I've even tried 
setting CFLAGS=-ma as suggested.  This also fails.  Any ideas?

Thanks IanP


-- 
Edit Bug report at: http://bugs.php.net/?id=10562&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10513 Updated: configure fails when I include Oracle 8.1.7

[cynic]

ID: 10513
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Compile Failure
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

user reports it's fixed in CVS

Previous Comments:
---

[2001-04-30 12:48:36] [EMAIL PROTECTED]
I've got round this problem by loading a new version from snaps.php.net called 
php4-200104270145.

Thanks.

---

[2001-04-26 12:38:37] [EMAIL PROTECTED]
configure fails when I include Oracle 8.1.7.
I set both vars below and exported them fist. 
  ORACLE_HOME=/o8/product/8.1.7
  LD_LIBRARY_PATH=/o8/product/8.1.7/lib

I've also tried this with PHP3 and fails during 'make' with a similar message about 
core4 and nlsrtl3.

The contents of debug.log is below.

CONFIGURE:   './configure' '--without-mysql' '--with-oracle' 
'--with-apache=../apache_1.3.19' '--enable-track-vars'
CC: cc
CFLAGS: -g
CPPFLAGS:   
CXX:
CXXFLAGS:   
INCLUDES:-I/ora4/test/apache_1.3.19/src/include 
  -I/ora4/test/apache_1.3.19/src/os/unix  
  -I$(top_builddir)/Zend 
  -I/o8/product/8.1.7/rdbms/public 
  -I/o8/product/8.1.7/rdbms/demo
LDFLAGS: -R/o8/product/8.1.7/lib -L/o8/product/8.1.7/lib
LIBS:   -lclntsh -lpsa -lcore4 -lnlsrtl3 -lld -lbsd_r 
  -lm -lodm -ldl -lbind -lm -ldl -lcrypt 
DLIBS:  
SAPI:   apache
PHP_RPATHS:  /o8/product/8.1.7/lib
uname -a:   AIX welwyn 3 4 00089E3DA100

cc -o conftest -g   -R/o8/product/8.1.7/lib 
   -L/o8/product/8.1.7/lib conftest.c -lclntsh -lpsa 
   -lcore4 -lnlsrtl3 -lld -lbsd_r -lm -lodm -ldl -lbind 
   -lm -ldl -lcrypt  1>&5
ld: 0706-027 The -R /o8/product/8.1.7/lib flag is ignored.
ld: 0706-006 Cannot find or open library file: -l core4
ld:open(): No such file or directory
ld: 0706-006 Cannot find or open library file: -l nlsrtl3
ld:open(): No such file or directory

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10513&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Alexander Bokovoy]

On Mon, Apr 30, 2001 at 10:47:21PM +0900, Rui Hirokawa wrote:
> 
> On Mon, 30 Apr 2001 15:37:14 +0300
> Andi Gutmans <[EMAIL PROTECTED]> wrote:
> 
> > At 09:35 PM 4/30/2001 +0900, Rui Hirokawa wrote:
> > 
> > >Andi,
> > >
> > >We have plan to add ext/jstring which is a japanese string extension module
> > >to php-4.0.6.
> > >Is there any problem to add this module on CVS tree now ?
> > 
> > No I don't see a problem with this but please do it quickly. 4.0.6 has 
> > already gone a long way since we started RC'ing 4.0.5 and I would like to 
> > start RC'ing it pretty soon. You should probably also copy 
> > dotnet/EXPERIMENTAL to your directory until it becomes completely stable.
> 
> I did.
> 
> > 
> > By the way, do you think jstring is the right name? Is it only for Japanese?
> 
> It includes some functions for japanese,but some functions are not 
> only for japanese.
> For example, this module supports encoding conversion functionality between
> Unicode and some other encodings like ISO-8859-X.
> Currently, it includes encoding conversion filter for japanese and ISO-8859-X,
> but it is relatively easy task to add another conversion filter for some other
> language.
> 
> I believe this module is small step for PHP internationalization.
> I think the name 'jstring' is right name now because it is existing
> for japanese string function now.
> But  'i18n' or 'wchar' or 'i18n-ja' are also the candidate for the name.
It would be very good to join this features with existing iconv extension
rather than generate new extensions.
-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Troubles with DL'ed module

[Andi Gutmans]

Sounds like some kind of memory corruption. With these kind of problems 
even the order of statements can make a difference. Do you want to post 
those two functions and we can take a look at them? Also are your RINIT() & 
MINIT() functions doing anything? Maybe they are causing problems?

Andi

At 11:17 AM 4/30/2001 -0500, Brian Foddy wrote:

>One more strange behavior I just saw.
>
>Take this little script:
>phpinfo ();
>
>
>$tux = tux_tpalloc (TUX_FML32, "", 5000);
>print $tux;
>
>
>tux_tpfree ($tux);
>print $tux;
>
>?>
>
>
>The tux_tpalloc and tux_free are new functions in my module.
>If I comment out everything but the phpinfo () and hit
>a fresh start of the web server, it will not core.  My module
>is loaded because I see it in the phpinfo output.  After that
>I can uncomment the rest of the script and it will NOT core.
>
>However if I just run this script right away from a fresh
>restart, it will coredump.
>
>Very strange...
>Brian
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10513 Updated: configure fails when I include Oracle 8.1.7

[ian_palfrey]

ID: 10513
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Compile Failure
Description: configure fails when I include Oracle 8.1.7

I've got round this problem by loading a new version from snaps.php.net called 
php4-200104270145.

Thanks.

Previous Comments:
---

[2001-04-26 12:38:37] [EMAIL PROTECTED]
configure fails when I include Oracle 8.1.7.
I set both vars below and exported them fist. 
  ORACLE_HOME=/o8/product/8.1.7
  LD_LIBRARY_PATH=/o8/product/8.1.7/lib

I've also tried this with PHP3 and fails during 'make' with a similar message about 
core4 and nlsrtl3.

The contents of debug.log is below.

CONFIGURE:   './configure' '--without-mysql' '--with-oracle' 
'--with-apache=../apache_1.3.19' '--enable-track-vars'
CC: cc
CFLAGS: -g
CPPFLAGS:   
CXX:
CXXFLAGS:   
INCLUDES:-I/ora4/test/apache_1.3.19/src/include 
  -I/ora4/test/apache_1.3.19/src/os/unix  
  -I$(top_builddir)/Zend 
  -I/o8/product/8.1.7/rdbms/public 
  -I/o8/product/8.1.7/rdbms/demo
LDFLAGS: -R/o8/product/8.1.7/lib -L/o8/product/8.1.7/lib
LIBS:   -lclntsh -lpsa -lcore4 -lnlsrtl3 -lld -lbsd_r 
  -lm -lodm -ldl -lbind -lm -ldl -lcrypt 
DLIBS:  
SAPI:   apache
PHP_RPATHS:  /o8/product/8.1.7/lib
uname -a:   AIX welwyn 3 4 00089E3DA100

cc -o conftest -g   -R/o8/product/8.1.7/lib 
   -L/o8/product/8.1.7/lib conftest.c -lclntsh -lpsa 
   -lcore4 -lnlsrtl3 -lld -lbsd_r -lm -lodm -ldl -lbind 
   -lm -ldl -lcrypt  1>&5
ld: 0706-027 The -R /o8/product/8.1.7/lib flag is ignored.
ld: 0706-006 Cannot find or open library file: -l core4
ld:open(): No such file or directory
ld: 0706-006 Cannot find or open library file: -l nlsrtl3
ld:open(): No such file or directory

---


Full Bug description available at: http://bugs.php.net/?id=10513


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Troubles with DL'ed module

[Sterling Hughes]

On Mon, 30 Apr 2001, Andi Gutmans wrote:

> Your module is probably causing some memory corruption. The best way to
> debug it is building the module statically into PHP. You need to copy it to
> ext/your_module/ (assuming you have a standard config.m4).
> Then in php4/ run ./buildconf and you should see your module when you do
> ./configure --help.
> ./configure and compile PHP with your module statically (best is even as a
> CGI) and then you can really debug it and see if it's a problem with the
> build as a shared library or if you have some bugs.
>

also, configuring with --enable-debug often helps...

-Sterling

> Andi
>
> At 11:01 AM 4/30/2001 -0500, Brian Foddy wrote:
> >Andi Gutmans wrote:
> > >
> > > Did you compile with debug on or off?
> > > Please try without debug in both PHP and your module and let us know if
> > > something changes.
> > > Also can you try and load it via php.ini (extension=module.so) and not with
> > > dl().
> > >
> >
> >
> >I rebuilt php 4.0.4p1 with debug off, rebuilt my module with debug off,
> >and switched from using DL to the extension load in the php.ini.
> >Unfortunately I still get the same coredump at the same line, just
> >a different constant.
> >
> >As before I can step though it with the debugger and the address
> >it cores in is viewable and has data.
> >
> >My gut is telling me its a build problem.  Some address not aligned
> >right or something.  For example shouldn't the -KPIC have been
> >used in the build argument list to libtool?
> >
> >But yet, in a seperate install without my new module the
> >same version of php on the same machine is running in production
> >very stable.
> >
> >Any ideas?
> >Brian
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Troubles with DL'ed module

[Andi Gutmans]

Your module is probably causing some memory corruption. The best way to 
debug it is building the module statically into PHP. You need to copy it to 
ext/your_module/ (assuming you have a standard config.m4).
Then in php4/ run ./buildconf and you should see your module when you do 
./configure --help.
./configure and compile PHP with your module statically (best is even as a 
CGI) and then you can really debug it and see if it's a problem with the 
build as a shared library or if you have some bugs.

Andi

At 11:01 AM 4/30/2001 -0500, Brian Foddy wrote:
>Andi Gutmans wrote:
> >
> > Did you compile with debug on or off?
> > Please try without debug in both PHP and your module and let us know if
> > something changes.
> > Also can you try and load it via php.ini (extension=module.so) and not with
> > dl().
> >
>
>
>I rebuilt php 4.0.4p1 with debug off, rebuilt my module with debug off,
>and switched from using DL to the extension load in the php.ini.
>Unfortunately I still get the same coredump at the same line, just
>a different constant.
>
>As before I can step though it with the debugger and the address
>it cores in is viewable and has data.
>
>My gut is telling me its a build problem.  Some address not aligned
>right or something.  For example shouldn't the -KPIC have been
>used in the build argument list to libtool?
>
>But yet, in a seperate install without my new module the
>same version of php on the same machine is running in production
>very stable.
>
>Any ideas?
>Brian
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Troubles with DL'ed module

[Brian Foddy]

One more strange behavior I just saw.

Take this little script:
 


The tux_tpalloc and tux_free are new functions in my module.
If I comment out everything but the phpinfo () and hit
a fresh start of the web server, it will not core.  My module
is loaded because I see it in the phpinfo output.  After that
I can uncomment the rest of the script and it will NOT core.

However if I just run this script right away from a fresh
restart, it will coredump.

Very strange...
Brian

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Troubles with DL'ed module

[Brian Foddy]

Andi Gutmans wrote:
> 
> Did you compile with debug on or off?
> Please try without debug in both PHP and your module and let us know if
> something changes.
> Also can you try and load it via php.ini (extension=module.so) and not with
> dl().
> 


I rebuilt php 4.0.4p1 with debug off, rebuilt my module with debug off,
and switched from using DL to the extension load in the php.ini.
Unfortunately I still get the same coredump at the same line, just
a different constant.

As before I can step though it with the debugger and the address
it cores in is viewable and has data.

My gut is telling me its a build problem.  Some address not aligned
right or something.  For example shouldn't the -KPIC have been
used in the build argument list to libtool?

But yet, in a seperate install without my new module the
same version of php on the same machine is running in production
very stable. 

Any ideas?
Brian

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Hartmut Holzgraefe]

Andi Gutmans wrote:
> Can we make a list of things which still need to make it into 4.0.6 
> before we branch?

i have started to create ext/saprfc that will interface with the ABAP/4
Remote Function Call mechanism in SAP R/3, 
but right now it only has a working configure script and no
functionality
within (making it even more useless than ext/rtfm for now)
so i'll wait until 4.0.6 branches off before i add it ...

-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] key_exists from php

[Jon Parise]

On Sun, Apr 29, 2001 at 09:50:13PM -0400, David Croft wrote:

> There doesn't seem to be any way for a php script to determine whether a
> given key exists in an array. isset($arr['x']) fails when it exists but
> has a null value. I know there are ways around it like using foreach or
> array_keys but these don't seem very efficient.
 
Wouldn't empty() handle that case?

e.g.if (!empty($arr['x'])) echo $arr['x'];

-- 
Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Hartmut Holzgraefe]

Cynic wrote:
> recode is GPL'd IIRC and thus (your mileage may vary) not very
> usable, doesn't build on win32 systems, and the author has
> no interest in changing that.

the recode command is under GPL while the library part is under LGPL
so it's ok as it is license-wise

(even RMS did not take the bait on it during the readline discussion)


-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Andi Gutmans]

At 12:23 AM 5/1/2001 +0900, Rui Hirokawa wrote:

>On Mon, 30 Apr 2001 17:26:58 +0300
>Andi Gutmans <[EMAIL PROTECTED]> wrote:
>
> > At 10:01 PM 4/29/2001 -0400, Sterling Hughes wrote:
> > >ext/wchar (wide character support?)
> > >ext/mstring (multibyte string functions)
> > >ext/jpstring (japanese string functions)
> >
> > I'd make mstring -> mbstring.
> > The question is if it's worth splitting this up into more than one
> > extension. Probably not.
> > So we should probably be picking out of wchar, mbstring, jpstring.
> > Rui, what do you think?
>
>I prefer unified approach is better for php-i18n than splitting
>some modules.
>I think mbstring is better, although this module also
>supports single-byte encoding like ISO-8859-X.
>Some people might say 'wchar' is better choise,
>because this module converts string to wide character internally.
>
>If someone want to add some other encoding support,
>he should add mbfilter_xx.c mbfilter_xx.h where xx means some
>specific language like ja (japanese).
>
>Anyway, because I am not original author of this module,
>I must discuss to Mr. Tsukada ,the original author of jstring
>about renaming the module.

OK. I think wchar or mbstring are both good. jstring will just confuse people.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Rui Hirokawa]

On Mon, 30 Apr 2001 17:26:58 +0300
Andi Gutmans <[EMAIL PROTECTED]> wrote:

> At 10:01 PM 4/29/2001 -0400, Sterling Hughes wrote:
> >ext/wchar (wide character support?)
> >ext/mstring (multibyte string functions)
> >ext/jpstring (japanese string functions)
> 
> I'd make mstring -> mbstring.
> The question is if it's worth splitting this up into more than one 
> extension. Probably not.
> So we should probably be picking out of wchar, mbstring, jpstring.
> Rui, what do you think?

I prefer unified approach is better for php-i18n than splitting 
some modules.
I think mbstring is better, although this module also 
supports single-byte encoding like ISO-8859-X.
Some people might say 'wchar' is better choise,
because this module converts string to wide character internally.

If someone want to add some other encoding support,
he should add mbfilter_xx.c mbfilter_xx.h where xx means some
specific language like ja (japanese).

Anyway, because I am not original author of this module,
I must discuss to Mr. Tsukada ,the original author of jstring
about renaming the module.

-- 
--
Rui Hirokawa <[EMAIL PROTECTED]>
maintainer of japanese PHP manual <[EMAIL PROTECTED]>

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] php.ini location

[Andi Gutmans]

Hi,

The default location of php.ini in the current CVS seems to be 
/usr/local/etc. Didn't we say we're saving this one for 4.1.x? I just got 
bitten by this and I bet there will be a huge amount of people who will too.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10561: sockets.c uses `SUN_LEN' unconditionally - undefined on Solaris

[Rob . McMahon]

From: [EMAIL PROTECTED]
Operating system: Solaris 7
PHP version:  4.0.4pl1
PHP Bug Type: Compile Failure
Bug description:  sockets.c uses `SUN_LEN' unconditionally - undefined on Solaris

Configured with

nv 'CC=cc -mt' CFLAGS=-O CPPFLAGS='-D_XPG4_2
-D__EXTENSIONS__' ./configure
--with-apxs=/usr/local/apache_1.3.19/bin/apxs
--with-mysql=/usr/local/mysql
--with-ldap=/usr/local/openldap --with-xml --enable-yp
--enable-safe-mode --with-gd --with-jpeg-dir=/usr/local
--with-pdflib --with-zlib --with-tiff-dir=/usr/local
--with-openssl=/usr/local/openssl --enable-bcmath --with-bz2
--enable-calendar --enable-dbase --with-gdbm=/usr/local/gnu
--with-ndbm --enable-ctype --with-db3=/usr/local/BerkeleyDB
--with-dom --enable-exif --with-fdftk --enable-filepro
--enable-ftp --enable-gd-imgstrttf --with-gd --with-gmp
--with-hyperwave --with-imap-ssl
--with-imap=/usr/local/src/pine4.30/imap
--with-java=/usr/java --with-mcal
--with-unixODBC=/usr/local/unixODBC
--with-readline=/usr/local/gnu --with-mm --enable-trans-sid
--enable-shmop --enable-sockets --with-regex=php
--enable-sysvsem --enable-sysvshm --enable-wddx --with-zlib
--enable-versioning --enable-track-vars --without-fdftk
--without-mcal --with-xpm-dir=/usr/local/X11

Can be fixed with (I suspect this is going to get mangled in
the post).

diff -c -r1.1 sockets.c
*** sockets.c   2001/04/19 10:04:11 1.1
--- sockets.c   2001/04/19 16:17:37
***
*** 66,71 
--- 66,77 
  #endif
  #endif

+ /* ... or this */
+ #ifndef   SUN_LEN
+ #define   SUN_LEN(sunp)   ((size_t)((struct
sockaddr_un *)0)->sun_path \
++ strlen((sunp)->sun_path))
+ #endif
+
  /* Use the read() wrapper, stopping at '\n', '\r', or '\0'. */
  #define PHP_NORMAL_READ 0x0001
  /* Use the read() wrapper, but read until the entire
buffer is filled. */



-- 
Edit Bug report at: http://bugs.php.net/?id=10561&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Colin Viebrock]

> I'd make mstring -> mbstring.
> The question is if it's worth splitting this up into more than one
> extension. Probably not.
> So we should probably be picking out of wchar, mbstring, jpstring.
> Rui, what do you think?

I'm not Rui, but my vote would be for "mbstring" (or "mb_string").  If this
handles any multi-byte character strings and Unicode, then it's going to be
used for a lot more than Japanese strings.

Hopefully, this will save me from porting String::Unicode into PHP. :)

- Colin


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Sterling Hughes]

On 30 Apr 2001, Stig Sæther Bakken wrote:

> [Cynic <[EMAIL PROTECTED]>]
> > recode is GPL'd IIRC and thus (your mileage may vary) not very
> > usable, doesn't build on win32 systems, and the author has
> > no interest in changing that.
>
> libiconv is pretty good too.  I don't know if it builds on Win32
> though.
>

It does.

-sterling


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] RE: Bug #10560 Updated: IISConfig Error

[David Jenkins]

Does this error only have to do with the setup of MMC or does it effect more
than that.  I'm new to PHP so I can't tell yet if there is a problem.

-Original Message-
From: Bug Database [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 30, 2001 8:48 AM
To: [EMAIL PROTECTED]
Subject: Bug #10560 Updated: IISConfig Error


ID: 10560
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Install and Config
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

this is being solved right now and will be probably fixed in 4.0.6

Previous Comments:
---

[2001-04-30 09:41:19] [EMAIL PROTECTED]
During the install of PHP I recieved an error stating that the MSCOMCTL.OCX
did not correctly register a file is missing or invalid.


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=10560&edit=2

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Stig Sæther Bakken]

[Cynic <[EMAIL PROTECTED]>]
> recode is GPL'd IIRC and thus (your mileage may vary) not very 
> usable, doesn't build on win32 systems, and the author has 
> no interest in changing that.

libiconv is pretty good too.  I don't know if it builds on Win32
though.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Andi Gutmans]

At 10:01 PM 4/29/2001 -0400, Sterling Hughes wrote:
>ext/wchar (wide character support?)
>ext/mstring (multibyte string functions)
>ext/jpstring (japanese string functions)

I'd make mstring -> mbstring.
The question is if it's worth splitting this up into more than one 
extension. Probably not.
So we should probably be picking out of wchar, mbstring, jpstring.
Rui, what do you think?
Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Logic in sapi/cgi/cgi_main.c

[Sterling Hughes]

On Mon, 30 Apr 2001, Andi Gutmans wrote:

> http://www.faqts.com/knowledge_base/view.phtml/aid/734/fid/37
> It sounds to me that you are right. That should probably just be request_uri.
> I thought many people have used this $PHP_SELF so it's kind of strange that
> there haven't been a zillion complaints.
> Does anyone object to changing this behavior?
>

You'd think one of the authors of the faqt would have filed a bug also...

Anyway, If no one objects by tonight, I'll go ahead make the change and
wait to be flamed ;)

-Sterling

> Andi
>
> At 01:56 PM 4/29/2001 -0400, Sterling Hughes wrote:
> > >Can you give an example of how it looks with request_uri and how it looks
> > >with both? Then it'll be easier for someone like me who doesn't know the
> > >standard too well to check the PHP manual and the HTTP standard to see
> > >what
> > >the correct behavior should be.
> > >
> >
> >Well, I can't really test this, as I don't have windows, but here's my
> >logic ;)
> >
> >To quote the bug report  ::
> >
> >in your website such that it is contained somewhere within the subtree of
> >a directory
> >whose name ends with ".php".  For example, on my box I had the file
> >located at
> >
> >http://site/php/secure.php/version.php
> >
> >If you then look at the value of $PHP_SELF it is
> >
> >/php/secure.php/php/secure.php/version.php
> >
> >and NOT
> >
> >/php/secure.php/version.php
> >
> >as it should be.
> >
> >
> >::
> >
> >This appears in what I assume is the CGI version (only place possible).  I
> >then took a look at the code shown below.  While most other sapi's
> >register only the request_uri (or something else, given by the server's
> >api itself), the code below provides an opportunity for the above
> >condition to occur, if SCRIPT_NAME is invalid, ie, it gets cut off too
> >soon, because of a odd directory name, then strcmp will not return the
> >correct results and request_uri will un-necessarily be appended
> >
> >If you look at the first one, its with SCRIPT_NAME and
> >REQUEST_URI (invalid), the second one is just the value of REQUEST_URI
> >(valid)...
> >
> >-Sterling
> >
> > >Andi
> > >
> > >>At 07:55 AM 4/29/2001 -0400, Sterling Hughes wrote:
> > >>
> > >>I've taken a look at the code that registers $PHP_SELF in the CGI
> > >>version,
> > >>in accordance with bug 6491.  I see the problem, its that on some server
> > >>&
> > >>OS combinations, the SCRIPT_NAME environment variable is incorrectly set
> > >>and therefore the below code exhibits the bug (the strcmp() should
> > >>avoid the request_uri being tagged on, but because the SCRIPT_NAME is
> > >>invalid, it doesn't happen the two don't match, and the REQUEST_URI is
> > >>incorrectly tagged on).
> > >>
> > >>It seems like the logical fix to this would to be just registering the
> > >>REQUEST_URI as the PHP_SELF, however, I don't know this code to well,
> > >>could one of the authors explain the reasoning behind prepending the
> > >>SCRIPT_NAME when FORCE_CGI_REDIRECT is not enabled?
> > >>
> > >>-Sterling
> > >>
> > >>
> > >>Related Code:
> > >>
> > >>#if FORCE_CGI_REDIRECT
> > >> php_register_variable("PHP_SELF", (SG(request_info).request_uri ?
> > >> SG(request_info).request_uri:""), track_vars_array ELS_CC PLS_CC);
> > >>#else
> > >> {
> > >> char *sn;
> > >> char *val;
> > >> int l=0;
> > >>
> > >> sn = getenv("SCRIPT_NAME");
> > >> pi = SG(request_info).request_uri;
> > >> if (sn)
> > >> l += strlen(sn);
> > >> if (pi)
> > >> l += strlen(pi);
> > >> if (pi && sn && !strcmp(pi, sn)) {
> > >> l -= strlen(pi);
> > >> pi = NULL;
> > >> }
> > >> val = emalloc(l + 1);
> > >> sprintf(val, "%s%s", (sn ? sn : ""), (pi ? pi : ""));   /* SAFE */
> > >> php_register_variable("PHP_SELF", val, track_vars_array ELS_CC
> > >>PLS_CC);
> > >> efree(val);
> > >> }
> > >>#endif
> > >>
> > >>
> > >>
> > >--
> > >>PHP Development Mailing List 
> > >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >>For additional commands, e-mail: [EMAIL PROTECTED]
> > >>To contact the list administrators, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >--
> > >PHP Development Mailing List 
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Stanislav Malyshev]

C>> recode is GPL'd IIRC and thus (your mileage may vary) not very
C>> usable, doesn't build on win32 systems, and the author has no

recode libs are LGPL, IIRC. As for win32, I don't know (not being user of
such systems) but I guess since its functionality do not include anything
that is unix-specific, it should build with little modification.
-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: Bug #10526 Updated: Possible problem with query

[Matthew Grigajtis]

Well, I 'm not sure where the error message is comming from.  
It is an error being generated by either PHP or MySQL.  I have 
figured out a way around the error, so it can be closed - but 
I never figured out what was causing the error.  It is 
definately something that should be looked into because 
someone else may have more problems in the future.

Matthew Grigajtis







-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Sterling Hughes]

On Mon, 30 Apr 2001, Rui Hirokawa wrote:

>
>
> On Mon, 30 Apr 2001 16:51:15 +0300 (IDT)
> Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
>
> > RH>> For example, this module supports encoding conversion
> > RH>> functionality between Unicode and some other encodings like
> > RH>> ISO-8859-X. Currently, it includes encoding conversion filter
> >
> > Doesn't this duplicate the GNU recode functionality?
>
>
> ext/jstring adds some unique functionalities as follows,
>
> - automatic encoding recognition functionality for japanese and Unicode   encodings.
> - the output encoding translation using output buffering functionality.
> - adding encoding translation for HTTP input (POST/GET/Cookie).
> - adding multibyte compatible string functions like mbstrlen (multibyte enabled 
>strlen())
>
> These functionalities are not fully supported by ext/recode or ext/iconv.
>

This seems like a very cool thing, however, I agree with Andi and others,
jstring sounds very Java like to me also.

perhaps:

ext/wchar (wide character support?)
ext/mstring (multibyte string functions)
ext/jpstring (japanese string functions)

-Sterling

>
> >
> >
> > --
> > Stanislav Malyshev, Zend Products Engineer
> > [EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115
> >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
>
>
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Rui Hirokawa]

On Mon, 30 Apr 2001 16:51:15 +0300 (IDT)
Stanislav Malyshev <[EMAIL PROTECTED]> wrote:

> RH>> For example, this module supports encoding conversion
> RH>> functionality between Unicode and some other encodings like
> RH>> ISO-8859-X. Currently, it includes encoding conversion filter
> 
> Doesn't this duplicate the GNU recode functionality?


ext/jstring adds some unique functionalities as follows,

- automatic encoding recognition functionality for japanese and Unicode   encodings.
- the output encoding translation using output buffering functionality.
- adding encoding translation for HTTP input (POST/GET/Cookie).
- adding multibyte compatible string functions like mbstrlen (multibyte enabled 
strlen())

These functionalities are not fully supported by ext/recode or ext/iconv.


> 
> 
> -- 
> Stanislav Malyshev, Zend Products Engineer
> [EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 


-- 
--
Rui Hirokawa <[EMAIL PROTECTED]>
maintainer of japanese PHP manual <[EMAIL PROTECTED]>

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Cynic]

recode is GPL'd IIRC and thus (your mileage may vary) not very 
usable, doesn't build on win32 systems, and the author has 
no interest in changing that.

At 15:51 30.4. 2001, Stanislav Malyshev wrote the following:
-- 
>RH>> For example, this module supports encoding conversion
>RH>> functionality between Unicode and some other encodings like
>RH>> ISO-8859-X. Currently, it includes encoding conversion filter
>
>Doesn't this duplicate the GNU recode functionality?
>
>
>-- 
>Stanislav Malyshev, Zend Products Engineer
>[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115
>
>
>
>-- 
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]
--end of quote-- 


[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Andi Gutmans]

At 10:47 PM 4/30/2001 +0900, Rui Hirokawa wrote:
> > No I don't see a problem with this but please do it quickly. 4.0.6 has
> > already gone a long way since we started RC'ing 4.0.5 and I would like to
> > start RC'ing it pretty soon. You should probably also copy
> > dotnet/EXPERIMENTAL to your directory until it becomes completely stable.
>
>I did.
>
> >
> > By the way, do you think jstring is the right name? Is it only for 
> Japanese?
>
>It includes some functions for japanese,but some functions are not
>only for japanese.
>For example, this module supports encoding conversion functionality between
>Unicode and some other encodings like ISO-8859-X.
>Currently, it includes encoding conversion filter for japanese and ISO-8859-X,
>but it is relatively easy task to add another conversion filter for some other
>language.
>
>I believe this module is small step for PHP internationalization.
>I think the name 'jstring' is right name now because it is existing
>for japanese string function now.
>But  'i18n' or 'wchar' or 'i18n-ja' are also the candidate for the name.

jstring sounds very Java'ish :)
I think a more descriptive name would be better especially if it is not 
Japanese specific.
Let's wait and see what other people think.
I'm very happy to see this code being merged into PHP 4. Many Japanese 
users have missed out on PHP 4 because these patches were mostly available 
for PHP 3.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #9297 Updated: sprintf ("%f", $foo) crashes with very large $foo.

[cmv]

ID: 9297
Updated by: cmv
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Strings related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

Works fine for me (RH7 and latest CVS):

[cmv@sunniva cmv]$ echo '' | php 
X-Powered-By: PHP/4.0.6-dev
Content-type: text/html

2286484951194899000n[cmv@sunniva
 cmv]

Previous Comments:
---

[2001-04-30 09:17:45] [EMAIL PROTECTED]
Can you please try the latest CVS or a snapshot from snaps.php.net and let us know if 
this still happens. I can't reproduce it on redhat 6.2.
Thanks.

---

[2001-02-16 10:34:20] [EMAIL PROTECTED]
[ben@home ben]$ echo '' | php 
X-Powered-By: PHP/4.0.4pl1
Content-type: text/html

2286484951194899000
Segmentation fault (core dumped)



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9297&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10560 Updated: IISConfig Error

[cynic]

ID: 10560
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Install and Config
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

this is being solved right now and will be probably fixed in 4.0.6

Previous Comments:
---

[2001-04-30 09:41:19] [EMAIL PROTECTED]
During the install of PHP I recieved an error stating that the MSCOMCTL.OCX did not 
correctly register a file is missing or invalid.


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10560&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Stanislav Malyshev]

RH>> For example, this module supports encoding conversion
RH>> functionality between Unicode and some other encodings like
RH>> ISO-8859-X. Currently, it includes encoding conversion filter

Doesn't this duplicate the GNU recode functionality?


-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.6

[Rui Hirokawa]

On Mon, 30 Apr 2001 15:37:14 +0300
Andi Gutmans <[EMAIL PROTECTED]> wrote:

> At 09:35 PM 4/30/2001 +0900, Rui Hirokawa wrote:
> 
> >Andi,
> >
> >We have plan to add ext/jstring which is a japanese string extension module
> >to php-4.0.6.
> >Is there any problem to add this module on CVS tree now ?
> 
> No I don't see a problem with this but please do it quickly. 4.0.6 has 
> already gone a long way since we started RC'ing 4.0.5 and I would like to 
> start RC'ing it pretty soon. You should probably also copy 
> dotnet/EXPERIMENTAL to your directory until it becomes completely stable.

I did.

> 
> By the way, do you think jstring is the right name? Is it only for Japanese?

It includes some functions for japanese,but some functions are not 
only for japanese.
For example, this module supports encoding conversion functionality between
Unicode and some other encodings like ISO-8859-X.
Currently, it includes encoding conversion filter for japanese and ISO-8859-X,
but it is relatively easy task to add another conversion filter for some other
language.

I believe this module is small step for PHP internationalization.
I think the name 'jstring' is right name now because it is existing
for japanese string function now.
But  'i18n' or 'wchar' or 'i18n-ja' are also the candidate for the name.

-- 
--
Rui Hirokawa <[EMAIL PROTECTED]>
maintainer of japanese PHP manual <[EMAIL PROTECTED]>

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10560: IISConfig Error

[davidj]

From: [EMAIL PROTECTED]
Operating system: NT 4.0
PHP version:  4.0.4pl1
PHP Bug Type: *Install and Config
Bug description:  IISConfig Error

During the install of PHP I recieved an error stating that the MSCOMCTL.OCX did not 
correctly register a file is missing or invalid.



-- 
Edit Bug report at: http://bugs.php.net/?id=10560&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10439 Updated: relative chdir from root doesn´t work

[andi]

ID: 10439
Updated by: andi
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: *Directory/Filesystem functions
PHP Version: 4.0.4
Assigned To: 
Comments:

Works fine in latest CVS under NT.
Please try 4.0.5 which should be released today and report back if your problem has 
been solved.

Previous Comments:
---

[2001-04-22 06:54:22] [EMAIL PROTECTED]
On w98 and w98se it is not possible to change from root directory (eg. c:) to a 
relative subdirectory (e.g. windows). There is a delay of about 1 second. The same 
when accessing file functions (eg. is_dir, filesize) on filenames in the root 
directory without path (e.g. filesize ("msdos.sys"), no result is returned.

Try this script:

".
str_replace ("\", "/", getcwd ()).""; 
  flush ();
}
mychdir ("change to root", "/", true);
mychdir ("change to existing full path", "c:/windows/temp", true);
mychdir ("change to parent", "..", true);
mychdir ("change to relative subdir", "temp", true);
mychdir ("change to parent-parent", "../..", true);
mychdir ("change to root", "/", true);
mychdir ("change to relative subdir from root - does not work (notice the delay)", 
"windows", false);
?>

Gustav Graf

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10439&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]