[PHP-DEV] PHP SDL module

[Emmanuel FAIVRE]

Hi All

I've just found a very intersting work on freshmeat :

http://sourceforge.net/projects/phpsdl/

Perhaps this man is here ?
Any comments ?


Manu



-- 
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] RC7 is out

[Anheyer, Tom]

Zeev Suraski wrote:

> 
> I rolled RC7 - if there are no surprises (there'd better not be! :), it
> can finally go out early next week.

please fix BUG 8994 / 10001 for the final 4.0.5. A fix for the 
set_socket_timeout problem is included in both reports.

thanks tom

-- 
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.5: Merge Request

[Jani Taskinen]

On Tue, 24 Apr 2001, Sterling Hughes wrote:

>I think its not a bad idea to encourage (even more :) bug fixing for the
>next release, but I don't think restricting valuable and/or needed
>features is a good idea.

You're just lazy. :)
There are these 'bugs' with type 'Feature/Change request'... so?

--Jani


-- 
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 #10505: include problem with ftp

[slaurijsse]

From: [EMAIL PROTECTED]
Operating system: HP-UX 11
PHP version:  4.0.4pl1
PHP Bug Type: *Web Server problem
Bug description:  include problem with ftp

PHP gives a problem with the ftp functionality.

We have compiled the php module with ftp functions  However as soon as we try to use 
one of the functions it says it has an error in include UNKNOWN on line 0 in the code.

In the code is NO "include" used.


-- 
Edit Bug report at: http://bugs.php.net/?id=10505&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] RE: 4.0.5: Merge Request

[Hellekin O. Wolf]

At 19:06 25/04/2001 +0100, James Moore wrote:
>Its doesnt at all :) We are using it as a temporary codename until we can
>think of a better one.
>
>- James

*** Brazil ? It starts with a B and it's all a Bug Story...


-- 
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-QA] Re: [PHP-DEV] RE: 4.0.5: Merge Request

[Cynic]

At 10:18 26.4. 2001, Hellekin O. Wolf wrote the following:
-- 
>At 19:06 25/04/2001 +0100, James Moore wrote:
>>Its doesnt at all :) We are using it as a temporary codename until we can
>>think of a better one.
>>
>>- James
>
>*** Brazil ? It starts with a B and it's all a Bug Story...

How about Big Drum? :)


[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]

[PHP-DEV] Bug #9839 Updated: opendir() before mysql_fetch_assoc() returns non-associative array

[cardinal]

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

mysql_fetch_assoc (And _fetch_row) now only takes one parameter in CVS.

Previous Comments:
---

[2001-04-07 00:52:49] [EMAIL PROTECTED]
This is a bug in MySQL extension.

The mysql_fetch_assoc() function is supposed to take
only one argument. And you found this bug by passing
the $dblink variable which holds (after running opendir)
number 2 as value. The actual bug is in php_mysql_fetch_hash() function (in 
php_mysql.c) as there
should be a check for the second possible argument, that it's one of MYSQL_ASSOC, 
MYSQL_NUM or MYSQL_BOTH.

--Jani


---

[2001-03-19 11:16:29] [EMAIL PROTECTED]
n");
}
 }   
 
?>

- End Script 

Data from phpinfo():

PHP was copmpiled with './configure' '--with-mysql' '--with-apache=../apache' 
'--enable-track-vars'

Virtual dir support is disabled


Apache Info: 

Apache Version Apache/1.3.19 
Apache Release 10319100 
Apache API Version 19990320 
Loaded Modules mod_php4, mod_setenvif, mod_auth, mod_access, mod_alias, mod_userdir, 
mod_actions, mod_imap, mod_asis, mod_cgi, mod_dir, mod_autoindex, mod_include, 
mod_status, mod_negotiation, mod_mime, mod_log_config, mod_env, http_core 


MySQL Info:

Active Persistent Links 0 
Active Links 0 
Client API version 3.23.22-beta 
MYSQL_INCLUDE   
MYSQL_LFLAGS   
MYSQL_LIBS   

mysql.allow_persistent  On On 
mysql.default_host  no value no value 
mysql.default_password  no value no value 
mysql.default_port  no value no value 
mysql.default_socket  no value no value 
mysql.default_user  no value no value 
mysql.max_links  Unlimited Unlimited 
mysql.max_persistent  Unlimited Unlimited 


If you need additional information, please feel free to contact me via email at 
[EMAIL PROTECTED] :)

Thanks



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9839&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 #10506: Using a variable as a mathematical operator

[jdj]

From: [EMAIL PROTECTED]
Operating system: Linux, but not important
PHP version:  4.0.4pl1
PHP Bug Type: Feature/Change Request
Bug description:  Using a variable as a mathematical operator



I am parsing the Date: header of an email address, which includes a GMT offset in the 
form [+|-]%4d.  Ideally, one of the following would work. ;)

$hour_mins = '0600';
$gmt_offset = '+0200';

$hour_mins = $hour_mins $gmt_offset[0] substr ($gmt_offset, 1);
That returns a parse error.. as does the short form of that (+=).

As it is now, I'm switch()'ing the $gmt_offset[0].
$hour_mins += substr ($gmt_offset, 1); works..
$hour_mins = $hour_mins + substr ($gmt_offset, 1); works..

Is this unsupported for any particular reason.. or am I just not syntactically correct?

Thanks!
Jeremy


-- 
Edit Bug report at: http://bugs.php.net/?id=10506&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 #10506 Updated: Using a variable as a mathematical operator

[cynic]

ID: 10506
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Feature/Change Request
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

just not correct.

Previous Comments:
---

[2001-04-26 05:06:01] [EMAIL PROTECTED]


I am parsing the Date: header of an email address, which includes a GMT offset in the 
form [+|-]%4d.  Ideally, one of the following would work. ;)

$hour_mins = '0600';
$gmt_offset = '+0200';

$hour_mins = $hour_mins $gmt_offset[0] substr ($gmt_offset, 1);
That returns a parse error.. as does the short form of that (+=).

As it is now, I'm switch()'ing the $gmt_offset[0].
$hour_mins += substr ($gmt_offset, 1); works..
$hour_mins = $hour_mins + substr ($gmt_offset, 1); works..

Is this unsupported for any particular reason.. or am I just not syntactically 
correct?

Thanks!
Jeremy

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10506&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 #10507: trouble with character set

[rom]

From: [EMAIL PROTECTED]
Operating system: Windows 2000 server
PHP version:  4.0.4pl1
PHP Bug Type: MySQL related
Bug description:  trouble with character set

When trying to use 
default-character-set directive with mysql,
php says: (when trying to connect to mysql server)

Warning: Can't initialize character set 14 (path: default) in k:\www\try.php on line 66

Lines from c:\my.cnf:
character-sets-dir=k:/usr/local/mysql/share/charsets/
default-character-set=cp1251

Mysql works ok, using the cp-1251 charset.
But php can't do it...
Tell me, where I must define the character-sets-dir path for PHP?

Waiting for Your answer, WBR, Rom McRitsky.


-- 
Edit Bug report at: http://bugs.php.net/?id=10507&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 #10508: Wrong result when comparing two specific strings via "==".

[swift]

From: [EMAIL PROTECTED]
Operating system: W2K
PHP version:  4.0.4pl1
PHP Bug Type: Scripting Engine problem
Bug description:  Wrong result when comparing two specific strings via "==".

Hi!

This seems to be a bug:



This will produce the output "Why?" on my system ... but: why?
"00" isn't equal "D0"!?

If I'm wrong, please tell me why ... thanks!!

 ... tobias wiersch



-- 
Edit Bug report at: http://bugs.php.net/?id=10508&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 #10508 Updated: Wrong result when comparing two specific strings via "==".

[cynic]

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

