Re: [PHP-DEV] Compile error (multiple compilations)

2001-01-12 Thread Wico de Leeuw

Hiya

gcc -c  -I../../os/unix -I../../include   -DLINUX=2 
-I/home/src/php-4.0.4pl1 -I/home/src/php-4.0.4pl1/main 
-I/home/src/php-4.0.4pl1/main -I/home/src/php-4.0.4pl1/Zend 
-I/home/src/php-4.0.4pl1/Zend -I/home/src/php-4.0.4pl1/TSRM 
-I/home/src/php-4.0.4pl1/TSRM -I/home/src/php-4.0.4pl1 -DUSE_EXPAT 
-I../../lib/expat-lite -DNO_DL_NEEDED -Os -O6 -march=pentium `../../apaci` 
-DAPACHE xmltok.c
In file included from xmltok.c:260:
xmltok_impl.c: In function `normal_getAtts':
xmltok_impl.c:1478: Internal compiler error in `do_spl', at loop.c:12473

changing -O6 to -O3 works



At 11:15 12-1-01 +0100, Wico de Leeuw wrote:
Hiya

when changing:
/bin/sh ../libtool --silent --mode=compile /home/src/php-4.0.4pl1/meta_cc 
-DHAVE_CONFIG_H -I. -I. -I../main   s -O6 -march=pentium  -c ./zend_execute.c

to:

/bin/sh ../libtool --silent --mode=compile /home/src/php-4.0.4pl1/meta_cc 
-DHAVE_CONFIG_H -I. -I. -I../main   -Os -O6 -march=pentium  -c ./zend_execute.c


and run make again everything is fine

Greetz,

Wicp


At 10:54 12-1-01 +0100, Wico de Leeuw wrote:
Hiya

when compiling php-4.0.4pl1

my CFLAGS AND CXXFLAGS are: "-Os -O6 -march=pentium"
using pgcc-2.95.2.1 linux rehat 6.2

i get this error when compiling php:

/bin/sh ../libtool --silent --mode=compile /home/src/php-4.0.4pl1/meta_cc 
-DHAVE_CONFIG_H -I. -I. -I../main -Os -O6 -march=pentium -c 
zend_constants.c
/bin/sh ../libtool --silent --mode=compile /home/src/php-4.0.4pl1/meta_cc 
-DHAVE_CONFIG_H -I. -I. -I../main -Os -O6 -march=pentium -c 
zend_dynamic_array.c
/bin/sh ../libtool --silent --mode=compile /home/src/php-4.0.4pl1/meta_cc 
-DHAVE_CONFIG_H -I. -I. -I../main   s -O6 -march=pentium  -c ./zend_execute.c
gcc: cannot specify -o with -c or -S and multiple compilations
make[1]: *** [zend_execute.lo] Error 1
make[1]: Leaving directory `/home/src/php-4.0.4pl1/Zend'
make: *** [all-recursive] Error 1
[root@linux src]#

Look like it strips off the -O and forgets the rest

Greetz,

Wico


--
PHP Development 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 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 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-DEV] PHP 4.0 Bug #5814 Updated: ODBC connection to Oracle fails

2001-01-12 Thread fsegtrop

ID: 5814
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: ODBC related
Description: ODBC connection to Oracle fails

After changing the server OS to Windows 2000 SP1, using IIS 5.0 instead of Apache and 
PHP 4.0.3, the error did not occur any more.
However, we did not examine exactly what did solve the problem, the new OS, the IIS or 
the new PHP version.

When I have time, I will examine this further, at the moment, I am just glad to have a 
working solution.

Thanks!

Previous Comments:
---

[2001-01-11 17:09:33] [EMAIL PROTECTED]
did you encounter this bug in later (preferrably 4.0.4) versions of PHP?

---

[2000-07-28 21:38:16] [EMAIL PROTECTED]
Just an addition:

The same bug occurs using Windows98 and Apache Web Server. The connection to Oracle 
via ODBC works with php3 and other ODBC-clients and fails with php4, where TNS cannot 
resolve the Oracle alias.

Regards,
Frank

---

[2000-07-28 16:09:21] [EMAIL PROTECTED]
This is the c function that works, and it shows no big difference to the 
odbc_sqlconnect function used by php4:


void myodbcconnect()
{
int rc;
SQLHANDLE henv,hdbc;


SQLAllocEnv(henv);
SQLAllocConnect(henv, hdbc);


rc = SQLConnect(hdbc,(unsigned char*)dsn,strlen(dsn),(unsigned 
char*)uid,strlen(uid),(unsigned char*)pwd,strlen(pwd));


if (rc != SQL_SUCCESS  rc != SQL_SUCCESS_WITH_INFO) {
MessageBox(hWnd,"","Fehler",IDOK);
SQLFreeConnect(hdbc);

}
else
MessageBox(hWnd,"OK","",IDOK);

}


---

[2000-07-28 14:06:42] [EMAIL PROTECTED]
No, both php3 and php4 run as CGI, and with the same user. Also, everyone has full 
access to the tnsnames.ora.

I have configured Apache the way that scripts ending with .php4 are executed by php4 
and scripts ending with .php3 by php3. A script, run as "test.php4" fails, the same 
run as "test.php3" succeeds. Everything runs as CGI, not as Apache module.

I have written a small test-program with C, and there the connection using SQLConnect 
works, as well as with php3. Somehow, in php4 the same function call (SQLConnect) 
returns SQL_ERROR.

In php3 and my test-program, SQLConnect finds the missing parameters DBQ and ASY from 
the ODBC-driver and can resolve the DBQ setting, in php4 it also finds the DBQ and ASY 
parameters, but cannot resolve the DBQ, though there is no obvious difference in the 
environment (same users, same machine, same browser). Anyhow, the php_odbc.c source 
does not show me any hint why this behaviour occurs, and it appears to be a different 
environment, but then the same occurs on different machines. Always, php3 works, php4 
does not work, other ODBC-clients work. 

One idea is: in php3, the SQLConnect runs from the exe, in php4 from a dll (even in 
the CGI-version), and the TNS-resolution does not work there?
That's the only difference I have found so far.

If i Find more, I'll update this report.

Best regards,
Frank

---

[2000-07-28 09:06:30] [EMAIL PROTECTED]
There must be something different in the environment between php3 and php4. 
The oracle error you're getting implies that the oracle libs aren't able to find 
tnsnames.ora.
Maybe you are running php3 as cgi and php4 as ISAPI?
Or do you have a different user executing the scripts? 

---

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

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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #8632 Updated: Error Message

2001-01-12 Thread cynic

ID: 8632
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Unknown/Other Function
Assigned To: 
Comments:

is this really the shortest possible script? wouldn't something shorter reproduce the 
bug too? it's quite lengthy, and the easier you make it for developers to locate the 
bug, the sooner it'll get fixed. 

Previous Comments:
---

[2001-01-10 08:27:12] [EMAIL PROTECTED]
IIS 5 

---

[2001-01-10 08:26:20] [EMAIL PROTECTED]
its only with the ISAPI !!

---

[2001-01-10 08:03:00] [EMAIL PROTECTED]
please, provide the shortest possible script reproducing the behavior. 
is it CGI version of PHP or SAPI version?
also, what web server do you use? 

---

[2001-01-10 07:48:39] [EMAIL PROTECTED]
This Error Message is displayed:

PHP has encountered an Access Violation at 011A527B

Script:
?php

/*

  File: browse.php
  Author: Chris
  Date: 2000/12/14

  Owl: Copyright Chris Vincent [EMAIL PROTECTED]

  You should have received a copy of the GNU Public
  License along with this package; if not, write to the
  Free Software Foundation, Inc., 59 Temple Place - Suite 330,
  Boston, MA 02111-1307, USA.

*/

require("./config/owl.php");
require("./config/html.php");
require("./lib/owl.lib");
require("./lib/security.lib");
include("./lib/header.inc");

if(!$parent) $parent = "1";
if(!$expand) $expand = "0";
if(!$order) $order = "name";

if(check_auth($parent, "folder_view", $userid) != "1") {
print($lang_nofolderaccess);
exit;
}

if ($expand == 1) {
print("ttTABLE WIDTH=90%n");
} else {
print("ttTABLE WIDTH=50%n");
}

// **FM**
print("tttTRTD" . $lang_currentdir . "/TD/TR");
print("tttTRTD bgcolor="#d0d0d0"" . gen_navbar($parent) . "/TD/TR/TABLE");
//print("tttTRTD" . gen_navbar($parent) . "/TD/TR/TABLE");

if ($expand == 1) {
print("ttHR WIDTH=90%n");
} else {
print("ttHR WIDTH=50%n");
}

if ($expand==1) print("TABLE WIDTH=90% BORDER='$default-table_border'");
if ($expand==0) print("TABLE WIDTH=50% BORDER='$default-table_border'");

print("TRTD ALIGN=LEFT WIDTH=50%A

HREF='modify.php?sess=$sessaction=folder_createparent=$parentexpand=$expand'
$lang_addfolder/Anbsp;");
print("A 
HREF='modify.php?sess=$sessaction=file_uploadparent=$parentexpand=$expand'
$lang_addfile/Anbsp;nbsp;");
if($expand==1) {
print("A HREF='browse.php?sess=$sessparent=$parentexpand=0order=$order'IMG SRC=

tt'$default-owl_root_url/locale/$default-owl_lang/graphics/btn_collapse_view.gif'
ttBORDER=0/A");
} else {
print("tttA HREF='browse.php?sess=$sessparent=$parentexpand=1order=$order'IMG 
SRC=

tt'$default-owl_root_url/locale/$default-owl_lang/graphics/btn_expand_view.gif'
ttBORDER=0/Anbsp;nbsp;n");
}

print("/TDTD ALIGN=RIGHT WIDTH=50%A 
HREF='index.php?login=logoutsess=$sess'$lang_logout/A/TD/TR/TABLE");

if ($expand == 1) {
print("tttTABLE WIDTH=90%TR BGCOLOR='$default-table_header_bg'TD
A 
HREF='browse.php?sess=$sessexpand=$expandparent=$parentorder=name' 
STYLE='toplink'$lang_title/A/TD
TDA 
HREF='browse.php?sess=$sessexpand=$expandparent=$parentorder=filename'$lang_file/A/TD

TDA 
HREF='browse.php?sess=$sessexpand=$expandparent=$parentorder=size'$lang_size/A/TD

TDA 
HREF='browse.php?sess=$sessexpand=$expandparent=$parentorder=creatorid'$lang_postedby/A/TD

TDA 
HREF='browse.php?sess=$sessexpand=$expandparent=$parentorder=modified'$lang_modified/A/TD

TD$lang_actions/TD/TR");
} else {
print("tttTABLE WIDTH=50%TR BGCOLOR='$default-table_header_bg'TD
A 
HREF='browse.php?sess=$sessexpand=$expandparent=$parentorder=name' 
STYLE='toplink'$lang_title/A/TD
TDA 
HREF='browse.php?expand=$expandparent=$parentorder=filename'$lang_file/A/TD
TDA 
HREF='browse.php?expand=$expandparent=$parentorder=size'$lang_size/A/TD/TR");
}

$sql = new Owl_DB;
if ($order == "creatorid") {
$sql-query("select * from $default-owl_folders_table where parent = 
'$parent' order by $order");
} else {
$sql-query("select * from $default-owl_folders_table where parent = 
'$parent' order by name");
}

while($sql-next_record()) {
print("TR BGCOLOR='$default-table_cell_bg'TDA 
HREF='browse.php?sess=$sessparent=" . $sql-f("id") . 
"expand=$expandorder=$order'IMG SRC='

$default-owl_root_url/locale/$default-owl_lang/graphics/icons/folder_closed.gif' 
BORDER=0
" . $sql-f("name") . "

[PHP-DEV] PHP 4.0 Bug #8046 Updated: upload is not working

2001-01-12 Thread cynic

ID: 8046
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Filesystem function related
Assigned To: 
Comments:

It Works For Me(tm) with latest snapshot from CVS. try 4.0.4pl1, and if it's the same, 
reopen this report.

Previous Comments:
---

[2000-11-30 04:15:39] [EMAIL PROTECTED]
The normal file upload process is not working
with PHP403pl1 when using it as a CGI app.

print_r($userfile);

prints out the file info, but the size
is zero, and the temp filename is null.

---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #7202 Updated: Problem running PHP

2001-01-12 Thread cynic

ID: 7202
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: PWS related
Assigned To: 
Comments:

err, should've probably been $HTTP_POST_VARS['username']

Previous Comments:
---

[2001-01-12 07:40:54] [EMAIL PROTECTED]
if you used php.ini-optimized, the variable will be in $HTTP_GET_VARS['username']. if 
this doesn't help, reopen the bug report, and append a short script reproducing the 
behavior.

---

[2000-10-14 00:43:15] [EMAIL PROTECTED]
I have just installed the PHP403 version on my machine.The PHP4isapi.dll is in 
d:PHP403sapi.Under the PWS configuration Console,I have configured the php4isapi.dll 
to service files with .php extension.Then I tried the Userform.html sample that posts 
the user name to a processform.php page and displays the username.

The problem is that the $username is always blank... (username is the name of the 
input box in userform.html)

---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #7406 Updated: Unable to load Dbase extension

2001-01-12 Thread cynic

ID: 7406
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: dBase related
Assigned To: 
Comments:

have you tried a newer version since then? did it work? if not, what were the settings 
in your php.ini, and where did the dll actually live on your system?

Previous Comments:
---

[2000-10-23 07:10:18] [EMAIL PROTECTED]
I seem to be unable to load the dbase dll, can you tell me if is functioning and if so 
what settings I should change?


---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #8674: invallid filetype() results (affects isdir() )

2001-01-12 Thread yavo

From: [EMAIL PROTECTED]
Operating system: redhat 6.2
PHP version:  4.0.4
PHP Bug Type: Filesystem function related
Bug description:  invallid filetype() results (affects isdir() )

im using php for shell scripting in redhat 6.2. compiled with 
'./configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-oci8=/usr/local/oracle'

trying to get the filetype files returns null for all entries exsept . and .. . 

-- code snippet -- 
  $dp = opendir($dir);
  if($dp){
while (($file = readdir($dp))!== false) {
  // Skip . and .. and check for type
  // tried with this on and both here and at the start
  clearstatcache();
  print($file." - ".filetype($file)."\n");
 
  if(($file != ".")  ($file != "..")  (filetype($file) == $type)){
$files[] = $file;
  }
}//while
return($files);
  }//if
  else{
debug("The directory [$dir] was not found or couldn't be opened");
write_log("The directory [$dir] was not found or couldn't be opened");
return(0);
  }
-- end of snippet -


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



-- 
PHP Development 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-DEV] Bug Tracking

2001-01-12 Thread Marc DAUMAS



I would like to thank you for your quick response to my bug request.
I successfully compiled PHP4.04 whith snmp support now even if I had to install
openssl.0.9.6 before it works.
PHP is a powerful and wonderful language.
Keep doing good job like that !!
Best regards for all the team.



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




RE: [PHP-DEV] PHP 4.0 Bug #8674: invallid filetype() results (affects isdir() )

2001-01-12 Thread Sean R. Bright

Thats because you need to pass a valid filename to filetype().  PHP is
trying to find $file in its current directory even if $dir is
/usr/local/not/phps/current/dir.  I have fixed your example below.  (Note
that this still won't work if the last character of $dir is not a '/', so
append one where necessary)

(I think this bug can be closed also.)

Sean
==
Sean Bright
[EMAIL PROTECTED] / [EMAIL PROTECTED]
==

   ...
   // tried with this on and both here and at the start
   clearstatcache();

// UPDATED : Try this
print($file." - ".filetype($dir . $file)."\n"); // Notice the
concatenation.

   if(($file != ".")  ($file != "..") 
   ...


-- 
PHP Development 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-DEV] PHP 4.0 Bug #7822 Updated: system crash

2001-01-12 Thread cynic

ID: 7822
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache related
Assigned To: 
Comments:

indeed. a temporary workaround, if I may:

LocationMatch "/php/php(\.exe)?"
deny from all
/LocationMatch

This at least denies direct access to the executable, and thus gets you rid of the 
crashes.

Previous Comments:
---

[2001-01-08 02:32:47] [EMAIL PROTECTED]
In 4.0.4, This bug still exists.

(Win32, php.ini) Conditions for this bug:
safe_mode=Off
doc_root=; the root of the php pages, used only if nonempty
(doc_root is empty)

In such configured PHP, system will crash if I type the URL:
http://localhost/php/php.exe
(Note: no "/" at the end of the URL)

I may consult the source code if I have time later.

---

[2001-01-06 02:29:03] [EMAIL PROTECTED]
does this problem exist in PHP 4.0.4

---

[2000-11-14 19:06:55] [EMAIL PROTECTED]
I config PHP for Apache 1.3.14 for Win32 as almost all people do: in apache 
configuation file:

ScriptAlias /php/ "C:/Program Files/PHP/"
Directory "C:/Program Files/PHP/"
AllowOverride None
Options None
/Directory
AddType application/x-httpd-php .php
Action application/x-httpd-php "/php/php.exe"

All the things go well and apache is able to process .php files. However, I type: 
http://localhost/php/php.exe, then my system crashes... Windows says that php.exe: 
program error.


---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #8674 Updated: invallid filetype() results (affects isdir() )

2001-01-12 Thread cynic

ID: 8674
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Filesystem function related
Assigned To: 
Comments:

a user error

Previous Comments:
---

[2001-01-12 09:58:24] [EMAIL PROTECTED]
im using php for shell scripting in redhat 6.2. compiled with 
'./configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-oci8=/usr/local/oracle'

trying to get the filetype files returns null for all entries exsept . and .. . 

-- code snippet -- 
  $dp = opendir($dir);
  if($dp){
while (($file = readdir($dp))!== false) {
  // Skip . and .. and check for type
  // tried with this on and both here and at the start
  clearstatcache();
  print($file." - ".filetype($file)."n");
 
  if(($file != ".")  ($file != "..")  (filetype($file) == $type)){
$files[] = $file;
  }
}//while
return($files);
  }//if
  else{
debug("The directory [$dir] was not found or couldn't be opened");
write_log("The directory [$dir] was not found or couldn't be opened");
return(0);
  }
-- end of snippet -

---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #8120 Updated: mysql_list_fields() returns no result

2001-01-12 Thread cynic

ID: 8120
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: MySQL related
Assigned To: 
Comments:

It might be mysql_field_name() would actually work if you had correct number of 
arguments in the mysql_connect() call. Seems like your error_reporting is too low, or 
display_errors is off, otherwise you'd know it.

it works for me with mod_php4 built from today's CVS, MySQL 3.23.27, and Apache 
1.3.15-dev:

$link = mysql_connect( 'localhost' , 'root', 'xxx' );
$result = mysql_list_fields( 'mysql' , 'host' , $link);
print "Result is: $result\n\n";
$num = mysql_num_fields($result);
for($i=0;$i$num;$i++) {
$name = mysql_field_name($result,$i);
$type = mysql_field_type($result,$i);
echo "$name: $type\n";
}


output:

Result is: Resource id #2

Host: string
Db: string
Select_priv: string
Insert_priv: string
Update_priv: string
Delete_priv: string
Create_priv: string
Drop_priv: string
Grant_priv: string
References_priv: string
Index_priv: string
Alter_priv: string

If you still encounter this error with newer versions of PHP and/or MySQL, reopen this 
bug report, please.

Previous Comments:
---

[2000-12-05 11:14:02] [EMAIL PROTECTED]
I tried using the code snippet in bug #5750 but couldn't get any results:

$link = mysql_connect($dbserver,$database, 'root', 'mypwd');
$result = mysql_list_fields($database,"meta", $link);
print "nResult is :".$result;
$num = mysql_num_fields($result);
for($i=0;$i$num;$i++) {
$name = mysql_field_name($result,$i);
$type = mysql_field_type($result,$i);
echo "$name $typen";

$result is always undefined.

I'm using Windows2000, MySQL 3.23.24-beta, and Apache.  I know the database exists and 
the table "meta" exists because they are used in many other pages for DHTML 
generation.

Thanks
Dave

---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #8554 Updated: ob_gzhandler

2001-01-12 Thread cecot

ID: 8554
User Update by: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Reproduceable crash
Description: ob_gzhandler

well in php4.0.4pl1 this problem seems to disappear
output_handler = ob_gzhandler works fine (even compresses the output :))

Previous Comments:
---

[2001-01-04 11:58:10] [EMAIL PROTECTED]
when I tried the example of Zeev Suraski at 
http://www.zend.com/zend/art/buffering.php, with the php.ini directive output_handler 
= ob_gzhandler it caused Segmentation fault of the apache.
I tried to use ob_start("ob_gzhandler"); and again segmentation fault ...

here are some tests
$test = ob_gzhandler("test") makes unpredictable results;
$test = gzencode("test") work fine (it even compress the text);
ob_start("gzencode") end with segfault again;

this happend on two different machines (both with debian) but one with a precompiled 
php debian package the other php compiled from me. both are compiled --with-zlib

phpinfo() gives this

zlib
ZLib Support enabled 
'zlib:' fopen wrapper enabled 
Compiled Version 1.1.3 
Linked Version 1.1.3 


---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #8675: ora-01005 when accessing remote SDI (follow-up to bug 8673)

2001-01-12 Thread christoph . hofstetter

From: [EMAIL PROTECTED]
Operating system: aix433
PHP version:  4.0.4
PHP Bug Type: Oracle related
Bug description:  ora-01005 when accessing remote SDI (follow-up to bug 8673)

I found a workaround for the ora-01034 problem: I specify the SID as the third 
argument to OCILogin.
Now I get ora-01005 (no password given). 

this only happens when accessing a remote db!


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



-- 
PHP Development 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-DEV] PHP 4.0 Bug #5181 Updated: 'No input file specified' error in CGI mode / location of bugs in code

2001-01-12 Thread sniper

ID: 5181
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Suspended
Status: Closed
Old-Bug Type: Installation problem
Bug Type: *General Issues
Assigned To: 
Comments:

This should be fixed now. Please try PHP 4.0.4pl1.

--Jani

Previous Comments:
---

[2000-08-02 12:13:24] [EMAIL PROTECTED]
please wait, none of the suggested changes
seem to be applied ... lets just suspend it for now

---

[2000-08-01 22:59:35] [EMAIL PROTECTED]
no feedback, closed

---

[2000-06-28 05:06:55] [EMAIL PROTECTED]
Please chekc the latest version - does it work now?

---

[2000-06-21 23:09:29] [EMAIL PROTECTED]
As others have reported, setting --enable-discard-path does not allow PHP to run 
properly in CGI mode.  This simple script will fail when hit through a Web server:

#!/usr/local/bin/php

?php echo "Hello, world."; ?

producing a "No input file specified" error.

There seem to be three bugs in the file sapi/cgi/cgi_main.c that cause this.  (At 
least, when I fixed these things, it worked).  I'll now reveal what is probably my 
ignorance of the code by pointing them out.

The problems are all in the init_request_info() function.  Specifically,

1.  ~Line 252.  script_filename is set to getenv("SCRIPT_FILENAME") rather than 
getenv("SCRIPT_NAME").  Maybe SCRIPT_FILENAME is a newer variant I haven't heard of, 
but our servers have always used SCRIPT_NAME.

2.  ~Line 278.  If DISCARD_PATH is set and script_filename is available, 
SG(request_info).path_translated should be set to the concatenation of 
getenv("DOCUMENT_ROOT") and script_filename, not just script_filename.  Otherwise, 
when php_fopen_primary_script() tries to open it it will bomb, because it doesn't have 
the full path.

3.  ~Line 290.  For some reason, irrespective of the previous DISCARD_PATH section, 
SG(request_info).path_translated is set to NULL.  This will clobber the script name 
when discard path is enabled.  As far as I can tell this line should simply be 
removed.


Hope that's useful to someone. :) 


---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #5315 Updated: --with-gdbm=blahblah not complete

2001-01-12 Thread sniper

ID: 5315
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Duplicate
Status: Closed
Old-Bug Type: Installation problem
Bug Type: *General Issues
Assigned To: 
Comments:

This is fixed. Try PHP 4.0.4pl1.

--Jani

Previous Comments:
---

[2000-08-17 05:39:04] [EMAIL PROTECTED]
Same as #5238.

( Might be quite trivial to fix this..rasmus??)

--Jani

---

[2000-07-27 20:11:41] [EMAIL PROTECTED]
checking out

---

[2000-07-01 20:29:24] [EMAIL PROTECTED]
In my environment I have a completely empty /usr/local.
Hence I must specify an override for locations of many
things. Specifying a --with-gdbm= path does not get
past ./configure. At about line 9816 in ./configure you
can see the script checks several paths for gdbm.h, 
but it never checks the path I provided with --with-gdbm

I have circumvented this manually by editting ./configure.

This bug has been in all the PHP 4* releases as far as I 
know (and probably before that too).

Low priority, but irritating (for me alone, I suspect :-)


---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #6559 Updated: yp_first() and yp_next() results handled wrong in ext/yp/yp.c

2001-01-12 Thread sniper

ID: 6559
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Open
Old-Bug Type: NIS related
Bug Type: YP/NIS related
Assigned To: 
Comments:



Previous Comments:
---

[2000-09-05 14:31:58] [EMAIL PROTECTED]
The key/value pairs that libnsl's yp_first/yp_next return contain
a trailing NEWLINE as per NIS specs. These NEWLINEs are
not chopped off before returning the key/value pair to the users's PHP
code. Hence you end up with newlines in PHP hashes.

Below is the context diff for the fix.

regards,
Gert

*** yp.c.orig   Mon Jun  5 21:47:45 2000
--- yp.cTue Sep  5 19:37:54 2000
***
*** 151,156 
--- 151,158 
RETURN_FALSE;
}
array_init(return_value);
+   outkey[outkeylen] = 0;
+   outval[outvallen] = 0;
add_assoc_string(return_value,"key",outkey,1);
add_assoc_string(return_value,"value",outval,1);
  }
***
*** 175,180 
--- 177,184 
RETURN_FALSE;
}
  
+   outkey[outkeylen] = 0;
+   outval[outvallen] = 0;
array_init(return_value);
add_assoc_string(return_value,outkey,outval,1);
  }


---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #8677: dbase module built with phpize doesn't work.

2001-01-12 Thread phpbug

From: [EMAIL PROTECTED]
Operating system: Debian GNU/Linux (woody)
PHP version:  4.0.4
PHP Bug Type: dBase related
Bug description:  dbase module built with phpize doesn't work.

dbase module built with:
mkdir dbase; cp _php_source/ext/dbase/* dbase/;
cd dbase; phpize; configure --enable-dbase; make; make install;
doesn't work and php complains that:
PHP Warning:  Invalid library (maybe not a PHP library) 'dbase.so'  in Unknown on line 0



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



-- 
PHP Development 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-DEV] PHP 4.0 Bug #8678: microtime() does not work very well

2001-01-12 Thread nevries

From: [EMAIL PROTECTED]
Operating system: Windows ME
PHP version:  4.0.4
PHP Bug Type: Date/time related
Bug description:  microtime() does not work very well

Under Windows ME microtime() does not work very well. 

Example output: 
979317843.96524 
979317843.9754 
979317843.98553 
979317843.99569 
979317843.9  
979317843.01011 
979317843.0202 
979317843.03033 
979317843.04045 
979317843.05056 
979317843.06069 
979317843.07079 
979317843.08082 
979317843.09089 
979317843.10126 
979317844.10589  
979317844.11597 
979317844.13162 
979317844.14164 
979317844.1518 
979317844.16193 

It is almost as if 2 completely different clocks are used.


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



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




Re: [PHP-DEV] PHP 4.0 Bug #8667 Updated: sockets

2001-01-12 Thread Jon Parise

On Fri, Jan 12, 2001 at 05:47:20PM +0200, Jani Taskinen wrote:

 Nope. I can reproduce this with latest CVS in Solaris 8.. BUT only
 when using GCC. With the Sun CC it works fine.
 
 So this bug report should be re-opened.

Well, the bug displayed errors that I fixed under Sun CC.  What you
have here are different errors with GCC, so that should be filed as a
separate bug.

 Here's what I get with latest CVS when using GCC 2.95.2:
 
 safe_mode.c: In function `php_checkuid':
 safe_mode.c:127: warning: passing arg 2 of `zend_hash_exists' discards
 qualifiers from pointer target type
 sockets.c:118: `php_if___xnet_listen' undeclared here (not in a function)
 sockets.c:118: initializer element is not constant
 sockets.c:118: (near initialization for `sockets_functions[10].handler')
 sockets.c:139: `php_if___xnet_socket' undeclared here (not in a function)
 sockets.c:139: initializer element is not constant
 sockets.c:139: (near initialization for `sockets_functions[16].handler')
 sockets.c:140: `php_if___xnet_connect' undeclared here (not in a function)
 sockets.c:140: initializer element is not constant
 sockets.c:140: (near initialization for `sockets_functions[17].handler')
 sockets.c:142: `php_if___xnet_bind' undeclared here (not in a function)
 sockets.c:142: initializer element is not constant
 sockets.c:142: (near initialization for `sockets_functions[19].handler')
 sockets.c:146: `php_if___xnet_sendto' undeclared here (not in a function)
 sockets.c:146: initializer element is not constant
 sockets.c:146: (near initialization for `sockets_functions[23].handler')
 sockets.c:153: `php_if___xnet_recvmsg' undeclared here (not in a function)
 sockets.c:153: initializer element is not constant
 sockets.c:153: (near initialization for `sockets_functions[30].handler')
 sockets.c:154: `php_if___xnet_sendmsg' undeclared here (not in a function)
 sockets.c:154: initializer element is not constant
 sockets.c:154: (near initialization for `sockets_functions[31].handler')
 sockets.c:157: `php_if___xnet_getsockopt' undeclared here (not in a
 function)
 sockets.c:157: initializer element is not constant
 sockets.c:157: (near initialization for `sockets_functions[34].handler')
 sockets.c:159: `php_if___xnet_socketpair' undeclared here (not in a
 function)
 sockets.c:159: initializer element is not constant
 sockets.c:159: (near initialization for `sockets_functions[36].handler')
 make[3]: *** [sockets.lo] Error 1
 make[2]: *** [all-recursive] Error 1
 make[1]: *** [all-recursive] Error 1
 make: *** [all-recursive] Error 1
 
 
 --Jani
 
 
 Previous Comments:
 ---
 
 [2001-01-12 02:25:27] [EMAIL PROTECTED]
 gcc  -I. -I/export/home/art/php-4.0.4pl1/ext/sockets 
-I/export/home/art/php-4.0.4pl1/main -I/export/home/art/php-4.0.4pl1 
-I/export/home/art/apache_1.3.14/src/include 
-I/export/home/art/apache_1.3.14/src/os/unix -I/export/home/art/php-4.0.4pl1/Zend 
-I/export/home/art/c-client/include -I/export/home/art/sdk40/include 
-I/usr/local/mysql/include/mysql -I/export/home/art/php-4.0.4pl1/ext/xml/expat/xmltok 
-I/export/home/art/php-4.0.4pl1/ext/xml/expat/xmlparse 
-I/export/home/art/php-4.0.4pl1/TSRM  -D_POSIX_PTHREAD_SEMANTICS -DXML_BYTE_ORDER=21 
-g -O2  -c sockets.c  touch sockets.lo
 sockets.c: In function `php_if_recvmsg':
 sockets.c:1728: structure has no member named `msg_control'
 sockets.c:1729: structure has no member named `msg_controllen'
 sockets.c:1731: structure has no member named `msg_control'
 sockets.c:1732: structure has no member named `msg_controllen'
 sockets.c:1735: structure has no member named `msg_flags'
 sockets.c:1741: structure has no member named `msg_control'
 sockets.c:1750: warning: passing arg 3 of `add_assoc_string' makes pointer from 
integer without a cast
 sockets.c:1754: structure has no member named `msg_controllen'
 sockets.c:1755: structure has no member named `msg_flags'
 sockets.c:1787: structure has no member named `msg_control'
 sockets.c:1788: structure has no member named `msg_controllen'
 sockets.c:1790: structure has no member named `msg_control'
 sockets.c:1791: structure has no member named `msg_controllen'
 sockets.c:1794: structure has no member named `msg_flags'
 sockets.c:1800: structure has no member named `msg_control'
 sockets.c:1810: warning: passing arg 3 of `add_assoc_string' makes pointer from 
integer without a cast
 sockets.c:1812: structure has no member named `msg_controllen'
 sockets.c:1814: structure has no member named `msg_flags'
 *** Error code 1
 make: Fatal error: Command failed for target `sockets.lo'
 Current working directory /export/home/art/php-4.0.4pl1/ext/sockets
 *** Error code 1
 make: Fatal error: Command failed for target `all-recursive'
 Current working directory /export/home/art/php-4.0.4pl1/ext/sockets
 *** Error code 1
 make: Fatal error: Command failed for target `all-recursive'
 Current working directory /export/home/art/php-4.0.4pl1/ext
 *** Error code 1
 

[PHP-DEV] Extending PHP and the STL

2001-01-12 Thread Jason Lee

I'd like to write a module for PHP so that we can, from our PHP scripts, 
talk to our servers using our home grown communication library.  My 
concern is that documentation says to use emalloc(), estrdup(), and 
efree().  Our code uses the STL quite heavily.  Beyond getting past the 
C++ to C linker issues (extern "C" { ), will the STL cause memory 
problems?  Is this the right forum for this kind of question? Thanks!

-- 
Jason Lee  | "Gun control? Oh, great. Now how am I going to
Programmer Analyst | well-regulate my militia?" -- The Onion


-- 
PHP Development 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-DEV] PHP 4.0 Bug #5694 Updated: system(), exec(), passthru() pass the command, but do not output anything

2001-01-12 Thread sniper

ID: 5694
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Duplicate
Old-Bug Type: Misbehaving function
Bug Type: Unknown/Other Function
Assigned To: 
Comments:



Previous Comments:
---

[2000-07-20 14:29:30] [EMAIL PROTECTED]
PHP 4.0.1pl2 running as CGI under IIS 5/Windows 2000 (the same is valid for IIS 4/Win 
NT 4)

system(), exec(), passthru() do not output any response of the command.

(it worked from version 3.0.12 thru 3.0.16)

for e.g. intranet applications this feature is pretty important, and it does work for 
unix platforms.
But we have to develop apps for both platforms due to certain conditions and we love 
PHP4 and would like to fully use it under WIN32 too.

Is this an item to be fixed easily? Do we have to stick to 3.0.16?

thanx  bye

Carsten

---


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


-- 
PHP Development 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-DEV] php_value error_reporting

2001-01-12 Thread Cynic

A quick one: is PHP supposed to recognize named constants in 
php_value error_reporting, or is it a bug?

php_value error_reporting E_ALL
and 
php_value error_reporting "E_ALL"

disable displaying errors including parse errors on both 
Linux (RH6.2, Apache 1.3.12, PHP 4.0.4) and NT 5 (1.3.15-dev,
today's CVS).

If it's supposed to take only integer values, why do the
numbers differ from the 'usual' stuff (php.ini)?




Cynic:

A member of a group of ancient Greek philosophers who taught
that virtue constitutes happiness and that self control is
the essential part of virtue.

[EMAIL PROTECTED]



-- 
PHP Development 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-DEV] PHP 4.0 Bug #8680: Here-DOC termination

2001-01-12 Thread anthony

From: [EMAIL PROTECTED]
Operating system: Any
PHP version:  4.0.4
PHP Bug Type: *General Issues
Bug description:  Here-DOC termination

The following PHP code causes a Parse error:

$string  EOD
This
is
a
string.
EOD ;

Workaround: eliminate space that precedes semicolon.  This causes me to depart from 
the best practices I chose to follow.


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



-- 
PHP Development 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-DEV] PHP 4.0 Bug #8653 Updated: function array_diff fails for larger arrays

2001-01-12 Thread cynic

ID: 8653
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Arrays related
Assigned To: 
Comments:

seems to be fixed in CVS.

Previous Comments:
---

[2001-01-11 08:56:38] [EMAIL PROTECTED]
?
# run this!

$array1 = array(
0 = 8221874,
31 = -237983854,
32 = -178422741,
33 = -133452210,
34 = -132423065,
35 = -86484311,
);

$array2 = array(
3 = -237983854,
4 = -178422741,
6 = -133452210,
7 = -132423065,
8 = -86484311,
11 = 8221874,
);

$array3 = array(
0 = 8221874,
1 = 41196856,
2 = 72211234,
3 = 176494324,
4 = 208997856,
5 = 228939765,
6 = 330073804,
7 = 340600386,
8 = 618210552,
9 = 762247645,
10 = 900146471,
11 = 1091304725,
12 = 1140421591,
13 = 1270411028,
14 = 1478191477,
15 = 1673874064,
16 = 1903882621,
17 = 1999343365,
18 = 2140576596,
19 = -2118575707,
20 = -2017197384,
21 = -1809590647,
22 = -1766079050,
23 = -1637347426,
24 = -1482531933,
25 = -1479363897,
26 = -1391639078,
27 = -1246350380,
28 = -1054044604,
29 = -982856673,
30 = -447800894,
31 = -237983854,
32 = -178422741,
33 = -133452210,
34 = -132423065,
35 = -86484311,
36 = -17918422,
37 = -14497841
);

$array4 = array(
0 = -447800894,
1 = -418764538,
2 = -392625909,
3 = -237983854,
4 = -178422741,
5 = -170886411,
6 = -133452210,
7 = -132423065,
8 = -86484311,
9 = -17918422,
10 = -14497841,
11 = 8221874,
12 = 41196856,
13 = 72211234,
14 = 176494324,
15 = 208997856,
16 = 228939765,
17 = 330073804,
18 = 340600386,
19 = 447686053,
20 = 618210552,
21 = 762247645,
22 = 900146471,
23 = 931246825,
24 = 931347017,
25 = 1091304725,
26 = 1098325520,
27 = 1140421591,
28 = 1270411028,
29 = 1283087206,
30 = 1478191477,
31 = 1545959313,
32 = 1546768297,
33 = 1582484674,
34 = 1609828347,
35 = 1652353999,
36 = 1673874064,
37 = 1903882621,
38 = 1999343365,
39 = 2140576596,
40 = -2118575707,
41 = -2092056065,
42 = -2041328486,
43 = -2017197384,
44 = -1815706420,
45 = -1809590647,
46 = -1766079050,
47 = -1682601875,
48 = -1637347426,
49 = -1482531933,
50 = -1479363897,
51 = -1477072276,
52 = -1431626038,
53 = -1391639078,
54 = -1246350380,
55 = -1054044604,
56 = -982856673,
57 = -904181010
);

echo "array_diff on small arrays:n";
print_r(array_diff ($array1,$array2));

echo "array_diff on bigger arrays:n";
print_r(array_diff ($array3,$array4));
?

---


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


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




Re: [PHP-DEV] PHP 4.0 Bug #8667 Updated: sockets

2001-01-12 Thread Jon Parise

On Fri, Jan 12, 2001 at 07:16:57PM +0200, Jani Taskinen wrote:

 Well, the bug displayed errors that I fixed under Sun CC.  What you
 have here are different errors with GCC, so that should be filed as a
 separate bug.
 
 [clip from original bug report]
 gcc  -I. -I/export/home/art/php-4.0.4pl1/ext/sockets
 
 So what is this ? Some new name for Sun CC?  :)

Ah, I missed that one.  My fault.

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

-- 
PHP Development 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-DEV] PHP 4.0 Bug #8681: Function arguments in 'global'

2001-01-12 Thread sven

From: [EMAIL PROTECTED]
Operating system: Linux/FreeBSD
PHP version:  4.0.4
PHP Bug Type: Variables related
Bug description:  Function arguments in 'global'

function foo ($bar)
{
  global $bar;
  # ...
}

Opposite to php3, php4 doesn't warn you. This is now documented.


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



-- 
PHP Development 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-DEV] Re: PHP 4.0 Bug #7244 Updated: Problem with LOAD DATA LOCAL INFILE

2001-01-12 Thread Christiane Schmidt-Kster

No, I didn't.
I've also got an old version of PHP 4.0.2 installed and I can switch
between both versions via ScriptAlias in httpd.conf (php.ini is still the
same). With PHP 4.0.2 it's all working fine but with PHP 4.0.4 there is
that problem.

Christiane


- Original Message -

From: "Bug Database" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, January 12, 2001 2:14 PM
Subject: PHP 4.0 Bug #7244 Updated: Problem with LOAD DATA LOCAL INFILE


 ID: 7244
 Updated by: cynic
 Reported By: [EMAIL PROTECTED]
 Old-Status: Open
 Status: Feedback
 Bug Type: MySQL related
 Assigned To:
 Comments:

 did you switch by any chance from php.ini-dist to php.ini-optimized when
you upgraded your PHP to 4.0.3?

 Previous Comments:
 
---

 [2001-01-04 11:02:07] [EMAIL PROTECTED]
 No, the original problem persists. Adding addslashes is only a temporary
solution. This breaks some existing programs.

 -Egon

 
---

 [2001-01-04 10:52:10] [EMAIL PROTECTED]
 User reported that it works if he does:
 $file = addslashes ($file)

 So this was a user error.

 
---

 [2001-01-04 10:41:56] [EMAIL PROTECTED]
 With

 $file = addslashes ($file);

 it works.

 
---

 [2000-10-16 10:51:25] [EMAIL PROTECTED]
 I'm using Win98, Apache 1.3.9, MySQL 3.23-beta and PHP4.0.3.

 Since PHP4.0.3 there is a problem with import data to MySQL (LOAD DATA
LOCAL INFILE). It seems that PHP is filtering out all slashes of the file
path, so MySQL can't find the file.

 mysql_error() and mysql_errno() say something like this

 "File 'e:TempphpA154.TMP' not found (Errcode: 2)"

 LOAD DATA INFILE (without LOCAL) seems to be ok.

 
---


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



-- 
PHP Development 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-DEV] PHP 4.0 Bug #7244 Updated: Problem with LOAD DATA LOCAL INFILE

2001-01-12 Thread cynic

ID: 7244
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: MySQL related
Assigned To: 
Comments:

user feedback:

No, I didn't.
I've also got an old version of PHP 4.0.2 installed and I can switch between both 
versions via ScriptAlias in httpd.conf (php.ini is still the same). With PHP 4.0.2 
it's all working fine but with PHP 4.0.4 there is that problem.


Previous Comments:
---

[2001-01-12 08:14:06] [EMAIL PROTECTED]
did you switch by any chance from php.ini-dist to php.ini-optimized when you upgraded 
your PHP to 4.0.3?

---

[2001-01-04 11:02:07] [EMAIL PROTECTED]
No, the original problem persists. Adding addslashes is only a temporary solution. 
This breaks some existing programs.

-Egon

---

[2001-01-04 10:52:10] [EMAIL PROTECTED]
User reported that it works if he does:

$file = addslashes ($file)



So this was a user error.

---

[2001-01-04 10:41:56] [EMAIL PROTECTED]
With

$file = addslashes ($file);

it works.

---

[2000-10-16 10:51:25] [EMAIL PROTECTED]
I'm using Win98, Apache 1.3.9, MySQL 3.23-beta and PHP4.0.3.

Since PHP4.0.3 there is a problem with import data to MySQL (LOAD DATA LOCAL INFILE). 
It seems that PHP is filtering out all slashes of the file path, so MySQL can't find 
the file.

mysql_error() and mysql_errno() say something like this

"File 'e:TempphpA154.TMP' not found (Errcode: 2)"

LOAD DATA INFILE (without LOCAL) seems to be ok.

---

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

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


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




Re: [PHP-DEV] PHP 4.0.4 patchlevel 1 released

2001-01-12 Thread Daniel Beulshausen

At 23:59 11.01.2001 +0200, Zeev Suraski wrote:
PHP 4.0.4 patchlevel 1 has been released.  This version fixes a few 
party-crashing bugs that were found in PHP 4.0.4, and two security problem 
that was found in the Apache module of all versions of PHP 4.0.  While the 
danger of being vulnerable to the security problems that were found is 
low, all users of PHP 4.0.x that use PHP alongside Apache are encouraged 
to upgrade to PHP 4.0.4pl1.

The new version can be downloaded from 
http://www.php.net/do_download.php?download_file=php-4.0.4pl1.tar.gz

i uploaded a package at http://www.php4win.com/download/php-4.0.4pl1-Win32.zip
maybe phil can up it when he's uploading the installer, i'm out of karma :)

daniel


/*--
daniel beulshausen - [EMAIL PROTECTED]
using php on windows? http://www.php4win.de


-- 
PHP Development 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-DEV] PHP 4.0 Bug #8330 Updated: Crash

2001-01-12 Thread cynic

ID: 8330
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: OCI8 related
Assigned To: 
Comments:

could you please retry with a newer version (4.0.4 / 4.0.4pl1) ?

Previous Comments:
---

[2000-12-20 05:32:19] [EMAIL PROTECTED]
Apache 1.3.12 win32; PHP4.0.3pl1; Windows NT4.0 Server SP5; Oracle 8.0.4.0.0 Client
php is installed via Apache-Module.
If I try to start Apache (installed as a service), I get a memory-access-violation.
If I comment out the line for oci8-support in the php.ini, it works.

I tried php also as CGI, but then I get the access-violation, if I start my 
php-script.




---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #8050 Updated: Sending malformed body (message string)

2001-01-12 Thread cynic

ID: 8050
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Mail related
Assigned To: 
Comments:

according to RFC... err, can't recall... you have to use CRLF (\r\n in PHP) to delimit 
lines in mail messages.

if that doesn't help, please reopen this bug report.

Previous Comments:
---

[2000-11-30 09:11:39] [EMAIL PROTECTED]
Should have mentioned I'm using the ISAPI .dll version of PHP as opposed to the .exe 
version, on an IIS4 web server.

---

[2000-11-30 09:09:48] [EMAIL PROTECTED]
When using the mail() function, anything put into the body becomes malformed. Example:

mail("[EMAIL PROTECTED]","test","testingn1...n2...n3...");

...results in the following email body...

testingatever.com
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

The server it's sending to is an XMail server, but I don't think it's that. And 
frankly, I have no idea what's causing it...I get the same results on two different 
servers

---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #8682: date issue

2001-01-12 Thread michael

From: [EMAIL PROTECTED]
Operating system: linux redhat 6.2
PHP version:  4.0.4
PHP Bug Type: Scripting Engine problem
Bug description:  date issue

echo date("m/d/Y br h:i A",$filemodified);
used to work in earlier versions (4.0.1?)

4.0.4pl1 it doesn' work.

same line above in 4.0.4pl1 produces

01/12/2001 01:825898547 PM

with capitalized BR tag, it's even different, but still not right.  


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



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




Re: [PHP-DEV] php_value error_reporting

2001-01-12 Thread Zeev Suraski

At 19:32 12/1/2001, Cynic wrote:
A quick one: is PHP supposed to recognize named constants in
php_value error_reporting, or is it a bug?

No, it's a feature of the php.ini parser - it's not supported by the Apache 
module php_value directives...


If it's supposed to take only integer values, why do the
numbers differ from the 'usual' stuff (php.ini)?

What do you mean?  They're not supposed to be different.

Zeev


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


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




Re: [PHP-DEV] php_value error_reporting

2001-01-12 Thread Cynic

At 20:15 12.1. 2001, Zeev Suraski wrote the following:
-- 
At 19:32 12/1/2001, Cynic wrote:
A quick one: is PHP supposed to recognize named constants in
php_value error_reporting, or is it a bug?

No, it's a feature of the php.ini parser - it's not supported by the Apache module 
php_value directives...

Well, that's surely pitty, because the advantage of named error level
constants is gone.

If it's supposed to take only integer values, why do the
numbers differ from the 'usual' stuff (php.ini)?

What do you mean?  They're not supposed to be different.

I'll check again... Ah, I got mistaken because 
http://www.php.net/manual/configuration.php only lists error 
levels up to E_NOTICE, sans the named constants. So I guess 
it's rather a docu prob.

Sorry for false alarm.

Cynic


-- 
PHP Development 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-DEV] carnavaldelpais.com.ar

2001-01-12 Thread antonio


[EMAIL PROTECTED]

Esa informacin la encontraras en la pagina www.carnavaldelpais.com.ar




 SU DIRECCION FUE OBTENIDA DE UN SITIO PUBLICO Y NUESTRA INTENCION ES INFORMARLE 
NUESTRA PROPUESTA, LE PEDIMOS DISCULPAS SI NO RESULTASE DE SU INTERES... 
/// 
Este mensaje se enva con la complacencia de la nueva legislacin sobre correo 
electrnico: Por seccin 301, parrafo (a)(2)(C) de S.1618 Bajo el decreto S.1618 
titulo 3ro. Aprobado por el 105 congreso base de las normativas internacionales sobre 
SPAM, este E-mail no podr ser considerado SPAM mientras incluya una forma de ser 
removido. Para ser removido de la lista enve a  [EMAIL PROTECTED] este mensaje 
y en subjet, ttulo o asunto escriba "REMOVE" que automticamente ser removido para 
futuros mensajes. El proceso es automtico. No olvide poner "REMOVE" en el asunto. 
 







--
PHP Development 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-DEV] PHP 4.0 Bug #8467 Updated: Crash in Tomcat with PHP/Servlet feature

2001-01-12 Thread akilov

ID: 8467
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproduceable crash
Description: Crash in Tomcat with PHP/Servlet feature

Tried again today with the latest CVS but still getting the
problem.  Here's the complete gdb backtrace (sorry for
chopping it in half before):

#0  0xd1830484 in abort ()
#1  0xd0bdfe64 in pthread_rwlock_destroy ()
#2  0xd0bf0c48 in pthread_rwlock_destroy ()
#3  signal handler called
#4  0xd2e951d0 in operator new ()
#5  0xd2e81094 in open_file_for_scanning
(file_handle=0x209ce358,
compiler_globals=0x20295328) at
./zend_language_scanner.l:296
#6  0xd2e808c8 in compile_file (file_handle=0x209ce358, type=2,
compiler_globals=0x20295328) at
./zend_language_scanner.l:343
#7  0xd2e68e28 in zend_execute_scripts (type=8,
compiler_globals=0x20295328,
executor_globals=0x202a92c8, file_count=3) at zend.c:740
#8  0xd2eb1a88 in php_execute_script (primary_file=0x209ce358,
compiler_globals=0x20295328, executor_globals=0x202a92c8,
core_globals=0x202b1ae8) at main.c:1198
#9  0xd2eaed68 in Java_net_php_servlet_send
(jenv=0x209cef04, self=0x4,
requestMethod=0x3, queryString=0x0, requestURI=0x2,
pathTranslated=0x1,
contentType=0x0, contentLength=-1, authUser=0x0,
display_source_mode=0 '\000') at servlet.c:407
#10 0x204a57ac in ?? () from (unknown load module)

Again, to be able to build this correctly, I had to hack the
ext/java/config.m4 to look for libjava.a (instead of
libjava.so).  Will have to fix this in CVS at some point.

Previous Comments:
---

[2000-12-28 18:35:25] [EMAIL PROTECTED]
Finally figured out how to get a gdb backtrace (sorry, my first time).
Here's the relevant section:

#5  0xd6ec80a8 in open_file_for_scanning (file_handle=0x209ce358,
compiler_globals=0x20250a38) at ./zend_language_scanner.l:297
#6  0xd6ec78c8 in compile_file (file_handle=0x209ce358, type=2,
compiler_globals=0x20250a38) at ./zend_language_scanner.l:345
#7  0xd6eafe20 in zend_execute_scripts (type=8, compiler_globals=0x20250a38,
executor_globals=0x202548a8, file_count=3) at zend.c:738
#8  0xd6f1ab0c in php_execute_script (primary_file=0x209ce358,
compiler_globals=0x20250a38, executor_globals=0x202548a8,
core_globals=0x202581d8) at main.c:1209
#9  0xd6f950b8 in Java_net_php_servlet_send (jenv=0x209cef04, self=0x4,
requestMethod=0x3, queryString=0x0, requestURI=0x2, pathTranslated=0x1,
contentType=0x0, contentLength=-1, authUser=0x0,
display_source_mode=0 '

-- 
PHP Development 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-DEV] PHP 4.0 Bug #8686: Starting a session corrupts reading of external files.

2001-01-12 Thread derek

From: [EMAIL PROTECTED]
Operating system: Linux AES.MandrakeSoft.com 2.2.17-21mdk
PHP version:  4.0.3pl1
PHP Bug Type: *Session related
Bug description:  Starting a session corrupts reading of external files.

When I begin a session, using "session_start()" and then read in a file using file(), 
readfile(), or require(), the contents of the file get corrupted with double quote 
characters.

Here's a sample file to read in (name it "test_file.txt"):
a.b=[]

Here's a PHP webpage that displays corrupted output:
?php

session_start();
readfile( 'test_file.txt' );

?

The corrupted output is:
a.b="[]"

If the call to session_start() is removed from the above script, the output matches 
the sample file contents.

Also if any of the characters are removed from the sample file, the readfile() works 
fine, so there's something specific to the text in the sample file that disagrees with 
session_start().

FYI, the sample file is small section of javascript in an HTML file I am using.  I 
pared down the javascript/HTML to this small section that was getting corrupted.  I'm 
trying to echo different HTML files depending on session variables I set. 


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



-- 
PHP Development 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-DEV] PHP 4.0 Bug #7458 Updated: FATAL: emalloc(): Unable to allocate -11773805 bytes

2001-01-12 Thread cynic

ID: 7458
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Duplicate
Bug Type: Mail related
Assigned To: 
Comments:

dupe of #7447

Previous Comments:
---

[2000-10-25 14:11:58] [EMAIL PROTECTED]
desc :
using the mail() function in a php scrit, the parser connects to the mail server (i 
see on my control panel of that mail server), then don't send anything and stop : i 
get that message on my browser :
FATAL: emalloc(): Unable to allocate -11773805 bytes 

i've FTP and GD 1.8 DLL loaded

my mailserver is "Internet Anywhere Mail Server 3.2.1 (www.tnsoft.co)

IT happend suddenly after 3 hours of test, and now it's 100% reproduction : never get 
the script to work again. nothing changed in my config between the last OK reload and 
the first non-OK.

After a reboot, it always says :
FATAL: emalloc(): Unable to allocate -11773805 bytes 

i can't figure out what it could be.

djdd [EMAIL PROTECTED]

---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #7408 Updated: ISAPI dll Error

2001-01-12 Thread cynic

ID: 7408
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: PWS related
Assigned To: 
Comments:

does this happen with newer versions of PHP?

actually, I think this is a very easy to fix in the MMC, so I'm closing the bug 
report. 
if you have your server set properly, and the bug appears in 4.0.4pl1 too, reopen it.

Previous Comments:
---

[2000-10-23 08:05:06] [EMAIL PROTECTED]
After I install PHP4.0.3pl1 I found that the PWS cannot run the file with extension 
.php
The error message giving as below

403.1 Forbidden: Execute Access Forbidden

This error can be caused if you try to execute a CGI, ISAPI, or other executable 
program from a directory that does not allow
programs to be executed.

Please contact the Web server's administrator if the problem persists.


---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #7666 Updated: PHP4 doesn't read php.ini with NT4/IIS

2001-01-12 Thread cynic

ID: 7666
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: *Configuration Issues
Assigned To: 
Comments:

until 4.0.4 incl. phpinfo() reported 'php.ini' (i. e. the filename without path) on 
windows. are you sure the files weren't read? could you try with a more recent version 
(4.0.4pl1 optimally)?

also note, though this may be of little relevance, that at least with win32 Apache, 
php.ini is read properly from %windir% or the directory where Apache.exe resides 
regardless whether php4ts.dll is in the Apache directory or %windir%/system32.

Previous Comments:
---

[2000-11-14 10:19:08] [EMAIL PROTECTED]
I now found the way to get it work (CGI-version):

The php.ini is only parsed, when php4ts.dll resides in %windir%/system32 AND php.ini 
in %windir%.
When I add the php directory to the PATH, php works with all files there, but the 
ini-File will not get parsed, neither in the php directory nor in %windir%. I also 
tried to set PHPRC accordingly, but it didn't work.

I think there must be a bug in the application when it tries to find php.ini. Perhaps 
one could change the windows install instructions (php4ts.dll MUST be copied to 
system32 not only to somewhere in the PATH)

I can't do it myself because I'm still not good enough... sorry.

Thank you
Christoph


---

[2000-11-06 19:05:18] [EMAIL PROTECTED]
Hi 

I can't get PHP4 to parse the php.ini file on two NT4/IIS-systems, one with CGI, one 
with ISAPI. 
I tried with php.ini in %windir% and in the php directory, but when calling phpinfo() 
I always get the default values. 
There are no duplicate php.ini files on both systems. I always stopped and restarted 
IIS on the command line when I've tried another configuration. I also tried to set the 
PHPRC environment variable to the correct path.

I wonder why phpinfo() says 

Configuration File (php.ini) Path : php.ini 

instead of c:winntphp.ini? 

On my local system with NT/Apache everything works perfectly. 

When scanning the web I found lots of messages describing a similar problem. None of 
the answers suited my problem. I'm neither a PHP pro nor a beginner. 

Thanks in advance for an answer. 
Christoph

---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #6652 Updated: include() require() add trailing CRLF

2001-01-12 Thread cynic

ID: 6652
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: *Function Specific
Assigned To: 
Comments:

have you by any chance updated your PHP since 4.0.2? does it still happen?

Previous Comments:
---

[2000-09-17 02:14:47] [EMAIL PROTECTED]
Start include.php
START?include('/web/file.inc')?END
End include.php

Start file.inc:
This is some text
End file.inc

Niether file has a trailing new line.  Remember to do a view source to see this 
because the browser will not render a new line.  

---

[2000-09-16 18:25:09] [EMAIL PROTECTED]
Cannot reproduce that on my system. Could you publish your file.inc?

---

[2000-09-10 18:11:37] [EMAIL PROTECTED]
When using include() or require imbeded in HTML a trailing new line is added. Example:

START?include('/file.inc');?END

Will produce:

STARTFile contents
END

The file can contain any number of characters.


---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #6474 Updated: no unlink() for deleting folders

2001-01-12 Thread cynic

ID: 6474
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Analyzed
Status: Feedback
Bug Type: Directory function related
Assigned To: 
Comments:

do you still have problems with these functions in 4.0.4 or 4.0.4pl1?
rename(), rmdir() and unlink() Work For Me(tm) on NT 5 with mod_php4.

Previous Comments:
---

[2000-11-23 06:07:21] [EMAIL PROTECTED]
reclassify

---

[2000-11-02 15:21:56] [EMAIL PROTECTED]
rename() is fixed in 4.0.4

---

[2000-08-31 15:49:09] [EMAIL PROTECTED]
Congratulation for fixing unlink() !!! 
Now Windows users can delete files using unlink(), BUT still can't delete folders!!!

Also rename() is STILL NOT WORKING!!!

REMEMBER: Last working version of unlink and rename was PHP 4.0.0 !!!

I hope version 4.0.3 will fix those bugs!

Chris

---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #8684 Updated: Call to parse_xml causes page load to fail.

2001-01-12 Thread sniper

ID: 8684
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *XML functions
Assigned To: 
Comments:

This is fixed in PHP 4.0.4pl1.

--Jani

Previous Comments:
---

[2001-01-12 16:05:06] [EMAIL PROTECTED]
You can ignore the script if desired because it is an exact duplicate of the final 
test example contained in the xml parsing documentation on this site.  This script 
causes a browser message box to appear saying the page cannot be opened due to the 
server returning an invalid or unrecognized response.

?php
$file = "xmltest.xml";

function trustedFile($file) {
// only trust local files owned by ourselves
if (!eregi("^([a-z]+)://", $file) 
 fileowner($file) == getmyuid()) {
return true;
}
return false;
}

function startElement($parser, $name, $attribs) {
print "lt;font color="#cc"$name/font";
if (sizeof($attribs)) {
while (list($k, $v) = each($attribs)) {
print " font color="#009900"$k/font="font 
   color="#99"$v/font"";
}
}
print "gt;";
}

function endElement($parser, $name) {
print "lt;/font color="#cc"$name/fontgt;";
}

function characterData($parser, $data) {
print "b$data/b";
}

function PIHandler($parser, $target, $data) {
switch (strtolower($target)) {
case "php":
global $parser_file;
// If the parsed document is "trusted", we say it is safe
// to execute PHP code inside it.  If not, display the code
// instead.
if (trustedFile($parser_file[$parser])) {
eval($data);
} else {
printf("Untrusted PHP code: i%s/i", 
htmlspecialchars($data));
}
break;
}
}

function defaultHandler($parser, $data) {
if (substr($data, 0, 1) == ""  substr($data, -1, 1) == ";") {
printf('font color="#aa00aa"%s/font', 
htmlspecialchars($data));
} else {
printf('font size="-1"%s/font', 
htmlspecialchars($data));
}
}

function externalEntityRefHandler($parser, $openEntityNames, $base, $systemId,
  $publicId) {
if ($systemId) {
if (!list($parser, $fp) = new_xml_parser($systemId)) {
printf("Could not open entity %s at %sn", $openEntityNames,
   $systemId);
return false;
}
while ($data = fread($fp, 4096)) {
if (!xml_parse($parser, $data, feof($fp))) {
printf("XML error: %s at line %d while parsing entity %sn",
   xml_error_string(xml_get_error_code($parser)),
   xml_get_current_line_number($parser), $openEntityNames);
xml_parser_free($parser);
return false;
}
}
xml_parser_free($parser);
return true;
}
return false;
}


function new_xml_parser($file) {
global $parser_file;

$xml_parser = xml_parser_create();
xml_parser_set_option($xml_parser, XML_OPTION_CASE_FOLDING, 1);
xml_set_element_handler($xml_parser, "startElement", "endElement");
xml_set_character_data_handler($xml_parser, "characterData");
xml_set_processing_instruction_handler($xml_parser, "PIHandler");
xml_set_default_handler($xml_parser, "defaultHandler");
xml_set_external_entity_ref_handler($xml_parser, "externalEntityRefHandler");

if (!($fp = @fopen($file, "r"))) {
return false;
}
if (!is_array($parser_file)) {
settype($parser_file, "array");
}
$parser_file[$xml_parser] = $file;
return array($xml_parser, $fp);
}

if (!(list($xml_parser, $fp) = new_xml_parser($file))) {
die("could not open XML input");
}

print "pre";
while ($data = fread($fp, 4096)) {
if (!xml_parse($xml_parser, $data, feof($fp))) {
die(sprintf("XML error: %s at line %dn",
xml_error_string(xml_get_error_code($xml_parser)),
xml_get_current_line_number($xml_parser)));
}
}
print "/pre";
print "parse completen";
xml_parser_free($xml_parser);

echo phpinfo();
?

---


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


-- 
PHP Development 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-DEV] PHP Security Advisory - Apache Module bugs

2001-01-12 Thread Zeev Suraski

Problems
=

[1] PHP supports a configuration mechanism that allows users to configure 
PHP directives on a per-directory basis.  Under Apache, this is usually 
done using .htaccess files.  Due to a bug in the Apache module version of 
PHP, remote 'malicious users' might be able to create a special HTTP 
request that would cause PHP to serve the next page with the wrong values 
for these directives.  In certain (fairly rare) situations, this could 
result in a security problem.

[2] PHP supports the ability to be installed, and yet disabled, by setting 
the configuration option 'engine = off'.  Due to a bug in the Apache module 
version of PHP, if one or more virtual hosts within a single Apache server 
were configured with engine=off, this value could 'propagate' to other 
virtual hosts.  Because setting this option to 'off' disables execution of 
PHP scripts, the source code of the scripts could end up being sent to the 
end clients.


Impact
===

Even though in their worst-case situations these problems could have severe 
implications, these worst-cases are rare.  In order to take advantage of 
problem #1, the attacker must have good knowledge of the structure of the 
site, the values of the various PHP directives in each directory, and a way 
that would help him exploit the bug using this knowledge.  In addition, he 
must also be lucky enough to perform the attack on the same Apache httpd 
process that he exploits in a prior request, which can be very difficult to 
do on a busy site.
Problem #2 is more serious, but because of its severity, it's most often 
detected immediately.  This problem also only affects a setup that has 
multiple virtual hosts with some of them configured not to allow execution 
of PHP scripts, which is pretty rare.


Affected Software Versions
===

All versions of PHP 4.0, from PHP 4.0.0 (and possibly earlier betas) 
through PHP 4.0.4 are vulnerable to these problems.  Note that only the 
Apache module version of PHP is vulnerable - the CGI module as well as 
other server modules are *NOT* affecgted.

PHP 3.0 is *NOT* affected.


Solution


The recommended solution is to upgrade to PHP 4.0.4pl1, available at 
http://www.php.net/downloads.php

A workaround for problem #2 is to explicitly set 'engine=on' on all of the 
virtual hosts that are supposed to serve PHP pages, if one or more virtual 
hosts is configured with engine=off.

A partial workaround for problem #1 is to disallow 'OPTIONS' requests.


Acknowledgements
==

I'd like to thank James Moore, which, after hearing about the bug report, 
managed to successfully reproduce it, and issue a pin-pointing problem 
description, that helped solve the bug instantly.


Zeev


PHP Group
http://www.php.net/

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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #7079 Updated: mysql_query() and mysql_affected_rows() always return false

2001-01-12 Thread cynic

ID: 7079
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: MySQL related
Assigned To: 
Comments:

have you experienced this error with newer versions of PHP?

Previous Comments:
---

[2000-10-07 12:12:41] [EMAIL PROTECTED]
I use the current php-4.0.2-4mdk RPM package from Mandrakesoft (maintainer Jean-Michel 
Dault [EMAIL PROTECTED]).

If I do an INSERT or UPDATE in an opened database, mysql_query() always return 0 
(false) even if the transaction was successful and the correct values are stored in 
the db.

The same problem for mysql_affected_rows(), it return 0 even if there are
1 or more rows altered in the database.

Apache is 1.3.12
MySQL is 3.23.23

I use the ZendOptimizer for php 4.0.2

---


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


-- 
PHP Development 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-DEV] PHP 4.0 Bug #6722 Updated: Not a valid MYSQL result resource / Lost connection to MySQL server during quer

2001-01-12 Thread cynic

ID: 6722
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: MySQL related
Assigned To: 
Comments:

have you experienced this error with newer versions of PHP?

Previous Comments:
---

[2000-09-13 18:38:09] [EMAIL PROTECTED]
we're using a Apache 1.3.12 Server + PHP 4.02 + MySQL on a Sun Ultra 250  - 256Mo RAM 
Patched 106541-11

we have the same message while connecting/select_db/query/fetch_row

"Not a valid MYSQL result resource ..."

mysql_error($connection_id) gives us : "Lost connection to MySQL server during query"

we consult the bug reporting list and :
- when we make a gettype($connection_id) - "resource"

- we tried to remove the second parameter ($connection_id) in query - nothing came

In fact, the pb appears sometimes at every request and sometimes do not appears for 
4/5 same requests.
It's very unregular !



Source : 

HTML
?
$cx_si = mysql_connect("localhost","root","toto");
mysql_select_db("si",$cx_si);
$sql = "select * from USERS;";
$st_si = mysql_query($sql);
echo("after : " . mysql_error($cx_si) . "BR");
echo("after query 2: " . gettype($cx_si) . "BR");
echo("st_si: " . gettype($st_si) . "BR");
echo("st_si: " . $st_si . "BR");
$temp = mysql_fetch_row($st_si);
?
/HTML


we made many recompilations with differents releases of apache(from 1.3.9 to 1.3.12), 
php with 4.01pl2 and 4.0.2

the database is correctly installed/configured/database accessible from the external

the table's got an unique index and contains two records

we tried to make a select * from table where 1=1 and 2=2 ...
to make the select bigger - nothing came



PHP Configuration : we followed strictly the configuration operations show in the page 
installation for uniw static mode on www.php.net
We are now testing the dynamic mode ...


Please could you tell us if you have already noticed this problem before with such a 
configuration ??

Thanks by advance.

Nicolas.




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 ? tag.  otherwise, only ?php and 
script 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

[PHP-DEV] PHP 4.0 Bug #7362 Updated: Crash when executing any mysql directive in php file

2001-01-12 Thread cynic

ID: 7362
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: MySQL related
Assigned To: 
Comments:

could you please try if this problem persists in 4.0.4pl1?

Previous Comments:
---

[2000-10-20 05:03:22] [EMAIL PROTECTED]
Hi.
I'm trying to call mySql from php.
MySql works fine on its side. So does php.
However, the following code crashes and opens a crash alert:
?
//establish user connection
mysql_connect("localhost");
?
It crashes in PHP4TS.DLL
Any clue?


---


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


-- 
PHP Development 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-DEV] ZendEngine Version Number

2001-01-12 Thread Sebastian Bergmann

  Wasn't the ZendEngine Version number raised to 1.0.4 for PHP 4.0.4? My
4.0.5-dev builds from CVS still show 1.0.3.

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

 make a gift   :   http://www.amazon.de/exec/obidos/wishlist/38W9FZC78HL2A

-- 
PHP Development 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-DEV] DOM XML Patch

2001-01-12 Thread Ron Chmara


From the notes:
--
[EMAIL PROTECTED]
Hello Uwe Steinmann! 

I have make a little change in Source so that is possible to create textnodes into 
existing node like this example: 

$node-new_child("", "text outside"); 

nodetext outside 
nodetext/ 
/node 

Here you can download my diff-file: 
http:/www.mf-software.de/files/php_domxml.diff 

Cu, Marco
---
Anybody know if this patch has been rolled in?

-Ronabop


--
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not neccesarrily those of myself,
my employers, or any of the other little voices in my head.

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