this (mis- but shh, don't tell anyone :)feature has already caused much confusion. the 
reason: "d0" is automagically converted to 0, just like the other string.

you're welcome.

Previous Comments:
---

[2001-04-26 05:41:21] [EMAIL PROTECTED]
Hi!

This seems to be a bug:



This will produce the output "Why?" on my system ... but: why?
"00" isn't equal "D0"!?

If I'm wrong, please tell me why ... thanks!!

 ... tobias wiersch


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10508&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 #10508 Updated: Wrong result when comparing two specific strings via "==".

[hholzgra]

ID: 10508
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Scripting Engine problem
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

use === to compare strings without auto-conversion

Previous Comments:
---

[2001-04-26 05:49:31] [EMAIL PROTECTED]
this (mis- but shh, don't tell anyone :)feature has already caused much confusion. the 
reason: "d0" is automagically converted to 0, just like the other string.

you're welcome.

---

[2001-04-26 05:41:21] [EMAIL PROTECTED]
Hi!

This seems to be a bug:



This will produce the output "Why?" on my system ... but: why?
"00" isn't equal "D0"!?

If I'm wrong, please tell me why ... thanks!!

 ... tobias wiersch


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10508&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 #9872 Updated: Couldn't access all file via gz* functions

[vaab]

ID: 9872
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Zlib Related
Description: Couldn't access all file via gz* functions

I have php 4.0.4pl1 under Apache. My zlib is version 1.1.2.

I've had problems accessing gz compressed file : 
This happens in the middle of a file : 'gzeof' don't catch
any EOF, but 'gzgetc' returns false as it was the end of the
file. Same for 'gzread' which acts exactly as if it had
encountered an EOF.
I open the compressed file for writing, and write with the
lines (and only these one): 

$zp = gzopen($this->file, "ab9");
gzwrite($zp,  strlen($string) . chr(0)
. $string . chr(0)
. "0" . chr(0)
   , strlen($string) + strlen(strlen($string)) + 4);

I open the compressed file for reading, and read with the
lines (and only these ones): 

$zp = gzopen($this->file, "rb");
$char = gzgetc($zp);
$string = gzread($zp, $SizeOfString);

This simple script can't read all the file : 

// Note : The file is 68 bytes long uncompressed, and 128
compressed (this info has been read with ls -al)

 $fd = gzopen($file,"rb");
 echo bin2hex(gzread ($fd, 1000));
 gzclose($fd);



This happens on ext2 file system, and vfat. But doesn't
happen under a foreign server (which I don't know the exact
configuration, but has only php 3.16 probably running under
apache on a linux 2.2.14 (for more info on this server go :
http://neosyris.free.fr/testphp.php3)). Their zlib is
version 1.1.3.

I've gunzipped the file I couldn't read in PHP, and read it
without any problems with gz* function by taking of the "9"
in the gzopen function. Although it seems it make the same
problems with other compression values.

I've opened the gunzziped file, and this one contains only
normal caracters except the '00' char. (checked this with
'hexdump showbug -c').

my configure line : 

--prefix=/usr/apps/apache --with-zlib --with-mysql
--with-apxs=/usr/apps/apache/bin/apxs
--with-config-file-paht=/usr/apps/apache/conf

I hope this could help. Last thing : I placed a file that
causes problems on http://neosyris.free.fr/showbug.gz

All these bugs could come from zlib version 1.1.2, downloading version 1.1.3 could 
resolve the issues. Finding
zlib source isn't always easy, so there is some addresses :
www.freshmeat.net
ftpsearch.ntnu.org

** An add from Craig about zlib 1.1.3 on WinME ***

I can confirm this bug. I have php4.04pl1 on two seperate linux installs as well as a 
windows ME installation.
(All are with Apache 1.3.14).
 
Using the same scripts and data the gzread and gzfile WILL WORK correctly on the linux 
installs but NOT on the windows install.
ie. Only a portion of the gzfile is read into the script.
a phpinfo() on all three installs reports a zlib version 1.1.3
 
It may be that the 1.1.3 zlib was fixed for the linux install, but not the windows 
??

**

Previous Comments:
---

[2001-03-20 10:22:45] [EMAIL PROTECTED]

I have php 4.0.4pl1 under Apache. My zlib is version 1.1.2.

I've had problems accessing gz compressed file : 
This happens in the middle of a file : 'gzeof' don't catch
any EOF, but 'gzgetc' returns false as it was the end of the
file. Same for 'gzread' which acts exactly as if it had
encountered an EOF.
I open the compressed file for writing, and write with the
lines (and only these one): 

$zp = gzopen($this->file, "ab9");
gzwrite($zp,  strlen($string) . chr(0)
. $string . chr(0)
. "0" . chr(0)
   , strlen($string) + strlen(strlen($string)) + 4);

I open the compressed file for reading, and read with the
lines (and only these ones): 

$zp = gzopen($this->file, "rb");
$char = gzgetc($zp);
$string = gzread($zp, $SizeOfString);

This simple script can't read all the file : 

// Note : The file is 68 bytes long uncompressed, and 128
compressed (this info has been read with ls -al)

 $fd = gzopen($file,"rb");
 echo bin2hex(gzread ($fd, 1000));
 gzclose($fd);



This happens on ext2 file system, and vfat. But doesn't
happen under a foreign server (which I don't know the exact
configuration, but has only php 3.16 probably running under
apache on a linux 2.2.14 (for more info on this server go :
http://neosyris.free.fr/testphp.php3)). Their zlib is
version 1.1.3.

I've gunzipped the file I couldn't read in PHP, and read it
without any problems with gz* function by taking of the "9"
in the gzopen function. Although it seems it make the same
problems with other compression values.

I've opened the gunzziped file, and this one contains only
normal caracters except the '00' char. (checked this with
'hexdump showbug -c').

my configure line : 

--prefix=/usr/apps/apache --with-zlib --with-mysql
--with-apxs=/usr/apps/apache/bin/apxs
--with-config-file-paht=/usr/apps/apache/conf

I hope t

[PHP-DEV] Bug #10509: Zend Optimizer includes "shell line" in output

[mdobel]

From: [EMAIL PROTECTED]
Operating system: Linux 2.2.19
PHP version:  4.0.4pl1
PHP Bug Type: Scripting Engine problem
Bug description:  Zend Optimizer includes "shell line" in output

Assume the following "Shell Script":

#!/usr/local/bin/php -q


With the Zend Optimizer switched on the script's output is:

[markus@testmoehre]$ ./test.php
#!/usr/local/bin/php -q
blafasel.
[markus@testmoehre]$

Notice the first line, which shouldn't be there.
After removing (or commenting) the lines

  zend_optimizer.optimization_level=15
  zend_extension="/usr/local/lib/zend/ZendOptimizer.so"

in php.ini, the output is as expected (i.e. without the first line).


-- 
Edit Bug report at: http://bugs.php.net/?id=10509&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 #10509 Updated: Zend Optimizer includes "shell line" in output

[hholzgra]

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

you should ask Zend support
on problems with Zend products

Previous Comments:
---

[2001-04-26 08:13:36] [EMAIL PROTECTED]
Assume the following "Shell Script":

#!/usr/local/bin/php -q


With the Zend Optimizer switched on the script's output is:

[markus@testmoehre]$ ./test.php
#!/usr/local/bin/php -q
blafasel.
[markus@testmoehre]$

Notice the first line, which shouldn't be there.
After removing (or commenting) the lines

  zend_optimizer.optimization_level=15
  zend_extension="/usr/local/lib/zend/ZendOptimizer.so"

in php.ini, the output is as expected (i.e. without the first line).

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10509&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 #10505 Updated: include problem with ftp

[slaurijsse]

ID: 10505
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: *Web Server problem
Description: include problem with ftp

Writing a file through ftp with fopen("ftp://...";) does work.


Previous Comments:
---

[2001-04-26 04:16:42] [EMAIL PROTECTED]
PHP gives a problem with the ftp functionality.

We have compiled the php module with ftp functions  However as soon as we try to use 
one of the functions it says it has an error in include UNKNOWN on line 0 in the code.

In the code is NO "include" used.

---


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


-- 
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 #10510: ini_set() as relates to max upload filesize setting

[webmaster]

From: [EMAIL PROTECTED]
Operating system: Unix/BSD
PHP version:  4.0.4pl1
PHP Bug Type: *Function Specific
Bug description:  ini_set() as relates to max upload filesize setting

First, let me say that I'm not entirely sure I would class this report as a bug, but 
it very well could be.

Recently, as in yesterday, I spent a number of hours trying to find a work-around to 
the maximum upload filesize setting.  I came across the ini_set() functions.

This appeared to be something of a solution to the delimma, by issuing a ini_set() to 
the max upload filesize, I figured I would be able to conduct a file upload that 
exceeded the default 2M limit.

It would appear that I was wrong.

Here is the situation which presented itself, and ultimately will explain why I'm 
emailing as a bug report.

 The Scenario -
My script resides on a "hosted" server, one which is beyond my direct control.  
Naturally the host controls the settings, and the like.

I needed to conduct file uploads, which may or may not exceed the default limit.  
After reviewing the manual, I found the ini_set functions. So, I decided to test the 
over-ride of the ini's setting for a max upload filesize.

For test purposes, we chose 4M, and issued an ini_set() to PHP. The set was 
successful, and our local value for the max upload filesize was 4M.

No problem, this is awesome I thought to myself, so we moved forward and attempted to 
upload, using a "file" field named file_url.

The end result was just un-real.

We selected a file that weighed in at approx. 2.2MB just .2 over the default limit, 
but well within our defined max size.

We watched our modems and bandwidth meters, seeing the transmit of the file to the 
server... (we think all is going sweetly).. then, nothing.

PHP gave no errors, as a matter of fact the script executed perfectly.  cept that the 
value of file_url became "none".. obviously something went wrong.. 

Here's what we ultimately discovered.

1) "IF" the file exceeded 2M (the default) the value of the file field is stripped and 
returns as "none" (as if no file was uploaded).

2) PHP Gives no "limit exceeded" error, or any errors for that matter.

3) "IF" the file is below the 2M limit, all is perfect.

In short, it would appear that the ini_set(), though it displays as being set, has no 
real affect.  Bug? I don't know.. I do however feel, that at the very least, PHP 
should give us some type of error message.. In the end, I'm left with the feeling that 
one of two possiblities exist here, 1) the ini_set() function holds no real coding 
value, or 2) I don't fully understand the function.  Granted, documentation is 
somewhat limited on these..


-- 
Edit Bug report at: http://bugs.php.net/?id=10510&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 #10490 Updated: xslt_process() generates fatal error

[sterling]

ID: 10490
Updated by: sterling
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Sablotron XSL
PHP Version: 4.0 Latest CVS (25/04/2001)
Assigned To: 
Comments:

If you really want to catch the error you can use the
xslt_set_error_handler() function.  Not a bug (already had
this conversation with a user, check the closed bug reports
to view it).

Previous Comments:
---

[2001-04-25 10:32:18] [EMAIL PROTECTED]
Well, not actually the latest CVS, but RC6-2 from Debian Unstable, which should be 
close enough...

At http://www.php.net/manual/en/function.xslt-process.php there is an example program. 
When I use it as is, it works all right and produces a nice table. Here is a short 
section of the code:
-
[...]
if (xslt_process($xslData, $xmlData, $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;
}
?>
-

This is quite similar to what I am trying. If you now corrupts the xmlData variable, 
e.g. by changing  to  without changing the closing tag, you will get 
an error message saying


Fatal error:  XML parser error 7: mismatched tag in
/var/www/test.php on line 40

As you can see here, xslt_process() dies with a fatal error and the program is 
terminated, and we never get to testing the return value. The next problem, is that 
since the error is "fatal", it is also not possible to use set_error_handler() to 
catch the error. 

Of course it can be discussed wether this is a bug or not, but when a function is 
documented to return false on error, I would not expect it to lay down and die. And 
since it should not corrupt the PHP internals in any way, I would at least expect to 
be able to handle it with set_error_handler().


Svein Roar Nilsen
Norwegian Hydrographic Services


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10490&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 #8994 Updated: socket_set_timeout works only once

[sterling]

ID: 8994
Updated by: sterling
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Network related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

Applied in CVS, don't know if it will make 4.0.5 this late
in the game.  Thanks!

Previous Comments:
---

[2001-04-26 09:49:54] [EMAIL PROTECTED]
Applied in CVS, don't know if it will make 4.0.5 this late
in the game.  Thanks!

---

[2001-03-22 04:11:22] [EMAIL PROTECTED]
please fix this issue for the final 4.0.5. It is not fixed 
in 4.0.5RC1. I think it's easy to fix.


---

[2001-03-22 04:11:20] [EMAIL PROTECTED]
please fix this issue for the final 4.0.5. It is not fixed 
in 4.0.5RC1. I think it's easy to fix.


---

[2001-01-30 05:36:45] [EMAIL PROTECTED]
socket_set_timeout() works only once. 
This is because the internal function php_sock_fgets() checks the timout flag before 
calling php_sockread_internal(). If blocking IO  php_sockwait_for_data() is called 
next. This function resets the socket timeout flag.

A possible solution is to reset the flag in php_sockset_timeout() like the following 
patch. Removing the timeout flag test from php_sock_fgets() is also possible maybe.

diff -c /usr/src/packages/BUILD/php-4.0.4pl1/ext/standard/fsock.c-orig 
/usr/src/packages/BUILD/php-4.0.4pl1/ext/standard/fsock.c
*** /usr/src/packages/BUILD/php-4.0.4pl1/ext/standard/fsock.c-orig  Tue Jan 30 
11:19:59 2001
--- /usr/src/packages/BUILD/php-4.0.4pl1/ext/standard/fsock.c   Tue Jan 30 11:19:59 
2001
***
*** 596,601 
--- 596,602 
SOCK_FIND(sock, socket);
  
sock->timeout = *timeout;
+   sock->timeout_event = 0;
  }
  
  #define SOCK_FIND_AND_READ_MAX(max) 


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8994&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.5: Merge Request

[Jani Taskinen]

On Wed, 25 Apr 2001, Sterling Hughes wrote:

>On Thu, 26 Apr 2001, Jani Taskinen wrote:
>
>> On Tue, 24 Apr 2001, Sterling Hughes wrote:
>>
>> >I think its not a bad idea to encourage (even more :) bug fixing for the
>> >next release, but I don't think restricting valuable and/or needed
>> >features is a good idea.
>>
>> You're just lazy. :)
>
>I really don't see that in my statement.  I'm saying is that going
>gung-ho at fixing bugs is great, but I don't see any reason to reject
>work because it is a feature rather than a bug fix.

Okay, wrong choice of word. I meant to say: You're just impatient.
Why couldn't you wait with those features until the bug fixing period
would be over? And adding new features is usually also adding of new
bugs..

>> There are these 'bugs' with type 'Feature/Change request'... so?
>There not really "bugs" in the terms that I think everyone else is
>referring to a bug as.  Its just convient to place these in the bugs db.

Hrhm..forget about it.

Anyway, we can forget this as most of the developers seem to object the
idea of 'bug fixing freeze'. (most of them have kept their mouths shut)

--Jani



-- 
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 #10510 Updated: ini_set() as relates to max upload filesize setting

[Hartmut Holzgraefe]

[EMAIL PROTECTED] wrote:
> Please take into account that the processing of post data happens 
> _before_ your call to ini_set. Thus your new limit value has no effect 
> to the upload and succeeds (of course) after the upload is rejected.

maybe we should think about a way to mark all ini settings like these
and generate warnings when ini_set is used at runtime to change them

-- 
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] Bug #10510 Updated: ini_set() as relates to max upload filesize setting

[spencer 'sporty' portee]

As of late, the company I work for, Community Connect, needs to extend the
openssl php module and might be able to release the source.  It is for RSA
encryption, but in my own interest, i would like to add on the other types
of algorithms to it too. 

I understand that there are more complex functions, such as encryption using
PKCS8 (or was that 7) to encrypt with a public key, while using envelopes and
SMIME.  I would like to see simpler functions, such as straight RSA and DSA
encryption/decryption, as well as cert creation as it exists in the openssl
api.  At the moment, RSA is the primary target for my needs.

I would like to start ASAP, so please let me know of anything i should know or
do before hand :)

-spencer p


-- 
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.5: Merge Request

[Zeev Suraski]

At 17:56 26/4/2001, Jani Taskinen wrote:
>Anyway, we can forget this as most of the developers seem to object the
>idea of 'bug fixing freeze'. (most of them have kept their mouths shut)

I'm still in favour of doing this for 4.0.6.

Zeev


-- 
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.5: Merge Request

[derick]

On Thu, 26 Apr 2001, Zeev Suraski wrote:

> At 17:56 26/4/2001, Jani Taskinen wrote:
> >Anyway, we can forget this as most of the developers seem to object the
> >idea of 'bug fixing freeze'. (most of them have kept their mouths shut)
>
> I'm still in favour of doing this for 4.0.6.

I think it's wise to do too. Every x minor releases we should this I
think. Where x is a number between 3 and 5. This doesn't harm anything,
and my guess is that it certainly makes PHP more stable (then it already
is).

regards,

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-


-- 
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.5: Merge Request

[Sterling Hughes]

On Thu, 26 Apr 2001, Jani Taskinen wrote:

> On Wed, 25 Apr 2001, Sterling Hughes wrote:
>
> >On Thu, 26 Apr 2001, Jani Taskinen wrote:
> >
> >> On Tue, 24 Apr 2001, Sterling Hughes wrote:
> >>
> >> >I think its not a bad idea to encourage (even more :) bug fixing for the
> >> >next release, but I don't think restricting valuable and/or needed
> >> >features is a good idea.
> >>
> >> You're just lazy. :)
> >
> >I really don't see that in my statement.  I'm saying is that going
> >gung-ho at fixing bugs is great, but I don't see any reason to reject
> >work because it is a feature rather than a bug fix.
>
> Okay, wrong choice of word. I meant to say: You're just impatient.
> Why couldn't you wait with those features until the bug fixing period
> would be over? And adding new features is usually also adding of new
> bugs..
>

I could, and it wouldn't be the end of the world...  I just don't see the
point in restricting good work, by setting up  a bug fixing freeze.  If
we were to have such a thing, I personally would spend the time fixing
bugs, however, if another developer has a really cool feature he wants to
add, I see no reason why it shouldn't go in.

> >> There are these 'bugs' with type 'Feature/Change request'... so?
> >There not really "bugs" in the terms that I think everyone else is
> >referring to a bug as.  Its just convient to place these in the bugs db.
>
> Hrhm..forget about it.
>
> Anyway, we can forget this as most of the developers seem to object the
> idea of 'bug fixing freeze'. (most of them have kept their mouths shut)
>

I actually think the general idea is good, have a release where all the
regular contributors agree to work on fixing bugs.  Or like the debian
folk do, have a bug squashing party.  I'm just saying that a feature
freeze seems un-necessary, I see no reason why we can't have our cake
and eat it too...

-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]

Re: [PHP-DEV] 4.0.5: Merge Request

[Andrei Zmievski]

On Wed, 25 Apr 2001, Sterling Hughes wrote:
> I actually think the general idea is good, have a release where all the
> regular contributors agree to work on fixing bugs.  Or like the debian
> folk do, have a bug squashing party.  I'm just saying that a feature
> freeze seems un-necessary, I see no reason why we can't have our cake
> and eat it too...

Because new features introduce new bugs.

-Andrei

Any sufficiently advanced bug is
indistinguishable from a feature.
-- Rich Kulawiec

-- 
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.5: Merge Request

[Sterling Hughes]

On Thu, 26 Apr 2001, Andrei Zmievski wrote:

> On Wed, 25 Apr 2001, Sterling Hughes wrote:
> > I actually think the general idea is good, have a release where all the
> > regular contributors agree to work on fixing bugs.  Or like the debian
> > folk do, have a bug squashing party.  I'm just saying that a feature
> > freeze seems un-necessary, I see no reason why we can't have our cake
> > and eat it too...
>
> Because new features introduce new bugs.
>

Naturally, but what does waiting 7 (an arbitrary number) of days do to
make the new feature have less bugs.  The way I see it, the sooner the
feature is in there, the sooner the bug gets identified the sooner we're
able to fix it, the better.  Meanwhile, we can all still be working on
fixing older bugs.

-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]

Re: [PHP-DEV] 4.0.5: Merge Request

[Andrei Zmievski]

On Wed, 25 Apr 2001, Sterling Hughes wrote:
> Naturally, but what does waiting 7 (an arbitrary number) of days do to
> make the new feature have less bugs.  The way I see it, the sooner the
> feature is in there, the sooner the bug gets identified the sooner we're
> able to fix it, the better.  Meanwhile, we can all still be working on
> fixing older bugs.

Look it's simple. We have x developers and QA people able to fix bugs.
For a certain RC we have y bugs. If you add a new feature, you will
probably introduce z bugs. Now, x/y is the amount of effort per bug
without the new feature, and it is certainly more than x/(y+z) - with
the new feature. Simple math.

-Andrei

The main reason Santa is so jolly is because he knows where
all the bad girls live.  -- George Carlin

-- 
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] openssl module for php

[spencer 'sporty' portee]

As of late, the company I work for, Community Connect, needs to extend the
openssl php module and might be able to release the source.  It is for RSA
encryption, but in my own interest, i would like to add on the other types
of algorithms to it too. 

I understand that there are more complex functions, such as encryption using
PKCS8 (or was that 7) to encrypt with a public key, while using envelopes and
SMIME.  I would like to see simpler functions, such as straight RSA and DSA
encryption/decryption, as well as cert creation as it exists in the openssl
api.  At the moment, RSA is the primary target for my needs.

I would like to start ASAP, so please let me know of anything i should know or
do before hand :)

-spencer p

p.s.  Sorry for the repeat, i apparently need to learn how to use my email client 
properly.

-- 
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 #10464 Updated: PHP_AUTH_PW is not set altough PHP_AUTH_USER is

[tisc]

ID: 10464
User Update by: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Apache related
Description: PHP_AUTH_PW is not set altough PHP_AUTH_USER is

I figured out that our webmaster took special care
for passwords - we have AFS here and AFS passwords are
often used to authenticate Web stuff.

Therefore he somehow deletes PHO_AUTH_PW before my script
gets executed.

Sorry for the wrong bug - the real bug is that I need to
be able to tell PHP not to reveal passwords already used
by Apache for some kind of authentication.

(This is bug #8827).

Previous Comments:
---

[2001-04-24 03:55:10] [EMAIL PROTECTED]
Update: register_globals is turned on.
(see
http://www-usercgi.tu-chemnitz.de/~tisc/authtest.php3
for output of phpinfo() after authentication.)



---

[2001-04-24 03:49:16] [EMAIL PROTECTED]
The, why is PHP_AUTH_USER set at all?

---

[2001-04-23 17:00:27] [EMAIL PROTECTED]
Sound like you don't have register_globals turned on in your php.ini.

- Colin

---

[2001-04-23 15:26:09] [EMAIL PROTECTED]
I tried to authenticate via PHP. It worked with PHP3.
After tracing back and forth, I found that the global
variable PHP_AUTH_PW is not set or empty.
HTTP_SERVER_VARS["HTTP_AUTH_PW"] still contains the
right value.

I do not write to that variable (I checked with grep...)

See http://www-usercgi.tu-chemnitz.de/~tisc/authtest.php3 
for a demonstration.

HTH! Tino.

---


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


-- 
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.5: Merge Request

[Sterling Hughes]

On Thu, 26 Apr 2001, Andrei Zmievski wrote:

> On Wed, 25 Apr 2001, Sterling Hughes wrote:
> > Naturally, but what does waiting 7 (an arbitrary number) of days do to
> > make the new feature have less bugs.  The way I see it, the sooner the
> > feature is in there, the sooner the bug gets identified the sooner we're
> > able to fix it, the better.  Meanwhile, we can all still be working on
> > fixing older bugs.
>
> Look it's simple. We have x developers and QA people able to fix bugs.
> For a certain RC we have y bugs. If you add a new feature, you will
> probably introduce z bugs. Now, x/y is the amount of effort per bug
> without the new feature, and it is certainly more than x/(y+z) - with
> the new feature. Simple math.
>

I'll agree that the inverse of the above is true ;)))

But if you look at it over time, it averages out, making the net
effect equal 0.

anyway, I think we agree on the math, we just disagree on whether the
short term affect is worth it.

regardless of the outcome, I'm fine though, I think that soon enough
the releases (because of there nature) will become a feature freeze (as
more features get added, there are less features that need to be added,
plus the core is getting smaller soon, so the net effect will be more bug
fix releases and less feature releases)...

-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] Bug #10512: can't build informix support library

[dino]

From: [EMAIL PROTECTED]
Operating system: unixware 711
PHP version:  4.0.4pl1
PHP Bug Type: Compile Problem
Bug description:  can't build informix support library

during make php4 in sco unixware 711, I configure it
with informix, and with apxs. But the program failed out
in the step to build informix library. error message is:
--
Making all in Zend
Making all in main
Making all in ext
Making all in informix
/bin/sh /pub/php-4.0.4pl1/libtool --silent --mode=link gcc  -I. -I/pub/php
-4.0.4pl1/ext/informix -I/pub/php-4.0.4pl1/main -I/pub/php-4.0.4pl1 -I/usr/local/a
pache/include -I/pub/php-4.0.4pl1/Zend -I/usr/informix/incl/esql -I/pub/php-4.0.4p
l1/ext/xml/expat/xmltok -I/pub/php-4.0.4pl1/ext/xml/expat/xmlparse -I/pub/php-4.0.
4pl1/TSRM  -DUW=700 -DUSE_HSREGEX -DUSE_EXPAT -DXML_BYTE_ORDER=21 -g -O2 -I/usr/in
formix/incl/esql   -o libinformix.la  ifx.lo  /usr/ccs/lib/libgen.a
libtool: link: cannot build libtool library `libinformix.la' from non-libtool obje
cts: /usr/ccs/lib/libgen.a
*** Error code 1 (bu21)
UX:make: ERROR: fatal error.
*** Error code 1 (bu21)
UX:make: ERROR: fatal error.
*** Error code 1 (bu21)
UX:make: ERROR: fatal error.
*** Error code 1 (bu21)
UX:make: ERROR: fatal error.

I can pass this error by remove IFX_LIBS = /usr/ccs/bin/libgen.a line in 
config_vars.mk,
and continue to build PHP4 without any other error.
But Apache can't work after "make install" to copy
php4 module into apache directory. It said :
--
Syntax error on line 207 of /usr/local/apache/conf/httpd.conf:
Cannot load /usr/local/apache/libexec/libphp4.so into server: dynamic linker: /usr
/local/apache/bin/httpd: relocation error: symbol not found: getmntent; referenced
 from: /usr/informix/lib/esql/libifos.so
/usr/local/apache/bin/apachectl start: httpd could not be started
-

advice?
thz.


-- 
Edit Bug report at: http://bugs.php.net/?id=10512&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] RC8

[Zeev Suraski]

http://www.php.net/distributions/php-4.0.5RC8.tar.gz

If there are no hell-broken-loose situations, 4.0.5 will be released next 
Monday.

Zeev


--
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] RE: [PHP-QA] RC8

[Liz]

If someone can compile up a windows set, and mail me the base DLLs+EXE and the
MS-SQL-DLL one, I'd be eternally grateful, as it took me about 3 hours to
compile it over citrix and then SMS to a machine with the stuff to do so.

I'd like the CGI + ISAPI version with MS-SQL, its for IIS, but I dont use any
other extensions at the moment.. I'll then trash it a bit..

Thanks

Liz


-- 
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: configure fails when I include Oracle 8.1.7

[ian_palfrey]

From: [EMAIL PROTECTED]
Operating system: AIX 4.3.3
PHP version:  4.0.4pl1
PHP Bug Type: Compile Failure
Bug description:  configure fails when I include Oracle 8.1.7

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


-- 
Edit Bug report at: http://bugs.php.net/?id=10513&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 #10464 Updated: PHP_AUTH_PW is not setaltough PHP_AUTH_USER is

[Rasmus Lerdorf]

> I figured out that our webmaster took special care
> for passwords - we have AFS here and AFS passwords are
> often used to authenticate Web stuff.
>
> Therefore he somehow deletes PHO_AUTH_PW before my script
> gets executed.
>
> Sorry for the wrong bug - the real bug is that I need to
> be able to tell PHP not to reveal passwords already used
> by Apache for some kind of authentication.

But even if PHP tries to hide this, you can still get it straight from the
browser headers.  It will be in the Authentication header using trivial
base64 encoding.  A base64_decode() on the authentication header will
reveal the username and password.

-Rasmus


-- 
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 #9435 Updated: Unreproducable crash of PHP

[jmoore]

ID: 9435
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: IIS related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

could you translate the errors please.

- James

Previous Comments:
---

[2001-02-24 08:18:07] [EMAIL PROTECTED]
After some time of browsing a PHP website (access to an oracle DB not on the same 
machine) PHP crashes:

PHP has encountered an Access Violation at 011A2466

Event-Log entry (sorry, german):

Ereignistyp:Fehler (error, type)
Ereignisquelle: WAM (source)
Ereigniskategorie:  Keine (category "None")
Ereigniskennung:204 (event-id)
Datum:  24.02.2001 (date)
Zeit:   11:03:45 (time)
Benutzer:   Nicht zutreffend (user)
Computer:   AD-OPAS1 (computer)
Beschreibung: (description)
Der HTTP-Server ist bei der Verarbeitung der ISAPI-Anwendung '
php4ts!zend_strndup + 0x2B
 + 0xA05F69B8
' auf eine unerwartete Ausnahme gestoßen. (unexpected exception in isapi-application)


I can continue surfing after the corresponding dllhost.exe is terminated using the 
task manager, or the iis-admin service is restarted.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9435&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 #6620 Updated: Inst'n should not be made for root web service

[jmoore]

ID: 6620
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: IIS related
PHP Version: 4.0.2
Assigned To: 
Comments:

The install instructions are just a guide. People who want to run PHP on IIS in a 
production enviroment should be aware of the correct way to set things up. Setting up 
as a cgi is well documented in the manual:
http://uk.php.net/manual/en/install.iis.php

- James

Previous Comments:
---

[2000-09-09 23:01:44] [EMAIL PROTECTED]

Correction

Running each web site as a separate problem only seems to
lessen these access violation problems.

The installation instructions included with the win 32
binaries should instead also include an outline for
installation php.exe as a CGI instead of using
php4isapi.dll, since this seems to make these mysterious
problems disappear.

---

[2000-09-08 01:59:10] [EMAIL PROTECTED]
Installation for IIS of PHP 4.0.2 says to add the php engine to the root web service.

This is not advisable when running more than one web site.

Since, (as to be expected) there are still problems in this release.  It would appear 
that random access violations disappear when you install php4isapi.dll for each web 
site (service) and have each web site (service) running as its own process.



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=6620&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 #10346 Updated: Bad configuration in windows nt with iis 4.0

[jmoore]

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

This looks like a install error. Please ask on php-win and php-install for help

- James

Previous Comments:
---

[2001-04-16 12:16:28] [EMAIL PROTECTED]
Hello:

I try to install php in a NT web server. I followed the instructions in the 
documentation, but the simple example does not work   :

 
  Ejemplo PHP 
 
 
  
 
 

Do nothing. I only can see a white page.


The php.ini is in the directory c:winnt this is the file:
I only change the extension_dir

[PHP]

;;;
; About this file ;
;;;
; This file controls many aspects of PHP's behavior.  In order for PHP to
; read it, it must be named 'php.ini'.  PHP looks for it in the current
; working directory, in the path designated by the environment variable
; PHPRC, and in the path that was defined in compile time (in that order).
; Under Windows, the compile-time path is the Windows directory.  The
; path in which the php.ini file is looked for can be overriden using
; the -c argument in command line mode.
;
; The syntax of the file is extremely simple.  Whitespace and Lines
; beginning with a semicolon are silently ignored (as you probably guessed).
; Section headers (e.g. [Foo]) are also silently ignored, even though
; they might mean something in the future.
;
; Directives are specified using the following syntax:
; directive = value
; Directive names are *case sensitive* - foo=bar is different from FOO=bar.
;
; The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one
; of the INI constants (On, Off, True, False, Yes, No and None) or an expression
; (e.g. E_ALL & ~E_NOTICE), or a quoted string ("foo").
;
; Expressions in the INI file are limited to bitwise operators and parentheses:
; | bitwise OR
; & bitwise AND
; ~ bitwise NOT
; ! boolean NOT
;
; Boolean flags can be turned on using the values 1, On, True or Yes.
; They can be turned off using the values 0, Off, False or No.
;
; An empty string can be denoted by simply not writing anything after the equal
; sign, or by using the None keyword:
;
;   foo =   ; sets foo to an empty string
;   foo = none  ; sets foo to an empty string
;   foo = "none"; sets foo to the string 'none'
;
; If you use constants in your value, and these constants belong to a dynamically
; loaded extension (either a PHP extension or a Zend extension), you may only
; use these constants *after* the line that loads the extension.
;
; All the values in the php.ini-dist file correspond to the builtin
; defaults (that is, if no php.ini is used, or if you delete these lines,
; the builtin defaults will be identical).



; Language Options ;


engine  =   On  ; Enable the PHP scripting language engine 
under Apache
short_open_tag  =   On  ; allow the  tags are recognized.
asp_tags=   Off ; allow ASP-style <% %> tags
precision   =   14  ; number of significant digits displayed in 
floating point numbers
y2k_compliance  =   Off ; whether to be year 2000 compliant (will cause 
problems with non y2k compliant browsers)
output_buffering= Off   ; Output buffering allows you to send header lines 
(including cookies)
; even after you send body 
content, in the price of slowing PHP's
; output layer a bit.
; You can enable output 
buffering by in runtime by calling the output
; buffering functions, or 
enable output buffering for all files
; by setting this directive to 
On.
output_handler  =   ; You can redirect all of the output of your 
scripts to a function,
; that can be responsible to 
process or log it.  For example,
; if you set the 
output_handler to "ob_gzhandler", than output
; will be transparently 
compressed for browsers that support gzip or
; deflate encoding.  Setting 
an output handler automatically turns on
; output buffering.
implicit_flush  = Off   ; Implicit flush tells PHP 

[PHP-DEV] Bug #10258 Updated: ActiveX ASP pages on the same Web server seems not to work properly any more!

[jmoore]

ID: 10258
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IIS related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

Not enough information and dup of 8094

Previous Comments:
---

[2001-04-10 09:35:16] [EMAIL PROTECTED]


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10258&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] function table

[David Croft]

Hello, I'm implementing an extension that allows user callbacks.

The Zend API document suggests using the Compiler globals to access the
function table. However I see the XML extension is using Executor globals.

Which is correct? is there a difference? If I were to take a wild guess
I'd say the CG only had global functions and EG has functions currently in
scope - is that right?

Thanks,
David

-- 
|> /+\ \| | |>

David Croft
Infotrek





-- 
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] function table

[Andrei Zmievski]

On Thu, 26 Apr 2001, David Croft wrote:
> 
> Hello, I'm implementing an extension that allows user callbacks.
> 
> The Zend API document suggests using the Compiler globals to access the
> function table. However I see the XML extension is using Executor globals.
> 
> Which is correct? is there a difference? If I were to take a wild guess
> I'd say the CG only had global functions and EG has functions currently in
> scope - is that right?

EG may have functions that were defined during run-time.

-Andrei
* We are not a clone. *

-- 
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 #10510 Updated: ini_set() as relates to max upload filesize setting

[Boian Bonev]

i forgot to say that maybe we shall add two more bugs from this one -

- a feature request for not allowing nonsense settings like the mentioned in
the list
- i don't know if is it a good idea post file upload to generate a warning
when limit is exceeded

b.

- Original Message -
From: "Hartmut Holzgraefe" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, April 26, 2001 5:59 PM
Subject: Re: [PHP-DEV] Bug #10510 Updated: ini_set() as relates to max
upload filesize setting


> [EMAIL PROTECTED] wrote:
> > Please take into account that the processing of post data happens
> > _before_ your call to ini_set. Thus your new limit value has no effect
> > to the upload and succeeds (of course) after the upload is rejected.
>
> maybe we should think about a way to mark all ini settings like these
> and generate warnings when ini_set is used at runtime to change them
>
> --
> 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]
>
>


-- 
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 #10510 Updated: ini_set() as relates to max upload filesize setting

[Boian Bonev]

sure. i guess at least about egpcs handling, arg separator, magic quotes,
perhapse some session options, register_globals, safe_mode.

lets make a list - this can be easily fixed. :)

b.

- Original Message -
From: "Hartmut Holzgraefe" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, April 26, 2001 5:59 PM
Subject: Re: [PHP-DEV] Bug #10510 Updated: ini_set() as relates to max
upload filesize setting


> [EMAIL PROTECTED] wrote:
> > Please take into account that the processing of post data happens
> > _before_ your call to ini_set. Thus your new limit value has no effect
> > to the upload and succeeds (of course) after the upload is rejected.
>
> maybe we should think about a way to mark all ini settings like these
> and generate warnings when ini_set is used at runtime to change them
>
> --
> 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]
>
>


-- 
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-QA] RC8

[Phil Driscoll]

Just built RC8 without incident on NT4 SP6 and Suse 7.1.
Tested on NT with phpMyAdmin, phorum and all my own code - all fine (as
usual!).
Only done a phpinfo() on Linux - but it worked ok :)
Got to go now, but will test more later.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
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-QA] RC8

[Matt White]

Liz;

http://myrile.madriver.k12.oh.us/technology/php/php-4.0.5RC8-win32-ts.zip

Contains ISAPI, CGI, and Apache/Win32 builds. The only extension I've included is the 
MS-SQL one.

- Matt

>>> Liz <[EMAIL PROTECTED]> 04/26/01 12:32PM >>>
If someone can compile up a windows set, and mail me the base DLLs+EXE and the
MS-SQL-DLL one, I'd be eternally grateful, as it took me about 3 hours to
compile it over citrix and then SMS to a machine with the stuff to do so.

I'd like the CGI + ISAPI version with MS-SQL, its for IIS, but I dont use any
other extensions at the moment.. I'll then trash it a bit..

Thanks

Liz


-- 
PHP Quality Assurance 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 #9435 Updated: Unreproducable crash of PHP

[Sterling Hughes]

On 26 Apr 2001 [EMAIL PROTECTED] wrote:

> ID: 9435
> Updated by: jmoore
> Reported By: [EMAIL PROTECTED]
> Old-Status: Open
> Status: Feedback
> Bug Type: IIS related
> PHP Version: 4.0.4pl1
> Assigned To:
> Comments:
>
> could you translate the errors please.
>

he did (in parentheses).

-sterling

> - James
>
> Previous Comments:
> ---
>
> [2001-02-24 08:18:07] [EMAIL PROTECTED]
> After some time of browsing a PHP website (access to an oracle DB not on the same 
>machine) PHP crashes:
>
> PHP has encountered an Access Violation at 011A2466
>
> Event-Log entry (sorry, german):
>
> Ereignistyp:  Fehler (error, type)
> Ereignisquelle:   WAM (source)
> Ereigniskategorie:Keine (category "None")
> Ereigniskennung:  204 (event-id)
> Datum:24.02.2001 (date)
> Zeit: 11:03:45 (time)
> Benutzer: Nicht zutreffend (user)
> Computer: AD-OPAS1 (computer)
> Beschreibung: (description)
> Der HTTP-Server ist bei der Verarbeitung der ISAPI-Anwendung '
> php4ts!zend_strndup + 0x2B
>  + 0xA05F69B8
> ' auf eine unerwartete Ausnahme gestoßen. (unexpected exception in isapi-application)
>
>
> I can continue surfing after the corresponding dllhost.exe is terminated using the 
>task manager, or the iis-admin service is restarted.
>
> ---
>
>
>
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at http://bugs.php.net/?id=9435&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] Fw: [PHP-DOC] cfunction?

[Hojtsy Gabor]

This is a question for the php-dev people too.
What are the other hidden features not documented
like this?


- Original Message - 
From: "Hojtsy Gabor" <[EMAIL PROTECTED]>
To: "PHP-DOC lista" <[EMAIL PROTECTED]>
Sent: Thursday, April 26, 2001 7:29 PM
Subject: [PHP-DOC] cfunction?


> Hi!
> 
> One interesting question dropped in on the hungarian php
> mailing list. There is an example file bundled with PHP:
> 
> /php-4.0.4pl1/tests/classes/class_example.phpt
> 
> The piece of code:
> 
> 
> /* pretty nifty object oriented code! */
> 
> class user {
>   var $first_name,$family_name,$address,$phone_num;
>   cfunction display()
>   {
> echo "User information\n";
> echo "\n\n";
> 
> 
> 
> But what is cfunction It is not documented...
> 
> Goba
> ... . . .  .  .
> Editor of the Hungarian PHP manual, Admin of the Hungarian PHP mirror
> 
> 
> 


-- 
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] Fw: [PHP-DOC] cfunction?

[Rasmus Lerdorf]

> This is a question for the php-dev people too.
> What are the other hidden features not documented
> like this?

Check the code.  This is simply a legacy feature there only for backward
compatibility and should not be documented as we don't want people writing
new scripts that use cfunction.

-Rasmus


-- 
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 #8663 Updated: Script with incorrect syntax crashes php4ts.dll (seems similar to #8521)

[jmoore]

ID: 8663
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproduceable crash
PHP Version: 4.0.4
Assigned To: 
Comments:

Reproduced under Apache and ISAPI under win2k.

- James

Previous Comments:
---

[2001-01-11 16:59:07] [EMAIL PROTECTED]
I have three php files as follows:

--f1.php--

--

--f2.php--

--

--f3.php--

--

When running f1.php through php.exe I get

PHP caused an invalid page fault in
module PHP4TS.DLL at 015f:1008e147.
Registers:
EAX=0001 CS=015f EIP=1008e147 EFLGS=00010206
EBX=006601ec SS=0167 ESP=0063f410 EBP=00791710
ECX= DS=0167 ESI=00791714 FS=541f
EDX=007910dc ES=0167 EDI=006601e4 GS=
Bytes at CS:EIP:
66 ff 48 0a 8b 06 66 8b 48 0a 66 85 c9 75 40 50 
Stack dump:
007612f0 100a46bb 00791714 00791990 007612f0 007918e0 0065ea04 006601c4 006601c4 
0001 007910dc 006601ec 81709050   0063f470 

Couldn't generate a backtrace, the borland debugger refused to work on this error. It 
seems to be similar to the problem described in bug #8521. In both cases a simple 
syntax error crashes the DLL. In this case, however, the include directives seem to 
have something to do with the bug. Simply copying the contents of f2 and f3 into f1 
does not cause a crash.

PHP is 4.0.4 windows installer from your website.

Bye,
Paul


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8663&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 #8396 Updated: "document not found"

[jmoore]

ID: 8396
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: IIS related
PHP Version: 4.0.3
Assigned To: 
Comments:

This looks more like a config error tahn a PHP error.
Please reopen this bug report if you are sure its a PHP error but the page your seeing 
certainly isnt generated by PHP.

- James

Previous Comments:
---

[2000-12-24 01:15:56] [EMAIL PROTECTED]
on any other machine scripts work fine, everything performs as planned.  On my own 
machine, however, contacting scripts on my server through the lan causes the following 
error:

 The page cannot be displayed 
There is a problem with the page you are trying to reach and it cannot be displayed. 



Please try the following:

Open the 192.168.0.2 home page, and then look for links to the information you want. 
Click the  Refresh button, or try again later.

Click  Search to look for information on the Internet. 
You can also see a list of related sites. 




HTTP 500 - Internal server error 
Internet Explorer  


I am behind a netgear router which doesnt allow me to directly access the domain.  
This error was produced when doing a script using a POST type action, if i switch to 
GET the error is gone, but then my variable are open for the world to see...

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8396&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] function table

[Andi Gutmans]

At 02:16 PM 4/26/2001 -0400, David Croft wrote:

>Hello, I'm implementing an extension that allows user callbacks.
>
>The Zend API document suggests using the Compiler globals to access the
>function table. However I see the XML extension is using Executor globals.

During execution the correct table to use is the executor globals one, 
i.e., EG(function_table).

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 #8663 Updated: Script with incorrect syntax crashes php4ts.dll (seems similar to #8521)

[jmoore]

ID: 8663
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: Reproduceable crash
PHP Version: 4.0.4
Assigned To: 
Comments:

heh trying a modified script didnt work but trying your script again crashses.

Backtrace:

_zval_ptr_dtor(_zval_struct * * 0x00e00b8c, char * 0x1022188c `string', unsigned int 
236) line 259 + 5 bytes
zend_switch_free(_zend_op * 0x00dae5c0, _temp_variable * 0x00e00b88, 
_zend_executor_globals * 0x00db21e0) line 236 + 38 bytes
execute(_zend_op_array * 0x00e00c28, _zend_executor_globals * 0x00db21e0) line 1831 + 
17 bytes
execute(_zend_op_array * 0x00dff2f8, _zend_executor_globals * 0x00db21e0) line 2039 + 
19 bytes
zend_execute_scripts(int 8, _zend_compiler_globals * 0x00db28f0, 
_zend_executor_globals * 0x00db21e0, int 3) line 743 + 22 bytes
php_execute_script(_zend_file_handle * 0x0012ff48, _zend_compiler_globals * 
0x00db28f0, _zend_executor_globals * 0x00db21e0, _php_core_globals * 0x00db52c0) line 
1205 + 29 bytes
main(int 3, char * * 0x00db18c0) line 735 + 22 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e992a6()




Previous Comments:
---

[2001-04-26 14:53:41] [EMAIL PROTECTED]
THis has been fixed in latest CVS, and will be included in 4.0.6 thanks for your 
report.


- James

---

[2001-04-26 14:25:50] [EMAIL PROTECTED]
Reproduced under Apache and ISAPI under win2k.

- James

---

[2001-01-11 16:59:07] [EMAIL PROTECTED]
I have three php files as follows:

--f1.php--

--

--f2.php--

--

--f3.php--

--

When running f1.php through php.exe I get

PHP caused an invalid page fault in
module PHP4TS.DLL at 015f:1008e147.
Registers:
EAX=0001 CS=015f EIP=1008e147 EFLGS=00010206
EBX=006601ec SS=0167 ESP=0063f410 EBP=00791710
ECX= DS=0167 ESI=00791714 FS=541f
EDX=007910dc ES=0167 EDI=006601e4 GS=
Bytes at CS:EIP:
66 ff 48 0a 8b 06 66 8b 48 0a 66 85 c9 75 40 50 
Stack dump:
007612f0 100a46bb 00791714 00791990 007612f0 007918e0 0065ea04 006601c4 006601c4 
0001 007910dc 006601ec 81709050   0063f470 

Couldn't generate a backtrace, the borland debugger refused to work on this error. It 
seems to be similar to the problem described in bug #8521. In both cases a simple 
syntax error crashes the DLL. In this case, however, the include directives seem to 
have something to do with the bug. Simply copying the contents of f2 and f3 into f1 
does not cause a crash.

PHP is 4.0.4 windows installer from your website.

Bye,
Paul


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8663&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] Fw: [PHP-DOC] cfunction?

[Hojtsy Gabor]

> > This is a question for the php-dev people too.
> > What are the other hidden features not documented
> > like this?
>
> Check the code.  This is simply a legacy feature there only for backward
> compatibility and should not be documented as we don't want people writing
> new scripts that use cfunction.

Then why it is used in some scripts in the test dir
in the distribution?

Goba
... . . .  .  .
Editor of the Hungarian PHP manual, Admin of the Hungarian PHP mirror


-- 
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] Fw: [PHP-DOC] cfunction?

[Andi Gutmans]

At 09:41 PM 4/26/2001 +0200, Hojtsy Gabor wrote:
> > > This is a question for the php-dev people too.
> > > What are the other hidden features not documented
> > > like this?
> >
> > Check the code.  This is simply a legacy feature there only for backward
> > compatibility and should not be documented as we don't want people writing
> > new scripts that use cfunction.
>
>Then why it is used in some scripts in the test dir
>in the distribution?

It shouldn't be. I'll fix those.

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 #10515: IE 5.0

[dshadow]

From: [EMAIL PROTECTED]
Operating system: Windows NT 4.0 SP6
PHP version:  4.0.4pl1
PHP Bug Type: Unknown/Other Function
Bug description:  IE 5.0 

When using multipart/form-data post forms and NT domain authentication, IE 5.0 appears 
to submit invalid data to the server, causing PHP to ignore all form variables. A 
print_r($GLOBALS) shows that the data in $CONTENT_TYPE is doubled, causing PHP to 
improperly process the content and not receive any data. IE 5.5 does not exhibit this 
problem.


-- 
Edit Bug report at: http://bugs.php.net/?id=10515&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.5: Merge Request

[Andi Gutmans]

At 12:11 AM 4/26/2001 -0400, Sterling Hughes wrote:
>I'll agree that the inverse of the above is true ;)))
>
>But if you look at it over time, it averages out, making the net
>effect equal 0.
>
>anyway, I think we agree on the math, we just disagree on whether the
>short term affect is worth it.
>
>regardless of the outcome, I'm fine though, I think that soon enough
>the releases (because of there nature) will become a feature freeze (as
>more features get added, there are less features that need to be added,
>plus the core is getting smaller soon, so the net effect will be more bug
>fix releases and less feature releases)...

It's psychological and a state of mind thing. If all developers know that 
for the next few days they shouldn't concentrate on adding new 
functionality but should help out the project by trying to fix bugs you'll 
end up having more bugs fixed.
I think usually developers prefer to work on new functionality and won't 
help with other bugs too much. If there is a call for this and some time 
frame trying to get everyone to work together that could make a difference 
(and respect to the guy who fixes the most amount of bugs ;)
By the way, it's not the end of the world if someone developers code on his 
machine at home and only commits it a few days later. You're not forcing 
him to stop development because he can still do it at home but at least you 
get the state of mind across and I think a lot of developers will join in.
Andi
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] Fw: [PHP-DOC] cfunction?

[Rasmus Lerdorf]

> > > This is a question for the php-dev people too.
> > > What are the other hidden features not documented
> > > like this?
> >
> > Check the code.  This is simply a legacy feature there only for backward
> > compatibility and should not be documented as we don't want people writing
> > new scripts that use cfunction.
>
> Then why it is used in some scripts in the test dir
> in the distribution?

The whole point of the test dir is to make sure no legacy bugs creep in.

-Rasmus


-- 
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] Fw: [PHP-DOC] cfunction?

[Rasmus Lerdorf]

> At 09:41 PM 4/26/2001 +0200, Hojtsy Gabor wrote:
> > > > This is a question for the php-dev people too.
> > > > What are the other hidden features not documented
> > > > like this?
> > >
> > > Check the code.  This is simply a legacy feature there only for backward
> > > compatibility and should not be documented as we don't want people writing
> > > new scripts that use cfunction.
> >
> >Then why it is used in some scripts in the test dir
> >in the distribution?
>
> It shouldn't be. I'll fix those.

Leave one, at least.  We want to know if this breaks.  At some point we
will want to remove the feature from php, and then we can remove the test
case.  But let's not remove testcases without removing the feature.  The
test scripts are not meant as examples for users.

-Rasmus


-- 
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 #8663 Updated: Script with incorrect syntax crashes php4ts.dll (seems similar to #8521)

[jmoore]

ID: 8663
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Reproduceable crash
PHP Version: 4.0.4
Assigned To: 
Comments:

THis has been fixed in latest CVS, and will be included in 4.0.6 thanks for your 
report.


- James

Previous Comments:
---

[2001-04-26 14:25:50] [EMAIL PROTECTED]
Reproduced under Apache and ISAPI under win2k.

- James

---

[2001-01-11 16:59:07] [EMAIL PROTECTED]
I have three php files as follows:

--f1.php--

--

--f2.php--

--

--f3.php--

--

When running f1.php through php.exe I get

PHP caused an invalid page fault in
module PHP4TS.DLL at 015f:1008e147.
Registers:
EAX=0001 CS=015f EIP=1008e147 EFLGS=00010206
EBX=006601ec SS=0167 ESP=0063f410 EBP=00791710
ECX= DS=0167 ESI=00791714 FS=541f
EDX=007910dc ES=0167 EDI=006601e4 GS=
Bytes at CS:EIP:
66 ff 48 0a 8b 06 66 8b 48 0a 66 85 c9 75 40 50 
Stack dump:
007612f0 100a46bb 00791714 00791990 007612f0 007918e0 0065ea04 006601c4 006601c4 
0001 007910dc 006601ec 81709050   0063f470 

Couldn't generate a backtrace, the borland debugger refused to work on this error. It 
seems to be similar to the problem described in bug #8521. In both cases a simple 
syntax error crashes the DLL. In this case, however, the include directives seem to 
have something to do with the bug. Simply copying the contents of f2 and f3 into f1 
does not cause a crash.

PHP is 4.0.4 windows installer from your website.

Bye,
Paul


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8663&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 #10515 Updated: IE 5.0

[dshadow]

ID: 10515
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Unknown/Other Function
Description: IE 5.0

Addendum: IE 5.0.1 SP 2 works correctly. ASP also properly processes forms submitted 
by IE 5.0.

Previous Comments:
---

[2001-04-26 14:47:20] [EMAIL PROTECTED]
When using multipart/form-data post forms and NT domain authentication, IE 5.0 appears 
to submit invalid data to the server, causing PHP to ignore all form variables. A 
print_r($GLOBALS) shows that the data in $CONTENT_TYPE is doubled, causing PHP to 
improperly process the content and not receive any data. IE 5.5 does not exhibit this 
problem.

---


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


-- 
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 #7910 Updated: urlp arameters not available in the default page

[jmoore]

ID: 7910
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IIS related
PHP Version: 4.0.4
Assigned To: 
Comments:

This seems like a IIS problem rather than a PHP one. We probably need to test this 
with other isapi and cgi dlls under IIS to confirm this then pass a bug report about 
the behaviour on to msft if this is the case.



Previous Comments:
---

[2000-12-27 12:32:35] [EMAIL PROTECTED]
I updated to PHP 4.0.4

I still have the same problem in ISAPI AND in CGI mode 

---

[2000-11-21 17:20:10] [EMAIL PROTECTED]
I am using PGP as an ISAPI extension woth IIS 4.0

IIS is configured to laak for a default page named index.php3

If I pass a parameter in the URL with the folowing syntax 
"http://www.domaine.com/?page=1"; the variable page is empty in the my php script.

If I include the name of the page in the URL 
"http://www.domaine.com/index.php3?page=1"; everything working my page vraiable contain 
1


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=7910&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] Fw: [PHP-DOC] cfunction?

[Andi Gutmans]

At 12:51 PM 4/26/2001 -0700, Rasmus Lerdorf wrote:
> > At 09:41 PM 4/26/2001 +0200, Hojtsy Gabor wrote:
> > > > > This is a question for the php-dev people too.
> > > > > What are the other hidden features not documented
> > > > > like this?
> > > >
> > > > Check the code.  This is simply a legacy feature there only for 
> backward
> > > > compatibility and should not be documented as we don't want people 
> writing
> > > > new scripts that use cfunction.
> > >
> > >Then why it is used in some scripts in the test dir
> > >in the distribution?
> >
> > It shouldn't be. I'll fix those.
>
>Leave one, at least.  We want to know if this breaks.  At some point we
>will want to remove the feature from php, and then we can remove the test
>case.  But let's not remove testcases without removing the feature.  The
>test scripts are not meant as examples for users.

It won't break and if it does, all the better :)
As you see people do take example from the test cases if they are meant to 
be testcases or not.
I think for 4.1 we should nuke cfunction and possible also old_function. 
Don't forget that cfunction had a very very short live-time in the beta's 
of PHP 3. We made the function<->old_function switch pretty early.

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 #10220 Updated: dynamic module can'nt not load

[jmoore]

ID: 10220
Updated by: jmoore
Reported By: littlekai@#163.com
Old-Status: Open
Status: Duplicate
Bug Type: IIS related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

dup of 9686

Previous Comments:
---

[2001-04-06 23:43:01] littlekai@#163.com
where use the iis4.0 as my php web server,i want to load php_ifx.dll 
the php return the error code like this :
 X-Powered-By: PHP/4.0.4pl1 Content-type: text/html hello, world!! PHP Warning: Unable 
to load dynamic library './extensions/php_ifx.dll'
 but where i change the web server to apache ,everything is ok.
 i am sure i had configure the php flowering the install notes exactly.
here is my php.ini

[PHP]

;;;
; About this file ;
;;;
; This file controls many aspects of PHP's behavior.  In order for PHP to
; read it, it must be named 'php.ini'.  PHP looks for it in the current
; working directory, in the path designated by the environment variable
; PHPRC, and in the path that was defined in compile time (in that order).
; Under Windows, the compile-time path is the Windows directory.  The
; path in which the php.ini file is looked for can be overriden using
; the -c argument in command line mode.
;
; The syntax of the file is extremely simple.  Whitespace and Lines
; beginning with a semicolon are silently ignored (as you probably guessed).
; Section headers (e.g. [Foo]) are also silently ignored, even though
; they might mean something in the future.
;
; Directives are specified using the following syntax:
; directive = value
; Directive names are *case sensitive* - foo=bar is different from FOO=bar.
;
; The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one
; of the INI constants (On, Off, True, False, Yes, No and None) or an expression
; (e.g. E_ALL & ~E_NOTICE), or a quoted string ("foo").
;
; Expressions in the INI file are limited to bitwise operators and parentheses:
; | bitwise OR
; & bitwise AND
; ~ bitwise NOT
; ! boolean NOT
;
; Boolean flags can be turned on using the values 1, On, True or Yes.
; They can be turned off using the values 0, Off, False or No.
;
; An empty string can be denoted by simply not writing anything after the equal
; sign, or by using the None keyword:
;
;   foo =   ; sets foo to an empty string
;   foo = none  ; sets foo to an empty string
;   foo = "none"; sets foo to the string 'none'
;
; If you use constants in your value, and these constants belong to a dynamically
; loaded extension (either a PHP extension or a Zend extension), you may only
; use these constants *after* the line that loads the extension.
;
; All the values in the php.ini-dist file correspond to the builtin
; defaults (that is, if no php.ini is used, or if you delete these lines,
; the builtin defaults will be identical).



; Language Options ;


engine  =   On  ; Enable the PHP scripting language engine 
under Apache
short_open_tag  =   On  ; allow the  tags are recognized.
asp_tags=   Off ; allow ASP-style <% %> tags
precision   =   14  ; number of significant digits displayed in 
floating point numbers
y2k_compliance  =   Off ; whether to be year 2000 compliant (will cause 
problems with non y2k compliant browsers)
output_buffering= Off   ; Output buffering allows you to send header lines 
(including cookies)
; even after you send body 
content, in the price of slowing PHP's
; output layer a bit.
; You can enable output 
buffering by in runtime by calling the output
; buffering functions, or 
enable output buffering for all files
; by setting this directive to 
On.
implicit_flush  = Off   ; Implicit flush tells PHP to tell the output layer to 
flush itself
; automatically after every 
output block.  This is equivalent to
; calling the PHP function 
flush() after each and every call to print()
; or echo() and each and every 
HTML block.
; Turning this option on has 
serious performance implications, and
; is generally recommended for 
debugging purposes only.
allow_call_time_pass_reference  = On; whether to enabl

[PHP-DEV] Bug #10514: Uploaded file not stored in "upload_tmp_dir"

[fhamonno]

From: [EMAIL PROTECTED]
Operating system: Linux server27.promotion-web.net 2.2.12-20 #1 Mon Sep 27 10:40:35 
EDT 1999 i686 unknown
PHP version:  4.0.4pl1
PHP Bug Type: PHP options/info functions
Bug description:  Uploaded file not stored in "upload_tmp_dir"

On the server, and according to phpInfo(), main PHP variables are:
Apache Version = Apache/1.3.19 
Apache Release = 10319100 
Apache API Version = 19990320 
User/Group = nobody(99)/99
Loaded Modules = mod_php4, .

Session Support = enabled
session.auto_start = Off

upload_max_filesize = 100
upload_tmp_dir = ./tmp/

I'm running the script below; it's located in a directory where has been created a 
directory "tmp" (so the path "./tmp/" is OK) with rights set to "777" (chmod):


Upload Test

 le formulaire est affiché
// A l'envoi du formulaire, "action" est renseigné
// => le script affiche les paramètres du fichier télé chargé
//et affiche le début du fichier

if ( !$action ) {

// Affichage du formulaire

  echo "\n";
  echo "\n";
  echo "Send this file: ";
  echo "\n";
  echo "\n";
  echo "\n";
  echo "\n";

} else {

// Affichage des paramètres du fichier téléchargé

  echo "Size: $userfile_size\n";
  echo "Type: $userfile_type\n";
  echo "Name: $userfile_name\n";
  echo "File: $userfile \n";

// Listing du répertoire "./tmp"

  $dir='./tmp';
  $handle=opendir($dir);
  echo "Pointeur de dossier: $handle\n";
  echo "Fichiers de $dir:\n";
  while ($fic = readdir($handle)) {
  echo "$fic\n";
  }
  closedir($handle); 
  echo "\n";

// Suppression des doubles slash dans le nom de fichier

  $file=ereg_replace("//+","/",$userfile);

// Lecture et affichage du début du fichier

  $fd=fopen($file,"r") or die ("Unable to open uploaded file!");
  $data=fread($fd, MAX_SIZE);
  fclose($fd);
  echo "Beginning of file: ".substr($data, 0, 25);
  
}
?>




The variables displayed are the one expected (user's file name, type, size), the temp 
file has a coherent name ("./tmp/phpxx")... but upload directory "./tmp" remains 
empty.
There is no error generated in "error.log" during PHP recovery of uploaded file. An 
error occurs when the script try to access the file.

I've double-checked everything I could think of...

The problem exposed seems to be the same as the one posted with Bug id #10386.



-- 
Edit Bug report at: http://bugs.php.net/?id=10514&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] PHP 4.0 Bug #10510 Updated: ini_set() as relates to max upload filesize setting

[webmaster]

ID: 10510
User Update by: [EMAIL PROTECTED]
Status: Closed
Bug Type: *Function Specific
Description: ini_set() as relates to max upload filesize setting

Okay, makes sense, which is partly why I would call ini_set "before" the form is 
loaded and data posted,
I guess I do misunderstand, as I thought that the set would remain intact until the 
call to restore?

By what you are saying, it would appear that the restore function would serve no 
purpose??

You mention using htaccess to set the limits, can you point me to some documentation 
on this? I am familiar with htaccess and the Apache server, but not specify PHP ini 
limits via such?

Previous Comments:
---

[2001-04-26 10:28:12] [EMAIL PROTECTED]
Please take into account that the processing of post data happens _before_ your call 
to ini_set. Thus your new limit value has no effect to the upload and succeeds (of 
course) after the upload is rejected.

I would recommend setting the value through .htaccess or apache's config.


---

[2001-04-26 09:58:38] [EMAIL PROTECTED]
First, let me say that I'm not entirely sure I would class this report as a bug, but 
it very well could be.

Recently, as in yesterday, I spent a number of hours trying to find a work-around to 
the maximum upload filesize setting.  I came across the ini_set() functions.

This appeared to be something of a solution to the delimma, by issuing a ini_set() to 
the max upload filesize, I figured I would be able to conduct a file upload that 
exceeded the default 2M limit.

It would appear that I was wrong.

Here is the situation which presented itself, and ultimately will explain why I'm 
emailing as a bug report.

 The Scenario -
My script resides on a "hosted" server, one which is beyond my direct control.  
Naturally the host controls the settings, and the like.

I needed to conduct file uploads, which may or may not exceed the default limit.  
After reviewing the manual, I found the ini_set functions. So, I decided to test the 
over-ride of the ini's setting for a max upload filesize.

For test purposes, we chose 4M, and issued an ini_set() to PHP. The set was 
successful, and our local value for the max upload filesize was 4M.

No problem, this is awesome I thought to myself, so we moved forward and attempted to 
upload, using a "file" field named file_url.

The end result was just un-real.

We selected a file that weighed in at approx. 2.2MB just .2 over the default limit, 
but well within our defined max size.

We watched our modems and bandwidth meters, seeing the transmit of the file to the 
server... (we think all is going sweetly).. then, nothing.

PHP gave no errors, as a matter of fact the script executed perfectly.  cept that the 
value of file_url became "none".. obviously something went wrong.. 

Here's what we ultimately discovered.

1) "IF" the file exceeded 2M (the default) the value of the file field is stripped and 
returns as "none" (as if no file was uploaded).

2) PHP Gives no "limit exceeded" error, or any errors for that matter.

3) "IF" the file is below the 2M limit, all is perfect.

In short, it would appear that the ini_set(), though it displays as being set, has no 
real affect.  Bug? I don't know.. I do however feel, that at the very least, PHP 
should give us some type of error message.. In the end, I'm left with the feeling that 
one of two possiblities exist here, 1) the ini_set() function holds no real coding 
value, or 2) I don't fully understand the function.  Granted, documentation is 
somewhat limited on these..

---


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


-- 
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] Fw: [PHP-DOC] cfunction?

[Rasmus Lerdorf]

> >Leave one, at least.  We want to know if this breaks.  At some point we
> >will want to remove the feature from php, and then we can remove the test
> >case.  But let's not remove testcases without removing the feature.  The
> >test scripts are not meant as examples for users.
>
> It won't break and if it does, all the better :)
> As you see people do take example from the test cases if they are meant to
> be testcases or not.

Yes, but the thing is there because there are scripts that use it.  If we
break it, then these scripts will break.  Therefore a test case should
remain so we don't break it.  If you are worried about the testcase
setting a bad example, stick a comment in there.  You don't remove test
cases for features just because you don't like them.  If it is part of the
language, it needs to be part of the regression testing.

> I think for 4.1 we should nuke cfunction and possible also old_function.
> Don't forget that cfunction had a very very short live-time in the beta's
> of PHP 3. We made the function<->old_function switch pretty early.

That's a completely separate issue.  And I agree that the feature and the
test case should be removed.

-Rasmus


-- 
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 #4630 Updated: Segmentation fault(coredump) in apache startup

[dshafer]

ID: 4630
Updated by: dshafer
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Compile Failure
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

Still happening as of 4.0.4pl1. It seems like there's enough information to fix the 
problem, for somebody who knows the source code. Would someone be able to look at 
this? Is there any more information you need?

Previous Comments:
---

[2001-02-15 15:10:36] [EMAIL PROTECTED]
The segfault still occurs as of php4-200102131445.

---

[2000-12-18 10:55:46] [EMAIL PROTECTED]
Could you try the latest snapshot from http://snaps.php.net/
to see if this is fixed now?

--Jani

---

[2000-09-08 19:42:47] [EMAIL PROTECTED]
After forwarding the issue to a compiler expert at IBM, I received the fix below, 
which I've tested and confirmed. Does anyone know how best to implement this fix?

-
The point where you found the segment fault was when php_create_dir attempted to call 
ap_register_cleanup. As it happens, php_create_dir is in libphp4.so and 
ap_register_cleanup is in httpd. In order to make this work on AIX, httpd has to be 
bound with an export list and
libphp4.so has to be bound with an import list.

Fortunately, the Apache part is already set up correctly.  When you install apache on 
AIX, $PREFIX/libexec/httpd.exp is a correctly formatted import/export file.

The PHP4 part, however was not set up correctly. In fact it was set up in the worst 
possible way under the circumstances. If you were to attempt to naively bind 
libphp4.so, the linker would produce a fatal error because ap_register_cleanup is 
undefined. $PHP4/libtool (which
I believe is generated by configure) gets around this inconvenience by adding a 
-berrok linker option. (It's called ${allow_undefined_flag}) So, the linker on AIX 
basically leaves the reference to ap_register_cleanup untouched so the call branches 
to a pseudo-random piece of code. After that, bad things happen.

I'm running now because I manually changed $PHP4/libtool so that it contains these 
lines:

# Commands used to build and install a shared archive.
archive_cmds="$CC ${wl}-bM:SRE -o $objdir/$soname $libobjs $deplibs $linkopts 
${wl}-bexpall ${wl}-bI:/usr/local/apache/libexec/httpd.exp 
${wl}-bnoentry${allow_undefined_flag}"
archive_expsym_cmds="$CC ${wl}-bM:SRE -o $objdir/$soname $libobjs $deplibs $linkopts 
${wl}-bI:/usr/local/apache/libexec/httpd.exp ${wl}-bE:$export_symbols 
${wl}-bnoentry${allow_undefined_flag}"

The bit I added (in both lines) is:
${wl}-bI:/usr/local/apache/libexec/httpd.exp

I have no idea what the ${wl} is; I just copied the existing pattern. I hard coded 
/usr/local/apache/libexec/httpd.exp. Obviously, the real export file should be 
identifed using something like apxs, but I don't know how to do that.

At any rate, httpd has now been running for a while on my machine.

---

[2000-08-24 00:02:42] [EMAIL PROTECTED]
Here are the results from the latest version. The following have changed:

PHP 4-28230945

export CFLAGS="-g -ma"

./configure --enable-c9x-inline 
--enable-debug 
--prefix=/local/www/php 
--with-apxs=/local/www/bin/apxs 
--with-config-file-path=/local/www/php/etc 
--without-mysql

bud # ./httpd -X
Segmentation fault(coredump)

bud # dbx httpd
Type 'help' for help.
reading symbolic information ...
[using memory image in core]

Segmentation fault in php_save_umask at line 121 in file "" ($t1)
could not read "mod_php4.c"
(dbx) where   
php_save_umask(), line 121 in "mod_php4.c"
php_create_dir(p = 0x2001ef28, dummy = (nil)), line 556 in "mod_php4.c"
ap_single_module_configure(0x2001ef28, 0x2001ef50, 0x200b9db8), line 1500 in 
"http_config.c"
load_module(0x2ff22948, 0x0, 0x200432d0, 0x200432e0), line 282 in "mod_so.c"
invoke_cmd(0x2000f5e0, 0x2ff22948, 0x0, 0x2ff20920), line 818 in "http_config.c"
unnamed block $b14, line 1008 in "http_config.c"
ap_handle_command(0x2ff22948, 0x2001f480, 0x2ff208f0), line 1008 in "http_config.c"
unnamed block $b16, line 1022 in "http_config.c"
ap_srm_command_loop(0x2ff22948, 0x2001f480), line 1022 in "http_config.c"
ap_process_resource_config(0x2001ef50, 0x2001f608, 0x2001ef28, 0x20022f68), line 1202 
in "http_config.c"
ap_read_config(0x2001ef28, 0x20022f68, 0x200052a0), line 1481 in "http_config.c"
http_main.main(argc = 2, argv = 0x2ff22b3c), line 4955 in "http_main.c"
(dbx) quit

bud # gdb httpd
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.14 (rs6000-ibm-aix3.2.5), Copyright 1995 Free

[PHP-DEV] Bug #10516: Recursive patterns don't work

[martijn]

From: [EMAIL PROTECTED]
Operating system: Win2K & Linux
PHP version:  4.0.4pl1
PHP Bug Type: PCRE related
Bug description:  Recursive patterns don't work

$s = "a(b(c)d)e(f)g";
$p = "/\( ( ( (?>[^()]+) | (?R) )* ) \)/xU";
if (preg_match_all($p, $s, $x)) {
   echo "match";
   // see what's in $x
} else {
   echo "no match";
}


This example pattern is taken straigh out of the PCRE docs, but I don't get the 
desired result, whatever I try. I haven't been able to succesfully use the 
experimental (?R) so I was wondering if anyone ever has.

In perl, recursive patterns seem to work fine by the way.


Regards,
Martijn


-- 
Edit Bug report at: http://bugs.php.net/?id=10516&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] Fw: [PHP-DOC] cfunction?

[Andi Gutmans]

At 01:28 PM 4/26/2001 -0700, Rasmus Lerdorf wrote:
> > >Leave one, at least.  We want to know if this breaks.  At some point we
> > >will want to remove the feature from php, and then we can remove the test
> > >case.  But let's not remove testcases without removing the feature.  The
> > >test scripts are not meant as examples for users.
> >
> > It won't break and if it does, all the better :)
> > As you see people do take example from the test cases if they are meant to
> > be testcases or not.
>
>Yes, but the thing is there because there are scripts that use it.  If we
>break it, then these scripts will break.  Therefore a test case should
>remain so we don't break it.  If you are worried about the testcase
>setting a bad example, stick a comment in there.  You don't remove test
>cases for features just because you don't like them.  If it is part of the
>language, it needs to be part of the regression testing.

Check zend_language_scanner.l for cfunction and you'll see why there is 
about a zillion times more chances that someone will discover cfunction 
from the test scripts then there is for cfunction to break without regular 
functions breaking too. So I think we can take our chances on this one.
Come on, it's really bullshit and we should have nuked cfunction a while ago.
If you really feel strongly about it then go ahead and put one back 
although I think it's OK the way it is now.

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 #10516 Updated: Recursive patterns don't work

[andrei]

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

The results you get are consistent with (?R) description in PCRE docs. If you have a 
problem with that, contact the PCRE library author, please.

Previous Comments:
---

[2001-04-26 17:05:56] [EMAIL PROTECTED]
$s = "a(b(c)d)e(f)g";
$p = "/( ( ( (?>[^()]+) | (?R) )* ) )/xU";
if (preg_match_all($p, $s, $x)) {
   echo "match";
   // see what's in $x
} else {
   echo "no match";
}


This example pattern is taken straigh out of the PCRE docs, but I don't get the 
desired result, whatever I try. I haven't been able to succesfully use the 
experimental (?R) so I was wondering if anyone ever has.

In perl, recursive patterns seem to work fine by the way.


Regards,
Martijn

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10516&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] cfunction / old_function

[Sebastian Bergmann]

  Just curious, what are/were cfunction and old_function?

-- 
 sebastian bergmann[EMAIL PROTECTED]
   http://www.sebastian-bergmann.de

 bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de

-- 
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] cfunction / old_function

[Andi Gutmans]

In PHP/FI 2 functions weren't written like in PHP 3 & 4. Their style was 
something like:
function foo $a $b
(

)
We added the more C-like functions and called it cfunction. Then we decided 
that should be the default so function became old_function and cfunction 
became function.

Andi


At 11:16 PM 4/26/2001 +0200, Sebastian Bergmann wrote:
>   Just curious, what are/were cfunction and old_function?
>
>--
>  sebastian bergmann[EMAIL PROTECTED]
>http://www.sebastian-bergmann.de
>
>  bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de
>
>--
>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] cfunction / old_function

[Sebastian Bergmann]

Andi Gutmans wrote:
> We added the more C-like functions and called it cfunction. Then we 
> decided that should be the default so function became old_function 
> and cfunction became function.

  Ah, I see. Thanks.

-- 
 sebastian bergmann[EMAIL PROTECTED]
   http://www.sebastian-bergmann.de

 bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de

-- 
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 #10517: suggestion for ease of use

[johnadams78]

From: [EMAIL PROTECTED]
Operating system: all
PHP version:  4.0.4
PHP Bug Type: Feature/Change Request
Bug description:  suggestion for ease of use

like most programmers i'm lazy...  and hate wasting time looking for something.  so i 
have a suggestion that from my own experience i believe would save time.

section IV of the online maual..  the functions section..  many times you have to come 
back to this section to look up the syntax of a function..  but there are so many 
groups under this heading it's hard to find the one you're looking for.

why not add sub-headings to this section.  one for database related functions and the 
other for everything else.  ie.

IV. Function Reference
I.  Database Related
I.  Database (dbm-style) abstraction layer functions
II. dBase functions
III.MySQL Functions

II. Everything Else
I.  Apache-specific Functions
II. Array Functions



just a suggestion..  would narrow down the number of headings the eye would have to 
scan through..  and help make it easier to find stuff faster.




-- 
Edit Bug report at: http://bugs.php.net/?id=10517&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 #10517 Updated: suggestion for ease of use

[hholzgra]

ID: 10517
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Assigned
Bug Type: Feature/Change Request
PHP Version: 4.0.4
Assigned To: 
Comments:

have been trying to do so every once in a while,
but the docbook DTD won't really let me

looks like we are going to tweak DTD and 
stylesheets ab bit :(

Previous Comments:
---

[2001-04-26 17:36:28] [EMAIL PROTECTED]
like most programmers i'm lazy...  and hate wasting time looking for something.  so i 
have a suggestion that from my own experience i believe would save time.

section IV of the online maual..  the functions section..  many times you have to come 
back to this section to look up the syntax of a function..  but there are so many 
groups under this heading it's hard to find the one you're looking for.

why not add sub-headings to this section.  one for database related functions and the 
other for everything else.  ie.

IV. Function Reference
I.  Database Related
I.  Database (dbm-style) abstraction layer functions
II. dBase functions
III.MySQL Functions

II. Everything Else
I.  Apache-specific Functions
II. Array Functions



just a suggestion..  would narrow down the number of headings the eye would have to 
scan through..  and help make it easier to find stuff faster.



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10517&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: mcrypt_generic is padding input when using cfb and ofb modes

[kettler]

From: [EMAIL PROTECTED]
Operating system: Mandrake 7.2, Linux 2.2.19ow1
PHP version:  4.0.4pl1
PHP Bug Type: mcrypt related
Bug description:  mcrypt_generic is padding input when using cfb and ofb modes

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)."\n\n";
print bin2hex($crypted)."\n\n";


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);


-- 
Edit Bug report at: http://bugs.php.net/?id=10518&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] Fwd: Re: [PHP-INST] AIX

[Andi Gutmans]

Has this happened to anyone else on AIX?

Maybe the MySQL configure isn't doing something right. It should set a 
#define called HAVE_INT_8_16_32 but I don't seem to find a reference to it 
in any .m4.

Andi

>Date: Thu, 26 Apr 2001 17:22:14 -0500
>To: [EMAIL PROTECTED]
>From: Jacob Steinberger <[EMAIL PROTECTED]>
>Subject: Re: [PHP-INST] AIX
>
>Apache Configured with generic. Though I don't think that matters just yet.
>
>PHP Configured with:
>
>./configure --with-mysql --with-apache=/tmp/AIX/apache_1.3.19 
>--enable-track-vars
>
>I did not specify a path for MySql as I'm not sure if its happy with just 
>the client libs or if it wants the server.
>
>I'm still getting the same error with Gnu Make. The error is from the 
>"Making all in libmysql".
>
>In file included from libmysql.c:9:
>global.h:525: conflicting types for 'int8'
>/usr/include/sys/inttypes.h:622: previous delaration of 'int8'
>global.h:526: warning: redefinition of 'int16'
>/usr/include/sys/inttypes.h:623: warning: 'int16' previously declared here
>global.h:536: warning: redefinition of 'int32'
>/usr/include/sys/inttypes.h:624: warning: 'int32' previously declared here
>libmysql.c: In function 'connect2':
>libmysql.c:179: warning: passing arg 5 of 'getsockopt' from incompatible 
>pointer type
>
>After this, it just errors out and reports leaving directories.
>
>Oy!
>
>Jacob
>
>
>--
>PHP Install Mailing List (http://www.php.net/)
>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] xpath_eval causes Segmentation fault with ancestor::*

[Grishick]

I was trying the xpath expression like ancestor::* it always causes the
Segmentation error by PHP (both in Apache static moduel and stand-alone
executable).
But expressions like ancestor::para work fine. Only when I try to get all
the ancestors of the node PHP fails.
Does anyone has any idea?
Thanks.
Grishick.




-- 
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 #10258 Updated: ActiveX ASP pages on the same Web server seems not to work properly any more!

[sniper]

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



Previous Comments:
---

[2001-04-10 09:35:16] [EMAIL PROTECTED]


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10258&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: Open
Status: Assigned
Bug Type: mcrypt related
PHP Version: 4.0.4pl1
Assigned To: derick
Comments:

thx, will look into this soon

Previous Comments:
---

[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 #10519: $HTTP_COOKIE_VARS spoofing

[stuff]

From: [EMAIL PROTECTED]
Operating system: Win98
PHP version:  4.0.4pl1
PHP Bug Type: Variables related
Bug description:  $HTTP_COOKIE_VARS spoofing



If you access this page with the command line arguement 

?cookie[three]=three 

print_r will show cookie[three] in $HTTP_COOKIE_VARS.

Just a bit of incongrous material, but for some sites could cause problems if cookies 
are spoofed thusly.

Regards


-- 
Edit Bug report at: http://bugs.php.net/?id=10519&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 #10520: Access $HTTP_RAW_POST_DATA

[hunte]

From: [EMAIL PROTECTED]
Operating system: N/A
PHP version:  4.0.4pl1
PHP Bug Type: Feature/Change Request
Bug description:  Access $HTTP_RAW_POST_DATA

The variable $HTTP_RAW_POST_DATA should be accessed even if PHP can recongize the 
CONTENT_TYPE.

I'm writing a program to emulate web client(in fact, it's an proxy, like CGIProxy). 
The enduser sends requests to the program, the program opens HTTP connection to target 
server and gets the response from the server. There is no problem if enduser use GET 
method, but if the method is POST and many FORM elements have same name, the big 
program is raised.


-- 
Edit Bug report at: http://bugs.php.net/?id=10520&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] function table / hashes

[David Croft]

Thank you Andi and Andrei.

I have noticed that object method callbacks are consistently faster than
global function callbacks, and was wondering why:

1.3135770559311 seconds for 10 runs - with no function callback
6.9758139848709 seconds for 10 runs - with object method callback
7.9048730134964 seconds for 10 runs - with global function callback

This is somewhat strange for me as I would expect objects to be slower if
it has to look up the class and then locate the function table?

I'm exploring hashes now. I find code like this in php_imap.c:

if (zend_hash_find(Z_ARRVAL_PP(envelope), "remail",
sizeof("remail"), (void **) &pvalue)== SUCCESS) {
convert_to_string_ex(pvalue);
env->remail=cpystr(Z_STRVAL_PP(pvalue));
}

Is that legal? It seems that it would alter the original array by forcing
conversion to string.

Lastly, I am trying to see the difference between zend_hash_find and
zend_hash_quick_find. Would I be correct in assuming quick_find only looks
at string keys, and it would be safe to use this if the function expects
only associative arrays?

Thanks again!

David

-- 
|> /+\ \| | |>

David Croft
Infotrek
On Thu, 26 Apr 2001, Andi Gutmans wrote:

> At 02:16 PM 4/26/2001 -0400, David Croft wrote:
>
> >Hello, I'm implementing an extension that allows user callbacks.
> >
> >The Zend API document suggests using the Compiler globals to access the
> >function table. However I see the XML extension is using Executor globals.
>
> During execution the correct table to use is the executor globals one,
> i.e., EG(function_table).
>
> 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 #10521: Referencing a variable without setting its contents

[timl]

From: [EMAIL PROTECTED]
Operating system: Win2K Server
PHP version:  4.0.4pl1
PHP Bug Type: IIS related
Bug description:  Referencing a variable without setting its contents

The following script works in Apache but not in IIS



Apache treats the variable $test as a null variable but IIS throws a error:

Warning: undefined variable test in [script] in line 2

Depending on what follows, it will usually output something like what you were testing 
for/wanted except that it has the error in front of it.

This is with the standard PHP windows installer.  CGI version.


-- 
Edit Bug report at: http://bugs.php.net/?id=10521&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] PHP 4.0 Bug #9933 Updated: readdir doesn't work see Bug ID # 9058

[Larry . Schartman]

ID: 9933
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Directory function related
Description: readdir doesn't work  see Bug ID # 9058

Hi,

i think this is the problem (reentrancy.c)
int ret;

errno = 0;

ret = readdir_r(dirp, entry);

if (!ret || errno != 0) {


*result = NULL;
} else {
*result = entry;
}

return errno;

thr return value of readdir_r is 0 on success, so the above
will return NULL on success. The line should be something like

if (ret != 0 || errno != 0) {


   Thomas



Previous Comments:
---

[2001-03-22 11:59:49] [EMAIL PROTECTED]
Greetings,

I have unknowlingly followed the same path that Brian has in bug report # 9058.  
Namely, HP-UX 10.20, gcc version 2.95, PHP compiled many different ways but latley  - 
./configure --enable-libgcc --with-apxs=/usr/local/apache/bin/apxs
 --with-mysql=/usr/local/mysql --disable-posix
My application seems to work OK with the execption of no files listed from a readdir 
call.  The example code from readdir returns -
Directory handle: Resource id #1 Files:
and no file names.

Please let me know if there is anything I can do.

larry


---


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


-- 
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 #8994 Updated: socket_set_timeout works only once

[sterling]

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

Applied in CVS, don't know if it will make 4.0.5 this late
in the game.  Thanks!

Previous Comments:
---

[2001-03-22 04:11:22] [EMAIL PROTECTED]
please fix this issue for the final 4.0.5. It is not fixed 
in 4.0.5RC1. I think it's easy to fix.


---

[2001-03-22 04:11:20] [EMAIL PROTECTED]
please fix this issue for the final 4.0.5. It is not fixed 
in 4.0.5RC1. I think it's easy to fix.


---

[2001-01-30 05:36:45] [EMAIL PROTECTED]
socket_set_timeout() works only once. 
This is because the internal function php_sock_fgets() checks the timout flag before 
calling php_sockread_internal(). If blocking IO  php_sockwait_for_data() is called 
next. This function resets the socket timeout flag.

A possible solution is to reset the flag in php_sockset_timeout() like the following 
patch. Removing the timeout flag test from php_sock_fgets() is also possible maybe.

diff -c /usr/src/packages/BUILD/php-4.0.4pl1/ext/standard/fsock.c-orig 
/usr/src/packages/BUILD/php-4.0.4pl1/ext/standard/fsock.c
*** /usr/src/packages/BUILD/php-4.0.4pl1/ext/standard/fsock.c-orig  Tue Jan 30 
11:19:59 2001
--- /usr/src/packages/BUILD/php-4.0.4pl1/ext/standard/fsock.c   Tue Jan 30 11:19:59 
2001
***
*** 596,601 
--- 596,602 
SOCK_FIND(sock, socket);
  
sock->timeout = *timeout;
+   sock->timeout_event = 0;
  }
  
  #define SOCK_FIND_AND_READ_MAX(max) 


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8994&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 #10511: Cannot set COM object properties

[peter . johnson]

From: [EMAIL PROTECTED]
Operating system: Windows 2K
PHP version:  4.0.4pl1
PHP Bug Type: COM related
Bug description:  Cannot set COM object properties

I am accessing ADO COM objects through PHP.  I am using PHP 4.05 RC6 on Win2K in CGI 
mode.  If I change the authentication from anonymous access, to requiring a login 
through basic authentication, then the scripts fail and cannot set properties on the 
COM object.  The same scripts work fine when run as the anonymous user.  Very weird...

Thanks in advance for any help

Cheers
Peter


-- 
Edit Bug report at: http://bugs.php.net/?id=10511&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.5: Merge Request

[Sterling Hughes]

On Thu, 26 Apr 2001, Jani Taskinen wrote:

> On Tue, 24 Apr 2001, Sterling Hughes wrote:
>
> >I think its not a bad idea to encourage (even more :) bug fixing for the
> >next release, but I don't think restricting valuable and/or needed
> >features is a good idea.
>
> You're just lazy. :)

I really don't see that in my statement.  I'm saying is that going
gung-ho at fixing bugs is great, but I don't see any reason to reject
work because it is a feature rather than a bug fix.

> There are these 'bugs' with type 'Feature/Change request'... so?
>

There not really "bugs" in the terms that I think everyone else is
referring to a bug as.  Its just convient to place these in the bugs db.

-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] Bug #10510 Updated: ini_set() as relates to max upload filesize setting

[bbonev]

ID: 10510
Updated by: bbonev
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Function Specific
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

Please take into account that the processing of post data happens _before_ your call 
to ini_set. Thus your new limit value has no effect to the upload and succeeds (of 
course) after the upload is rejected.

I would recommend setting the value through .htaccess or apache's config.


Previous Comments:
---

[2001-04-26 09:58:38] [EMAIL PROTECTED]
First, let me say that I'm not entirely sure I would class this report as a bug, but 
it very well could be.

Recently, as in yesterday, I spent a number of hours trying to find a work-around to 
the maximum upload filesize setting.  I came across the ini_set() functions.

This appeared to be something of a solution to the delimma, by issuing a ini_set() to 
the max upload filesize, I figured I would be able to conduct a file upload that 
exceeded the default 2M limit.

It would appear that I was wrong.

Here is the situation which presented itself, and ultimately will explain why I'm 
emailing as a bug report.

 The Scenario -
My script resides on a "hosted" server, one which is beyond my direct control.  
Naturally the host controls the settings, and the like.

I needed to conduct file uploads, which may or may not exceed the default limit.  
After reviewing the manual, I found the ini_set functions. So, I decided to test the 
over-ride of the ini's setting for a max upload filesize.

For test purposes, we chose 4M, and issued an ini_set() to PHP. The set was 
successful, and our local value for the max upload filesize was 4M.

No problem, this is awesome I thought to myself, so we moved forward and attempted to 
upload, using a "file" field named file_url.

The end result was just un-real.

We selected a file that weighed in at approx. 2.2MB just .2 over the default limit, 
but well within our defined max size.

We watched our modems and bandwidth meters, seeing the transmit of the file to the 
server... (we think all is going sweetly).. then, nothing.

PHP gave no errors, as a matter of fact the script executed perfectly.  cept that the 
value of file_url became "none".. obviously something went wrong.. 

Here's what we ultimately discovered.

1) "IF" the file exceeded 2M (the default) the value of the file field is stripped and 
returns as "none" (as if no file was uploaded).

2) PHP Gives no "limit exceeded" error, or any errors for that matter.

3) "IF" the file is below the 2M limit, all is perfect.

In short, it would appear that the ini_set(), though it displays as being set, has no 
real affect.  Bug? I don't know.. I do however feel, that at the very least, PHP 
should give us some type of error message.. In the end, I'm left with the feeling that 
one of two possiblities exist here, 1) the ini_set() function holds no real coding 
value, or 2) I don't fully understand the function.  Granted, documentation is 
somewhat limited on these..

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10510&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]