[PHP-DEV] is_link() behavior
This was originally posted to php-general, but for some reason I believe it may belong here. I apologize if I'm wrong. Forgive me for my ignorance, but I've noticed some unwanted behavior (IMO, at least) with the is_link() function. Given the simple code.. if ( is_link (/tmp/this_is_a_symlink) ) print (Success\n); and the file.. lrwxrwxrwx 1 root root 5 Apr 23 21:19 /tmp/this_is_a_symlink - /bin/ the above obviously prints 'Success\n'. However, if I BREAK the symlink, with something like the following.. lrwxrwxrwx 1 root root 4 Apr 23 21:21 /tmp/this_is_a_symlink - foo the script fails with.. Warning: stat failed for /tmp/this_is_a_symlink (errno=2 - No such file or directory) in ./test.php on line 3. The file /tmp/this_is_a_symlink is still a symlink, so it seems to me that the is_link() function should still return true, whether or not the symlink's target exists. Is there perhaps a function I have yet to discover that provides that behavior, without verifying the link's target? I ask this because much of linux's /proc contains (intentionally) broken symlink's and is_link()'s behavior is making the scouring of /proc difficult on me. ;) Thanks for any input.. J. Jones P.S. The script ran as root, so filesystem permissions aren't the issue. -- 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 #10468 Updated: PHPChat does not work with PHP 4.x
ID: 10468 Updated by: torben Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Unknown/Other Function PHP Version: 4.0.4pl1 Assigned To: Comments: Your feeling is correct--while PHP 4 is downwardly compatible with PHP 3 in most respects, there are differences. There is a migration list in the manual: http://www.php.net/manual/en/migration4.php Previous Comments: --- [2001-04-24 02:41:17] [EMAIL PROTECTED] Absolutely agree with you, but my feeling is that 4.x is not fully down compatible with earlier versions. PHPChat is not the only script with incompatibility problems (I had problems with WAPmail as well). May I ask you is there some detailed description about or some 4.x compatibility notes available? Thank you very much for quick response. Regards, Z --- [2001-04-23 18:49:51] [EMAIL PROTECTED] No offense, but that would be a bug in the script and not PHP. There is a possibility that the problem is caused by a bug in PHP, of course, but you'd need to verify what the bug was before submitting a report on it. The proper place to ask for support related to PHPChat is at the online forum at http://www.phpwizard.net/phorum/list.php?f=4 --- [2001-04-23 18:20:31] [EMAIL PROTECTED] a well known free script from PHPwizard that worked perfect under 3.0.x versions refuse to work under PHP 4.x. Seems problems are in session incompatibility Does anybody has some idea how to solve the problem. Thank you in advance. Regards, Z --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10468edit=2 -- 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 #10464 Updated: PHP_AUTH_PW is not set altough PHP_AUTH_USER is
ID: 10464 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Description: PHP_AUTH_PW is not set altough PHP_AUTH_USER is Update: register_globals is turned on. (see http://www-usercgi.tu-chemnitz.de/~tisc/authtest.php3 for output of phpinfo() after authentication.) Previous Comments: --- [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 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] 4.0.5: Merge Request
At 03:02 24/4/2001, Anil Madhavapeddy wrote: It a bit of a showstopper for pretty much all web-based mail clients like IMP - people have been reporting their logs being littered with segfaults for a while now actually. Ok then, merge it in, and looks like we'll have to have RC8 after all. Zeev -- 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] RC6 still reported even after repeated update to RC7
Yeah, it's been reported - RC7 identifies itself as RC6. It's still RC7 though :) At 06:33 24/4/2001, Jon Rosenberg wrote: I went through my server and deleted all files and directories associated with RC6, then went ahead and compiled RC7 with the same options, I deleted everything first b/c of aformentioned path changes I saw on Zend. I used the following config options and all worked perfectly, did a make, make install. I downloaded the following file: http://www.php.net/distributions/php-4.0.5RC7.tar.gz This is on apache 1.3.19 on linux. Configure Command'./configure' '--with-mysql' '--with-imap=/usr/lib' '--enable-trans-sid' '--with-apxs=/usr/sbin/apxs' '--with-jpeg-dir=/usr/src/jpeg-6b' '--with-png-dir=/usr/lib' '--with-gd=/usr/src/gd-2.0.1' '--with-freetype-dir=/usr/src/freetype-2.0.1' Here is what I get from phpinfo(); Version 4.0.5RC6 SystemLinux www.domain.com 2.2.14 Wed Jun 21 15:05:10 JST 2000 i586 unknown Build DateApr 23 2001 Server APIApache Virtual Directory Supportdisabled Configuration File (php.ini) Path/usr/local/lib/php.ini here is the listing for the new binary -rwxr-xr-x 1 root root 4612955 Apr 23 17:58 libphp4.so for some reason it still thinks it is RC6 and is using the old path for the php.ini file. I've removed every trace of php about 3 times and this keeps happening. So, what am I doing wrong? Thanks Jon -- 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] -- 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] Bug #10469: ODBC_result() fails on DB2 LONG VARCHAR columns
From: [EMAIL PROTECTED]
Operating system: Linux Slackware 7.1+
PHP version: 4.0.4pl1
PHP Bug Type: ODBC related
Bug description: ODBC_result() fails on DB2 LONG VARCHAR columns
Running on IBM DB2 UDB version 7.1 for Linux, PHP compiled with --with-ibm-db2
configure option.
Given the following table definition:
CREATE TABLE foo (bar1 INTEGER, bar2 LONG VARCHAR)
Connecting to the database:
$conn=odbc_connect(TESTDB, username, password);
Inserting data:
$rc=odbc_exec($conn, INSERT INTO foo VALUES (1, 'This is some really long
data..'));
And then running the following script:
for($i=1;$i3;$i++) {
$rc=odbc_fetch_row($q, 0);
$result=odbc_result($q, $i);
echo Data:.$result;
}
The first iteration returns the data from bar1 correctly.
The second iteration will give the following error on the line containing the
ODBC_result() call:
Warning: SQL error: [IBM][CLI Driver] CLI0115E Invalid cursor state.
SQLSTATE=24000, SQL state 24000 in SQLGetData in
/home/ltning/webmail2/functions/test.php on line 10
I have found that I do NOT get this error if I do not use the ODBC_fetch_row()
function prior to the second iteration (moving that line out of the loop). My theory
is that the DB2 engine handles ODBC_fetch_row() ODBC_result() calls differently when
LONG VARCHAR fields are involved than otherwise, and PHP does not know how to handle
this.
I need to use the ODBC_fetch_row() on every iteration because I'm creating custom
database functions, and there should be nothing directly wrong with that. I.e. this
_should_ work..
If I can provide any other information, please tell me.. ;)
Best regards,
Eirik Overby
--
Edit Bug report at: http://bugs.php.net/?id=10469edit=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] 4.0.5: Merge Request
On Tue, 24 Apr 2001, Zeev Suraski wrote: At 03:02 24/4/2001, Anil Madhavapeddy wrote: It a bit of a showstopper for pretty much all web-based mail clients like IMP - people have been reporting their logs being littered with segfaults for a while now actually. Ok then, merge it in, and looks like we'll have to have RC8 after all. There has been a simple API change in Apache 2.0 as well which I'd like to accomodate. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- 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 #10470: Authorization not read by getallheaders()
From: [EMAIL PROTECTED] Operating system: Linux (Mandrake 7.2) PHP version: 4.0.4pl1 PHP Bug Type: HTTP related Bug description: Authorization not read by getallheaders() I cannot read the Authorization header via getallheaders function. But if i use phpinfo() in the same generated page, the Authorization header is viewable. I act under Novell IChain Server eDirectory, and Authentification is used to give access to protect ressources. The script is the standard script shows as example for getallheaders and the phpinfo function that don't return the same data. Configure Line . /usr/local/bin/oraenv ./configure \ --prefix=/usr \ --localstatedir=/var/log/httpd \ --enable-track-vars \ --enable-force-cgi-redirect \ --enable-safe-mode \ --enable-magic-quotes \ --enable-sigchild \ --enable-inline-optimization \ --enable-trans-sid \ --enable-sysvsem \ --enable-sysvshm \ --enable-ftp \ --with-apxs=/usr/sbin/apxs \ --with-oracle \ --with-oci8 \ --with-regex=php \ --with-config-file-path=/etc/httpd/conf \ --with-ttf \ --with-ldap=/etc/openldap PHP.ini [PHP_4] engine =On ; short_open_tag= On; asp_tags=Off; precision=14; y2k_compliance= On; safe_mode=On safe_mode_exec_dir= safe_mode_allowed_env_vars = PHP_, ORACLE_ ; safe_mode_protected_env_vars = LD_LIBRARY_PATH, PATH; highlight.string= #DD highlight.comment = #FF8000 highlight.keyword = #007700 highlight.bg= #FF highlight.default = #BB highlight.html = #00 expose_php=Off; charset = iso-8859-1 ; This sets the charset for the default text/html type served up by PHP max_execution_time = 30 ; Maximum execution time of each script, in seconds memory_limit = 8388608 ; Maximum amount of memory a script may consume (8MB) error_reporting = 7; display_errors = On ; Print out errors (as a part of the HTML script) log_errors = On ; Log errors into a log file (server-specific log, stderr, or error_log (below)) track_errors= On ; Store the last error/warning message in $php_errormsg (boolean) error_prepend_string = font color=ff ; string to output before an error message error_append_string = /font; string to output after an error message error_log = /var/log/httpd/php_log ; log errors to specified file ;error_log = syslog ; log errors to syslog (Event Log on NT, not valid in Windows 95) warn_plus_overloading = On ; warn if the + operator is used with strings magic_quotes_gpc= Off; magic quotes for incoming GET/POST/Cookie data magic_quotes_runtime= Off ; magic quotes for runtime-generated data, e.g. data from SQL, from exec(), etc. magic_quotes_sybase = Off ; Use Sybase-style magic quotes (escape ' with '' instead of \') track_vars = On ; enable $HTTP_GET_VARS[], $HTTP_POST_VARS[] and $HTTP_COOKIE_VARS[] arrays ;auto_prepend_file = ;auto_append_file = ; ; Paths and Directories ; ; include_path=. ; UNIX: /path1:/path2 Windows: \path1;\path2 ;doc_root = ; the root of the php pages, used only if nonempty ;user_dir = ; the directory under which php opens the script using /~username, used only if nonempty ;upload_tmp_dir = ; temporary directory for HTTP uploaded files (will use system default if not specified) upload_max_filesize = 2097152 ; 2 Meg default limit on file uploads extension_dir = /usr/libexec/ ; directory in which the loadable extensions (modules) reside ;UNIX Extensions ;extension=pgsql.so ;extension=mysql.so ;extension=imap.so ;extension=ldap.so ;;; ; Module Settings ; ;;; [Syslog] define_syslog_variables = Off ; Whether or not to define the various syslog variables, ; e.g. $LOG_PID, $LOG_CRON, etc. Turning it off is a ; good idea performance-wise. In runtime, you can define ; these variables by calling define_syslog_variables() [mail function] SMTP= localhost ;for win32 only sendmail_from = [EMAIL PROTECTED];for win32 only sendmail_path = ;for unix only, may supply arguments as well (default is sendmail -t) [Debugger] debugger.host = localhost debugger.port = 7869 debugger.enabled= False [Logging] ; These configuration directives are used by the
Re: [PHP-DEV] 4.0.5: Merge Request
At 12:03 24/4/2001, Sascha Schumann wrote: On Tue, 24 Apr 2001, Zeev Suraski wrote: At 03:02 24/4/2001, Anil Madhavapeddy wrote: It a bit of a showstopper for pretty much all web-based mail clients like IMP - people have been reporting their logs being littered with segfaults for a while now actually. Ok then, merge it in, and looks like we'll have to have RC8 after all. There has been a simple API change in Apache 2.0 as well which I'd like to accomodate. The race between world peace and PHP 4.0.5 is tightening by the minute :) Anyway, let's say Wednesday evening (GMT) would be the last time to put in changes; RC8 goes out then; 4.0.5 goes out on Monday, unless there are serious show stoppers. Zeev -- 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 #10471: Warning: Access denied for user: 'john@BOB' (Using password: YES) in ./db_mysql
From: [EMAIL PROTECTED]
Operating system: Windows 98
PHP version: 4.0.4pl1
PHP Bug Type: MySQL related
Bug description: Warning: Access denied for user: 'john@BOB' (Using password: YES) in
./db_mysql
Have not had much luck with mysql (probably because i have only used ODBC)
Have followed installation instructions and mysql seems to be fine, heres my.ini:
[WinMySQLAdmin]
Server=C:/PROGRAM FILES/MYSQL/bin/mysqld-opt.exe
user=john
password=nirvana
[mysqld]
basedir=C:/PROGRAM FILES/MYSQL
#bind-address=192.168.1.6
datadir=C:/PROGRAM FILES/MYSQL/data
#language=C:/PROGRAM FILES/MYSQL/share/english
#slow query log#=
#tmpdir#=C:/Program Files/mysql/mytemp
#port=3306
#set-variable=key_buffer=16M
I have downloaded vbulletin by jelsoft and when going through the install steps it
comes up with the following error messages:
Warning: Access denied for user: 'john@BOB' (Using password: YES) in ./db_mysql.php on
line 31
Warning: Supplied argument is not a valid MySQL-Link resource in ./db_mysql.php on
line 37
The code looks like it creates a new db if an existing one is not found. But doesn't
even get there!
Have also tried setting up a reference to the db to be created (freeforum or
freewareforum in the config.php).
Heres db_mysql.php where the error occurred:
?php
// db class for mysql
// this class is used in all scripts
// do NOT fiddle unless you know what you are doing
class DB_Sql_vb {
var $database = ;
var $link_id = 0;
var $query_id = 0;
var $record = array();
var $errdesc= ;
var $errno = 0;
var $reporterror = 1;
var $server = 192.168.1.6;
var $user = john;
var $password = nirvana;
var $appname = vBulletin Lite;
var $appshortname = vBulletin Lite (cp);
function connect() {
// connect to db server
if ( 0 == $this-link_id ) {
if ($this-password==) {
$this-link_id=mysql_pconnect($this-server,$this-user);
} else {
$this-link_id=mysql_pconnect($this-server,$this-user,$this-password);
}
if (!$this-link_id) {
$this-halt(Link-ID == false, connect failed);
}
if ($this-database!=) {
if(!mysql_select_db($this-database, $this-link_id)) {
$this-halt(cannot use database .$this-database);
}
}
}
}
function geterrdesc() {
$this-error=mysql_error();
return $this-error;
}
function geterrno() {
$this-errno=mysql_errno();
return $this-errno;
}
function select_db($database=) {
// select database
if ($database!=) {
$this-database=$database;
}
if(!mysql_select_db($this-database, $this-link_id)) {
$this-halt(cannot use database .$this-database);
}
}
function query($query_string) {
// do query
$this-query_id = mysql_query($query_string,$this-link_id);
if (!$this-query_id) {
$this-halt(Invalid SQL: .$query_string);
}
return $this-query_id;
}
function fetch_array($query_id=-1) {
// retrieve row
if ($query_id!=-1) {
$this-query_id=$query_id;
}
$this-record = mysql_fetch_array($this-query_id);
return $this-record;
}
function free_result($query_id=-1) {
// retrieve row
if ($query_id!=-1) {
$this-query_id=$query_id;
}
return @mysql_free_result($this-query_id);
}
function query_first($query_string) {
// does a query and returns first row
$this-query($query_string);
$returnarray=$this-fetch_array($this-query_id);
$this-free_result($this-$query_id);
return $returnarray;
}
function data_seek($pos,$query_id=-1) {
// goes to row $pos
if ($query_id!=-1) {
$this-query_id=$query_id;
}
$status = mysql_data_seek($this-query_id, $pos);
return $status;
}
function num_rows($query_id=-1) {
// returns number of rows in query
if ($query_id!=-1) {
$this-query_id=$query_id;
}
return mysql_num_rows($this-query_id);
}
function insert_id() {
// returns last auto_increment field number assigned
return mysql_insert_id($this-link_id);
}
function halt($msg) {
$this-errdesc=mysql_error();
$this-errno=mysql_errno();
// prints warning message when there is an error
global $technicalemail;
$message=Database error in $this-appname: $msg\n;
$message.=mysql error: $this-errdesc\n;
$message.=mysql error number: $this-errno\n;
$message.=Date: .date(l dS of F Y h:i:s A).\n;
$message.=Script: .getenv(REQUEST_URI).\n;
$message.=Referer: .getenv(HTTP_REFERER).\n;
//mail ($technicalemail,$this-appshortname Database error!,$message);
if ($this-reporterror==1) {
echo \n!-- $message --\n;
echo /td/tr/table\npThere seems to have been a slight problem with the
database.\n;
echo Please try again by pressing the refresh button in your browser./p;
echo An E-Mail has been dispatched to our a
href=\mailto:$technicalemail\;Technical Staff/a, who you can also contact if the
[PHP-DEV] Bug #10471 Updated: Warning: Access denied for user: 'john@BOB' (Using password: YES) in ./db_mysql
ID: 10471
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: MySQL related
PHP Version: 4.0.4pl1
Assigned To:
Comments:
this is a bug database, not a support forum
please ask questions on the php-general mailing list
(to be found under support on php.net)
Previous Comments:
---
[2001-04-24 06:30:33] [EMAIL PROTECTED]
Have not had much luck with mysql (probably because i have only used ODBC)
Have followed installation instructions and mysql seems to be fine, heres my.ini:
[WinMySQLAdmin]
Server=C:/PROGRAM FILES/MYSQL/bin/mysqld-opt.exe
user=john
password=nirvana
[mysqld]
basedir=C:/PROGRAM FILES/MYSQL
#bind-address=192.168.1.6
datadir=C:/PROGRAM FILES/MYSQL/data
#language=C:/PROGRAM FILES/MYSQL/share/english
#slow query log#=
#tmpdir#=C:/Program Files/mysql/mytemp
#port=3306
#set-variable=key_buffer=16M
I have downloaded vbulletin by jelsoft and when going through the install steps it
comes up with the following error messages:
Warning: Access denied for user: 'john@BOB' (Using password: YES) in ./db_mysql.php on
line 31
Warning: Supplied argument is not a valid MySQL-Link resource in ./db_mysql.php on
line 37
The code looks like it creates a new db if an existing one is not found. But doesn't
even get there!
Have also tried setting up a reference to the db to be created (freeforum or
freewareforum in the config.php).
Heres db_mysql.php where the error occurred:
?php
// db class for mysql
// this class is used in all scripts
// do NOT fiddle unless you know what you are doing
class DB_Sql_vb {
var $database = ;
var $link_id = 0;
var $query_id = 0;
var $record = array();
var $errdesc= ;
var $errno = 0;
var $reporterror = 1;
var $server = 192.168.1.6;
var $user = john;
var $password = nirvana;
var $appname = vBulletin Lite;
var $appshortname = vBulletin Lite (cp);
function connect() {
// connect to db server
if ( 0 == $this-link_id ) {
if ($this-password==) {
$this-link_id=mysql_pconnect($this-server,$this-user);
} else {
$this-link_id=mysql_pconnect($this-server,$this-user,$this-password);
}
if (!$this-link_id) {
$this-halt(Link-ID == false, connect failed);
}
if ($this-database!=) {
if(!mysql_select_db($this-database, $this-link_id)) {
$this-halt(cannot use database .$this-database);
}
}
}
}
function geterrdesc() {
$this-error=mysql_error();
return $this-error;
}
function geterrno() {
$this-errno=mysql_errno();
return $this-errno;
}
function select_db($database=) {
// select database
if ($database!=) {
$this-database=$database;
}
if(!mysql_select_db($this-database, $this-link_id)) {
$this-halt(cannot use database .$this-database);
}
}
function query($query_string) {
// do query
$this-query_id = mysql_query($query_string,$this-link_id);
if (!$this-query_id) {
$this-halt(Invalid SQL: .$query_string);
}
return $this-query_id;
}
function fetch_array($query_id=-1) {
// retrieve row
if ($query_id!=-1) {
$this-query_id=$query_id;
}
$this-record = mysql_fetch_array($this-query_id);
return $this-record;
}
function free_result($query_id=-1) {
// retrieve row
if ($query_id!=-1) {
$this-query_id=$query_id;
}
return @mysql_free_result($this-query_id);
}
function query_first($query_string) {
// does a query and returns first row
$this-query($query_string);
$returnarray=$this-fetch_array($this-query_id);
$this-free_result($this-$query_id);
return $returnarray;
}
function data_seek($pos,$query_id=-1) {
// goes to row $pos
if ($query_id!=-1) {
$this-query_id=$query_id;
}
$status = mysql_data_seek($this-query_id, $pos);
return $status;
}
function num_rows($query_id=-1) {
// returns number of rows in query
if ($query_id!=-1) {
$this-query_id=$query_id;
}
return mysql_num_rows($this-query_id);
}
function insert_id() {
// returns last auto_increment field number assigned
return mysql_insert_id($this-link_id);
}
function halt($msg) {
$this-errdesc=mysql_error();
$this-errno=mysql_errno();
// prints warning message when there is an error
global $technicalemail;
$message=Database error in $this-appname: $msgn;
$message.=mysql error: $this-errdescn;
$message.=mysql error number: $this-errnon;
$message.=Date: .date(l dS of F Y h:i:s A).n;
$message.=Script: .getenv(REQUEST_URI).n;
$message.=Referer: .getenv(HTTP_REFERER).n;
//mail ($technicalemail,$this-appshortname Database
[PHP-DEV] Bug #10472: with session, IE not parse html header
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.3pl1 PHP Bug Type: *Session related Bug description: with session, IE not parse html header In php 4.0.3pl1, with session IE doesn't parse html header. only not using php, you can see IE page infomation. just connect www.php3.com with IE, and done browing, mouse right click and press p, then, you can see protocol, url, size, modified-date, etc. but if you connect any site using php session, you can't see any informatio of those. -- follow header is sample which is not using session HTTP/1.1 200 OK Date: Tue, 24 Apr 2001 10:33:33 GMT Server: Apache/1.3.14 (Unix) PHP/4.0.3pl1 mod_ssl/2.7.1 OpenSSL/0.9.6 X-Powered-By: PHP/4.0.3pl1 Connection: close Content-Type: text/html -- follow header is sample which is using session HTTP/1.1 200 OK Date: Tue, 24 Apr 2001 10:34:21 GMT Server: Apache/1.3.14 (Unix) PHP/4.0.3pl1 mod_ssl/2.7.1 OpenSSL/0.9.6 X-Powered-By: PHP/4.0.3pl1 Set-Cookie: IMID=407f81eb11d4a059c7bff457ecf87c05; path=/; domain=.yourdomain.com Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Connection: close Content-Type: text/html -- so i wondering what cause the different of header parsing with IE. and, I would like to know how to solve this problem in useing IE with php session. why -- Edit Bug report at: http://bugs.php.net/?id=10472edit=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] 4.0.5: Merge Request
On Tue, 24 Apr 2001, Zeev Suraski wrote: At 12:03 24/4/2001, Sascha Schumann wrote: On Tue, 24 Apr 2001, Zeev Suraski wrote: At 03:02 24/4/2001, Anil Madhavapeddy wrote: It a bit of a showstopper for pretty much all web-based mail clients like IMP - people have been reporting their logs being littered with segfaults for a while now actually. Ok then, merge it in, and looks like we'll have to have RC8 after all. There has been a simple API change in Apache 2.0 as well which I'd like to accomodate. The race between world peace and PHP 4.0.5 is tightening by the minute :) Anyway, let's say Wednesday evening (GMT) would be the last time to put in changes; RC8 goes out then; 4.0.5 goes out on Monday, unless there are serious show stoppers. Or someone else comes and says this tiny change is really needed by XXX software users around the world.. ? I think this should end now. Release 4.0.5 now as is. And roll out 4.0.6RC1. Or on next monday we'll have RC9.. --Jani -- 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 #10473: DSO loading and core dumped
From: [EMAIL PROTECTED] Operating system: Solaris 2.6 PHP version: 4.0.4pl1 PHP Bug Type: Apache related Bug description: DSO loading and core dumped I've tried to load the PHP 4.0.4pl1 shared object module(named libphp4.so). and I've captured the truss message. If I don't load the php DSO module, apache works very well. But whenever I tried to load the php DSO module, apache core dumped. When I examine the truss message, I think there is no problem to load the php DSO module. But, other function causes the core dump. I compiled the php DSO module as follows ./configure --with-apxs=/usr/local/apache/bin/apxs \ --enable-debug Is this a php's bug or my mistake? * truss message * --- open(/web/httpd/libexec/libphp4.so, O_RDONLY) = 5 fstat(5, 0xEFFFB20C)= 0 mmap(0x, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xEF78 mmap(0x, 1253376, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xEF40 munmap(0xEF50, 57344) = 0 mmap(0xEF50E000, 57580, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 5, 1040384) = 0xEF50E000 open(/dev/zero, O_RDONLY) = 6 mmap(0xEF51E000, 76524, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 6, 0) = 0xEF51E000 mmap(0x, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 6, 0) = 0xEF67 close(5)= 0 open(/usr/lib/libpam.so.1, O_RDONLY) = 5 fstat(5, 0xEFFFB14C)= 0 mmap(0xEF78, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 5, 0) = 0xEF78 mmap(0x, 90112, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xEF65 munmap(0xEF656000, 57344) = 0 mmap(0xEF664000, 7087, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 5, 16384) = 0xEF664000 close(5)= 0 open(/usr/lib/libresolv.so.2, O_RDONLY) = 5 fstat(5, 0xEFFFB14C)= 0 mmap(0xEF78, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 5, 0) = 0xEF78 mmap(0x, 139264, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xEF55 munmap(0xEF55E000, 57344) = 0 mmap(0xEF56C000, 6819, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 5, 49152) = 0xEF56C000 mmap(0xEF56E000, 11524, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 6, 0) = 0xEF56E000 close(5)= 0 open(/usr/lib/libm.so.1, O_RDONLY)= 5 fstat(5, 0xEFFFB14C)= 0 mmap(0xEF78, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 5, 0) = 0xEF78 mmap(0x, 155648, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xEF3D munmap(0xEF3E6000, 57344) = 0 mmap(0xEF3F4000, 7309, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 5, 81920) = 0xEF3F4000 close(5)= 0 mprotect(0xEF40, 1045756, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0xEF40, 1045756, PROT_READ|PROT_EXEC) = 0 close(6)= 0 ... stat(/web/httpd/conf.www/conf/srm.conf, 0xE838) = 0 open(/web/httpd/conf.www/conf/srm.conf, O_RDONLY) = 3 fstat(3, 0xE740)= 0 fstat64(3, 0xEFFFD590) = 0 ioctl(3, TCGETA, 0xEFFFD51C)Err#25 ENOTTY read(3, #\n # T h i s c o n.., 8192) = 1599 read(3, 0x000C4A5C, 8192) = 0 llseek(3, 0, SEEK_CUR) = 1599 close(3)= 0 stat(/web/httpd/conf.www/conf/access.conf, 0xE838) = 0 open(/web/httpd/conf.www/conf/access.conf, O_RDONLY) = 3 fstat(3, 0xE740)= 0 fstat64(3, 0xEFFFD590) = 0 ioctl(3, TCGETA, 0xEFFFD51C)Err#25 ENOTTY read(3, #\n # T h i s c o n.., 8192) = 1509 read(3, 0x000C4A5C, 8192) = 0 llseek(3, 0, SEEK_CUR) = 1509 close(3)= 0 Incurred fault #6, FLTBOUNDS %pc = 0xEF44DC64 siginfo: SIGSEGV SEGV_MAPERR addr=0x0018 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0x0018 *** process killed *** * gdb stack log * -- #0 0xef34dc64 in ?? () #1 0xef35b7b0 in ?? () #2 0xef6bed44 in ?? () #3 0xef6c2824 in ?? () #4 0xef6c2ee0 in ?? () #5 0xef6d41c8 in ?? () Cannot access memory at address 0x1 -- Edit Bug report at: http://bugs.php.net/?id=10473edit=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 #7782 Updated: Cannot use PATH_INFO fully with php isapi
ID: 7782
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Feature/Change Request
Description: Cannot use PATH_INFO fully with php isapi
Hi,
Due to some problems we have had with the isapi version of php under IIS,
we have made some changes in the sourcecode of this isapi module to support
Apache style PATH_INFO and PATH_TRANSLATED variables. We tested it with
IIS 5 on Windows 2000 Server.
(See also Bug number 7782).
What we have done:
- In the function init_request_info we have added some code which will
translate the path_translated server variable to a path
which points to the requested script on disk.
- In the function sapi_isapi_register_server_variables2 we have added
some translations for the variables $PATH_INFO and $PATH_TRANSLATED
PATH_INFO will now be translated from:
/script/path/script.php/some/non/existing/path
to
/some/non/existing/path
PATH_TRANSLATED will be translated from:
d:\Inetpub\wwwroot\script.php\some\non\existing\path
to
d:\Inetpub\wwwroot\script.php
- We have added a function named sapi_isapi_get_server_var
which will retrieve the requested server variable and returns
a pointer to it. This function has been added to make things more
structured (because of the need to check for a INSUFFICIENT BUFFER
error).
We have made a patch file of these changes against the cvs version 1.7 of
php4isapi.c. This path file is attached to this e-mail.
Please keep in mind that we did not have the opportunity to test this fix with Zeus.
We hope you can/will commit this fix to the php cvs repository.
With kind regards,
Gijsbert te Riet,
Muze.
[EMAIL PROTECTED]
patch:
16a17
| IIS PATH_TRANSLATED / PATH_INFO fix: Gijsbert te Riet [EMAIL PROTECTED] |
83a85
PATH_INFO,
88a91
REQUEST_URI,
464a468,492
static char *sapi_isapi_get_server_var(LPEXTENSION_CONTROL_BLOCK lpECB, char
*varname, DWORD *buffer_len) {
char*buffer;
buffer=emalloc(*buffer_len=ISAPI_SERVER_VAR_BUF_SIZE);
if (!lpECB-GetServerVariable(lpECB-ConnID, varname, buffer, buffer_len)) {
if (GetLastError() == ERROR_INSUFFICIENT_BUFFER) {
buffer = (char *) erealloc(buffer, *buffer_len);
if (!lpECB-GetServerVariable(lpECB-ConnID, varname, buffer,
buffer_len)) {
efree(buffer);
buffer=0;
}
} else {
efree(buffer);
buffer=0;
}
}
return buffer;
}
468,469c496
DWORD variable_len;
char static_variable_buf[ISAPI_SERVER_VAR_BUF_SIZE];
---
DWORD varsize, varbufsize;
470a498
char *var_buf1, *var_buf2;
473,478c501,508
variable_len = ISAPI_SERVER_VAR_BUF_SIZE;
if (lpECB-GetServerVariable(lpECB-ConnID, *p, static_variable_buf,
variable_len)
static_variable_buf[0]) {
php_register_variable(*p, static_variable_buf,
track_vars_array ELS_CC PLS_CC);
if (recorded_values) {
recorded_values[p-server_variables] =
estrndup(static_variable_buf, variable_len);
---
if (variable_buf=sapi_isapi_get_server_var(lpECB, *p, varsize)) {
// translate PATH_INFO to Apache compatible PATH_INFO
if (strcmp(*p, PATH_INFO) == 0) {
if (var_buf1=sapi_isapi_get_server_var(lpECB,
SCRIPT_NAME, varbufsize)) {
memmove(variable_buf, variable_buf +
strlen(var_buf1), strlen(variable_buf) - strlen(var_buf1) + 1);
efree(var_buf1);
}
480,484c510,519
} else if (GetLastError() == ERROR_INSUFFICIENT_BUFFER) {
variable_buf = (char *) emalloc(variable_len);
if (lpECB-GetServerVariable(lpECB-ConnID, *p, variable_buf,
variable_len)
variable_buf[0]) {
php_register_variable(*p, variable_buf,
track_vars_array ELS_CC PLS_CC);
---
// translate PATH_TRANSLATED to Apache compatible
PATH_TRANSLATED
if (strcmp(*p, PATH_TRANSLATED) == 0) {
if (var_buf1=sapi_isapi_get_server_var(lpECB,
PATH_INFO, varbufsize)) {
if (var_buf2=sapi_isapi_get_server_var(lpECB,
SCRIPT_NAME, varbufsize)) {
variable_buf[strlen(variable_buf)-(strlen(var_buf1)-strlen(var_buf2))]='\0';
Re: [PHP-DEV] RE: [PHP-WIN] PHP Search
Manesh: This, the php-dev list, is for discussion of the development of the PHP Language itself. Questions pertaining to development *USING* the PHP language should be addressed to [EMAIL PROTECTED] - Original Message - From: Manesh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 23, 2001 22:22 Subject: [PHP-DEV] RE: [PHP-WIN] PHP Search i need the full source code, to search over 700 pages and the text! -Original Message- From: Joe Brown [mailto:[EMAIL PROTECTED]] Sent: Monday, April 23, 2001 10:01 PM To: Manesh Subject: Re: [PHP-WIN] PHP Search Here, does this help? (*) search ;-) -Joe - Original Message - From: Manesh [EMAIL PROTECTED] Newsgroups: php.windows Sent: Monday, April 23, 2001 7:06 PM Subject: RE: [PHP-WIN] PHP Search i need to include it in a HTML page -Original Message- From: John Meyer [mailto:[EMAIL PROTECTED]] Sent: Monday, April 23, 2001 7:04 PM To: [EMAIL PROTECTED] Subject: Re: [PHP-WIN] PHP Search Have you written any code? --- Manesh [EMAIL PROTECTED] wrote: I need one to search my site, and the web, it need to be like a radio button. PLEASE PLEASE PLEASE -- PHP Windows 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] __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ -- PHP Windows 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 Windows 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]
Re: [PHP-DEV] 4.0.5: Merge Request
A reproducible crash bug in a mainstream module is a show stopper IMHO... Zeev At 14:16 24/4/2001, Jani Taskinen wrote: On Tue, 24 Apr 2001, Zeev Suraski wrote: At 12:03 24/4/2001, Sascha Schumann wrote: On Tue, 24 Apr 2001, Zeev Suraski wrote: At 03:02 24/4/2001, Anil Madhavapeddy wrote: It a bit of a showstopper for pretty much all web-based mail clients like IMP - people have been reporting their logs being littered with segfaults for a while now actually. Ok then, merge it in, and looks like we'll have to have RC8 after all. There has been a simple API change in Apache 2.0 as well which I'd like to accomodate. The race between world peace and PHP 4.0.5 is tightening by the minute :) Anyway, let's say Wednesday evening (GMT) would be the last time to put in changes; RC8 goes out then; 4.0.5 goes out on Monday, unless there are serious show stoppers. Or someone else comes and says this tiny change is really needed by XXX software users around the world.. ? I think this should end now. Release 4.0.5 now as is. And roll out 4.0.6RC1. Or on next monday we'll have RC9.. --Jani -- 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] 4.0.5: Merge Request
At 03:59 PM 4/24/2001 +0300, Zeev Suraski wrote: A reproducible crash bug in a mainstream module is a show stopper IMHO... I think you mean in a mainstream module and in a situation which has a high chance of happening. Crash bugs which are 1 in a million don't necessarily need to be show stoppers. Andi -- 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] 4.0.5: Merge Request
Not necessarily; Crash bugs can very often lead to security issues. Of course, it's a clearer cut if it's in a situation which is very likely to happen. Zeev At 17:09 24/4/2001, Andi Gutmans wrote: At 03:59 PM 4/24/2001 +0300, Zeev Suraski wrote: A reproducible crash bug in a mainstream module is a show stopper IMHO... I think you mean in a mainstream module and in a situation which has a high chance of happening. Crash bugs which are 1 in a million don't necessarily need to be show stoppers. Andi -- 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] 4.0.5: Merge Request
On Tue, Apr 24, 2001 at 12:26:34PM +0300, Zeev Suraski wrote: The race between world peace and PHP 4.0.5 is tightening by the minute :) Anyway, let's say Wednesday evening (GMT) would be the last time to put in changes; RC8 goes out then; 4.0.5 goes out on Monday, unless there are serious show stoppers. And I assume the 4.0.5 release will be based on the RC8 tag (unless there's a strong reason otherwise, of course). -- 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]
Re: [PHP-DEV] 4.0.5: Merge Request
Well you want me to merge the foreach() fix then? I don't because I prefer it being tested for a while so that we don't have a pl1. I don't think we fix all crash bugs every release. Mainly buffer overflows are dangerous. Not double free()'s or de-referencing NULL pointers. But of course, a lot of crashes are potentially dangerous but we would never have any releases if we'd make sure that there's no chance PHP can crash, ever. Andi At 04:12 PM 4/24/2001 +0300, you wrote: Not necessarily; Crash bugs can very often lead to security issues. Of course, it's a clearer cut if it's in a situation which is very likely to happen. Zeev At 17:09 24/4/2001, Andi Gutmans wrote: At 03:59 PM 4/24/2001 +0300, Zeev Suraski wrote: A reproducible crash bug in a mainstream module is a show stopper IMHO... I think you mean in a mainstream module and in a situation which has a high chance of happening. Crash bugs which are 1 in a million don't necessarily need to be show stoppers. Andi -- 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] 4.0.5 release
RC7 still appends a binary zero to every element in the array returned by get_defined_functions(). IIRC Andrei said he fixed it (but maybe in HEAD only?). Seems like it'd be easy to fix, shouldn't it be done for 4.0.5? At 22:23 23.4. 2001, Zeev Suraski wrote the following: -- Unless someone screams in the next couple of hours - no. What Jani said as a joke, initially, makes pretty good sense to me - release 4.0.5, and aim to start the 4.0.6 release process in the very near future. There've been tons of changes since 4.0.5 already, even though 4.0.5 has no showstoppers. Zeev At 23:28 23/4/2001, Jason Greene wrote: JW, whats the current release schedule plans for 4.0.5, are we going to have an RC8? -Jason -- 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] -- 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] --end of quote-- [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List 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] Fwd: [PHP-CVS] cvs: php4(PHP_4_0_5) /ext/standard array.c
I see it in RC7.
On Tue, 24 Apr 2001, Andi Gutmans wrote:
Looks like it got merged before RC7.
Can you check if your source includes this fix?
From: Andrei Zmievski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Mon, 02 Apr 2001 16:12:07 -
Subject: [PHP-CVS] cvs: php4(PHP_4_0_5) /ext/standard array.c
andrei Mon Apr 2 09:12:07 2001 EDT
Modified files: (Branch: PHP_4_0_5)
/php4/ext/standard array.c
Log:
MFH
Index: php4/ext/standard/array.c
diff -u php4/ext/standard/array.c:1.101 php4/ext/standard/array.c:1.101.2.1
--- php4/ext/standard/array.c:1.101 Mon Mar 12 02:14:00 2001
+++ php4/ext/standard/array.c Mon Apr 2 09:12:06 2001
@@ -21,7 +21,7 @@
+--+
*/
-/* $Id: array.c,v 1.101 2001/03/12 10:14:00 stas Exp $ */
+/* $Id: array.c,v 1.101.2.1 2001/04/02 16:12:06 andrei Exp $ */
#include php.h
#include php_ini.h
@@ -2195,7 +2195,7 @@
switch (zend_hash_get_current_key_ex(target_hash,
string_key, str_key_len, num_key, 1, pos)) {
case HASH_KEY_IS_STRING:
Z_STRVAL_P(data) = string_key;
- Z_STRLEN_P(data) = str_key_len;
+ Z_STRLEN_P(data) = str_key_len-1;
Z_TYPE_P(data) = IS_STRING;
break;
case HASH_KEY_IS_LONG:
--
PHP CVS 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]
-Andrei
A room without books is like a body without a soul.
-- Marcus Tullius Cicero (106-43 B.C.)
--
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] 4.0.5 release
On Tue, 24 Apr 2001, Cynic wrote: RC7 still appends a binary zero to every element in the array returned by get_defined_functions(). IIRC Andrei said he fixed it (but maybe in HEAD only?). Seems like it'd be easy to fix, shouldn't it be done for 4.0.5? It's been merged into the release branch. -Andrei Everything should be made as simple as possible, but not simpler. -- Albert Einstein -- 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] 4.0.5 RC7 and TRANS_SID under Win32
Hello... I'm banging around on PHP 4.0.5 RC7 Win32 (Apache module), and I'm having great difficultly getting the TRANS_SID feature to work. I have one web application which depends heavily on it, and it's unusable under 4.0.5RC7. Has anyone else been experiencing this difficultly? - Matt -- 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] 4.0.5 RC7 and TRANS_SID under Win32
Did this work in the past? If so, any idea when it stopped working? Andi At 10:13 AM 4/24/2001 -0400, Matt White wrote: Hello... I'm banging around on PHP 4.0.5 RC7 Win32 (Apache module), and I'm having great difficultly getting the TRANS_SID feature to work. I have one web application which depends heavily on it, and it's unusable under 4.0.5RC7. Has anyone else been experiencing this difficultly? - Matt -- 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]
Re: [PHP-DEV] 4.0.5: Merge Request
At 17:24 24/4/2001, Andi Gutmans wrote: Well you want me to merge the foreach() fix then? I don't because I prefer it being tested for a while so that we don't have a pl1. The plan is to release 4.0.5 four days after RC8. I don't think we fix all crash bugs every release. Mainly buffer overflows are dangerous. Not double free()'s or de-referencing NULL pointers. But of course, a lot of crashes are potentially dangerous but we would never have any releases if we'd make sure that there's no chance PHP can crash, ever. A known, easily reproducible crash is always more dangerous... I have no doubt that PHP's code base includes quite a few different crashes today, but at least they're not known. Zeev -- 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 in objects+XML
Hi!
Maybe, I'm not so correct, or something else, but. Try to run the
script (php 4.0.6-dev).
Compiled with:
./configure --with-sablot
--with-dom --with-gettext --with-jpeg-dir=/usr --with-pops
--with-xml=/usr/local --with-gdbm=/usr/local --enable-gd-native-ttf
--with-gd --with-freetype-dir --with-mysql=/usr/local/mysql
--with-png-dir=/usr/local --enable-sysvshm=yes --enable-sysvsem=yes
--enable-debug=no
gcc, linux, glibc2*, latest sablot, expat, etc.
--- Script
?
$Bad=0; // try to set it to 1 for segfault
$taggz[0]=table_here;
$taggz[1]=mydir;
$functinz['table_here']=my_func;
$functinz['mydir']=my_func;
error_reporting(E_ALL);
Function my_func($atr){
echo(Variable:-);
var_dump($atr);
}
class my_xml {
var $functinz;
var $tagz;
var $parser;
var $parzed;
function tag_open($parser,$tag,$attribz) {
echo(+tagopen\n);
$atr=$attribz;
if(in_array($tag,$this-tagz))
{
echo(Bad girlz\n);
// var_dump($atr);
echo(\n);
$this-parzed.=Qtes;
//call_user_func($this-functinz[$tag],$atr);
} else {
$this-parzed.=$tag;
if (isset($atr)) {
echo(Bag giez\n);
// var_dump($atr);
if(is_array($atr))
{
echo(A\n);
while (list($k, $v) = each($atr)) {
$this-parzed.= $k=\$v\;
}
}
} // is set
$this-parzed.=;
} // else
echo(End\n);
}
function my_xml($tags, $func_array) {
global $Bad;
$this-parzed=;
$this-parser = xml_parser_create();
if($Bad)xml_set_object($this-parser,$this);
xml_set_element_handler($this-parser,tag_open,tag_close);
xml_set_character_data_handler($this-parser,cdata);
xml_parser_set_option($this-parser, XML_OPTION_CASE_FOLDING, false);
$this-functinz=$func_array;
$this-tagz=$tags;
}
function cdata($parser,$cdata) {
echo(+d\n);
$this-parzed.=$cdata;
}
function tag_close($parser,$tag) {
echo(+tagclose\n);
if(in_array($tag,$this-tagz)) {
} else {
$this-parzed.=/$tag;
}
}
function parze($data) {
xml_parse($this-parser,$data);
return $this-parzed;
}
}
$a=new my_xml($taggz,$functinz);
if(!$Bad) xml_set_object($a-parser,$a);
$e=$a-parze(
doka
a href=\http://www.kiae.su\;Buka
table_here ID=\958955897\fgkljgkljgkljg/table_here
/a
table_here ID=\3\fkfjhjkhkjhkjfhff/table_here
\n);
xml_parser_free($a-parser);
echo($e);
echo(H\n);
?
--
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] 4.0.5: Merge Request
At 12:03 24/4/2001, Sascha Schumann wrote: On Tue, 24 Apr 2001, Zeev Suraski wrote: At 03:02 24/4/2001, Anil Madhavapeddy wrote: It a bit of a showstopper for pretty much all web-based mail clients like IMP - people have been reporting their logs being littered with segfaults for a while now actually. Ok then, merge it in, and looks like we'll have to have RC8 after all. There has been a simple API change in Apache 2.0 as well which I'd like to accomodate. The race between world peace and PHP 4.0.5 is tightening by the minute :) Anyway, let's say Wednesday evening (GMT) would be the last time to put in changes; RC8 goes out then; 4.0.5 goes out on Monday, unless there are serious show stoppers. Or someone else comes and says this tiny change is really needed by XXX software users around the world.. ? An easily reproducable segfault in a common PHP extension is a serious issue which could lead to potential security breaches and thus lots of bad mojo from nasty bugtraq postings. If we know about such a segfault and we have a fix and go ahead and release a stable package without this fix then our entire QA process is a joke. If we find such bugs before a release, we fix them. That's what the process is for. -Rasmus -- 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 #10466 Updated: hidden '.' files don't work with file_exists()
ID: 10466
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Closed
Status: Bogus
Bug Type: Filesystem function related
PHP Version: 4.0.4pl1
Assigned To:
Comments:
Previous Comments:
---
[2001-04-23 17:13:21] [EMAIL PROTECTED]
Usually we like to have more information than 'doesn't work'. :)
But for the moment, what happens if you quote your strings?
i.e.:
if (file_exists('/file/names/must/be/.quoted.txt')) {
. . .
}
---
[2001-04-23 17:02:22] [EMAIL PROTECTED]
file_exists () seems to get confused with 'hidden' files, starting with '.' (dot).
this works fine:
--
if(file_exists(test/normal-file)) {
die (error message);
}
this does not work:
--
if(file_exists(test/.hidden-file)) {
die (error message);
}
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10466edit=2
--
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 #10466 Updated: hidden '.' files don't work with file_exists()
ID: 10466
User Update by: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Filesystem function related
Description: hidden '.' files don't work with file_exists()
single quotes solved it.
thanks...
Previous Comments:
---
[2001-04-23 18:46:50] [EMAIL PROTECTED]
single quotes works fine. thanks!
also, could be a bug, but i got it to work by having it ~follow~ a symbolic link.
it didn't check that the link existed, it checked the the place the link pointed to
existed.
could be a security issue.
thanks... atom
---
[2001-04-23 17:13:21] [EMAIL PROTECTED]
Usually we like to have more information than 'doesn't work'. :)
But for the moment, what happens if you quote your strings?
i.e.:
if (file_exists('/file/names/must/be/.quoted.txt')) {
. . .
}
---
[2001-04-23 17:02:22] [EMAIL PROTECTED]
file_exists () seems to get confused with 'hidden' files, starting with '.' (dot).
this works fine:
--
if(file_exists(test/normal-file)) {
die (error message);
}
this does not work:
--
if(file_exists(test/.hidden-file)) {
die (error message);
}
---
Full Bug description available at: http://bugs.php.net/?id=10466
--
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 #10474: wrong object in an example, german doc
From: [EMAIL PROTECTED] Operating system: FreeBSD PHP version: 4.0.2 PHP Bug Type: Documentation problem Bug description: wrong object in an example, german doc function.mysql-fetch-field.html WRONG: echo PRE blob: $meta - blob max_length: $meta - max_length multiple_key: $meta - multiple_key name: $meta - name not_null: $meta - not_null numeric: $meta - numeric primary_key: $meta - primary_key table:$meta - table type: $meta - type unique_key: $meta - unique_key unsigned: $meta - unsigned zerofill: $meta - zerofill /PRE; OK: echo PRE blob: $meta-blob max_length: $meta-max_length multiple_key: $meta-multiple_key name: $meta-name not_null: $meta-not_null numeric: $meta-numeric primary_key: $meta-primary_key table:$meta-table type: $meta-type unique_key: $meta-unique_key unsigned: $meta-unsigned zerofill: $meta-zerofill /PRE; -- Edit Bug report at: http://bugs.php.net/?id=10474edit=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] Bug in objects+XML
On Tue, Apr 24, 2001 at 08:00:47PM +0400, Vadka wrote:
?
$Bad=0; // try to set it to 1 for segfault
$taggz[0]=table_here;
$taggz[1]=mydir;
$functinz['table_here']=my_func;
$functinz['mydir']=my_func;
error_reporting(E_ALL);
Function my_func($atr){
echo(Variable:-);
var_dump($atr);
}
class my_xml {
var $functinz;
var $tagz;
var $parser;
var $parzed;
[trimmed]
Would you say this is the same problem that I reported a while
back?
http://www.php.net/bugs.php?id=6175
--
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]
Re: [PHP-DEV] Bug in objects+XML
On Tue, 24 Apr 2001, Jon Parise wrote: [trimmed] Would you say this is the same problem that I reported a while back? http://www.php.net/bugs.php?id=6175 Yes, it is, as I can see. The problem remains. For now, I have no so much time to hack it, but it seems that the pointer is assumed to the pointer before it's real initialization(class init) and this notation could not work in a proper way. -- 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] Bug in objects+XML
More, calling xml_parse_into_struct after normal xml_parse cause the segfault too (repeating of xml_parse will cause no error). -- 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 #10475: Array returned by str_replace unusable.
From: [EMAIL PROTECTED] Operating system: FreeBSD PHP version: 4.0.4pl1 PHP Bug Type: *Function Specific Bug description: Array returned by str_replace unusable. See http://sbw.sbw.org/str_replace/. str_replace(-string-, -string-, -array-) should return an array. It appears that it does so, but when the returned array is passed to implode or each, PHP issues warnings: Bad arguments to implode() Variable passed to each() is not an array or object -- Edit Bug report at: http://bugs.php.net/?id=10475edit=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 #10475 Updated: Array returned by str_replace unusable.
ID: 10475
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Function Specific
PHP Version: 4.0.4pl1
Assigned To:
Comments:
It works in latest CVS.
$input = array('foobar', 'barhop');
var_dump(implode(' : ', str_replace('bar', '---', $input)));
Output:
string(15) foo--- : ---hop
Previous Comments:
---
[2001-04-24 13:06:09] [EMAIL PROTECTED]
See http://sbw.sbw.org/str_replace/.
str_replace(-string-, -string-, -array-) should return an array.
It appears that it does so, but when the returned array is passed to implode or each,
PHP issues warnings:
Bad arguments to implode()
Variable passed to each() is not an array or object
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10475edit=2
--
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 #10476: search ofonline documentation
From: [EMAIL PROTECTED] Operating system: RedHat 6.2 PHP version: 4.0.4pl1 PHP Bug Type: Documentation problem Bug description: search ofonline documentation The search engine are not working in www.php.net. -- Edit Bug report at: http://bugs.php.net/?id=10476edit=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 #10476 Updated: search ofonline documentation
ID: 10476 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Bogus Bug Type: Documentation problem PHP Version: 4.0.4pl1 Assigned To: Comments: Please report this to [EMAIL PROTECTED] This site is for reporting bugs in PHP. Thx for this notification. Derick Previous Comments: --- [2001-04-24 13:42:40] [EMAIL PROTECTED] The search engine are not working in www.php.net. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10476edit=2 -- 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 #10477: ob_start('function') is called before trans-sid is applied, not after
From: [EMAIL PROTECTED]
Operating system: linux 2.2
PHP version: 4.0.4pl1
PHP Bug Type: Output Control
Bug description: ob_start('function') is called before trans-sid is applied, not after
?php
if (isset($PATH_INFO))
{
$var = explode('/', $PATH_INFO);
for($c = 1; $c count($var); $c += 2)
{
$$var[$c] = $var[$c + 1];
$HTTP_GET_VARS[$var[$c]] = $var[$c + 1];
}
}
function fix_session($output)
{
global $SID;
$o_sid = '?'. $SID;
$n_sid = '/'. str_replace('=', '/', $SID);
$output = substr_count($output, $o_sid) .'br'. str_replace($o_sid,
$n_sid, $output);
return $output;
}
ob_start('fix_session');
?
I want to convert.
index.php?PHPSESSID=xx
-
index.php/PHPSESSID/xx
this code will convert hardcoded SID links but not trans-sid. this must be caused
because fix_session() is being called 'before' trans-sid is applied, it should be
called after. no ? what is strange is that if I use ob_start() to gzip my content
trans-sid is astill applied, but I dont know how this is done to compressed code I
will have to check this.
Chris Lee
[EMAIL PROTECTED]
--
Edit Bug report at: http://bugs.php.net/?id=10477edit=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 #10478: --with-mcrypt leads to configure: error: Sorry
From: [EMAIL PROTECTED] Operating system: Redhat 7.0 PHP version: 4.0.4pl1 PHP Bug Type: *Configuration Issues Bug description: --with-mcrypt leads to configure: error: Sorry My configure line used to work on a redhat 6.2 system. Now I have upgraded, it does not work any more, it seems not to find any function in the mcrypt library... configure line: -- ./configure --with-mysql \ --enable-track-vars \ --with-apache=../../../apache/make/apache_1.3.19 \ --prefix=/home/local/php \ --with-config-file-path=/home/local/php/conf \ --without-gd \ --disable-debug \ --with-mhash=/home/local/mhash-0.8.9 \ --with-mcrypt=mcrypt-2.4.10 \ --with-mm=/home/local/mm \ --enable-trans-sid \ --with-dom= \ --with-magic-quotes \ --with-zlib-dir=/home/local/zlib \ --with-imap=/home/local/libimap configure output: --- (...) Configuring extensions checking for ASPELL support... no checking for bc style precision math functions... no checking for BZip2 support... no checking whether to enable calendar conversion support... no checking CCVS Support... no checking whether to include cpdflib support... no checking whether to enable ctype support... no checking for CURL support... no checking for CyberCash support... no checking whether to enable DAV support through mod_dav... no checking whether to include old xDBM support... no checking whether to enable DBA... no checking for GDBM support... no checking for NDBM support... no checking for Berkeley DB2 support... no checking for Berkeley DB3 support... no checking for DBM support... no checking for CDB support... no checking whether to enable DBA interface... no checking whether to enable the bundled dbase library... no checking for DOM support... yes checking for libxml version... = 2.2.7 checking for libz needed by libxml ... already zlib support checking whether to enable exif support... no checking for fdftk support... no checking whether to enable the bundled filePro support... no checking whether to add fribidi support... no checking whether to enable FTP support... no checking whether to enable truetype string function in gd... no checking for libjpeg (needed by gd-1.8+)... no configure: warning: If configure fails try --with-jpeg-dir=DIR checking for libXpm (needed by gd-1.8+)... no configure: warning: If configure fails try --with-xpm-dir=DIR checking whether to include GD support... no checking whether to include GNU gettext support... no checking for gmp support... no checking for Hyperwave support... no checking for ICAP support... no checking for Kerberos support in IMAP... no checking for SSL support in IMAP... no checking for IMAP support... yes checking for Informix support... no checking for Ingres II support... no checking for InterBase support... no checking for ircg support... no checking for Java support... no checking whether to include LDAP support... no checking for MCAL support... no checking for mcrypt support... yes checking for init_mcrypt in -lmcrypt... no checking for mcrypt_module_open in -lmcrypt... no configure: error: Sorry -- Edit Bug report at: http://bugs.php.net/?id=10478edit=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] hebrew error messages?
Parse error: parse error, expecting `T_PAAMAYIM_NEKUDOTAYIM' or `'('' in
/path/to/file.php on line 246
Zeev/Andi ... ? :)
- Colin
--
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] hebrew error messages?
On Tue, 24 Apr 2001, Colin Viebrock wrote:
Parse error: parse error, expecting `T_PAAMAYIM_NEKUDOTAYIM' or `'('' in
/path/to/file.php on line 246
Zeev/Andi ... ? :)
Read expecting '::' or '('.
-Andrei
Commitment, n.:
Commitment can be illustrated by a breakfast of ham and eggs. The chicken
was involved, the pig was committed.
--
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] Bug in objects+XML
On Tue, Apr 24, 2001 at 08:00:47PM +0400, Vadka wrote:
Hi!
frag
to get this working you have to say:
class hallo {
//...
function hallo($bla) {
// ^ this is important!
$this-parser = xml_parser_create();
xml_set_object($this-parser,$this);
// ...
}
}
and then instantiate using:
$a = new hallo($bla);
// ^ important.
the problem here a cyclic references _and_ $this _not_ being
the instantiated object (unless u use this ugly ampersand
hack as illustrated)
tc
--- Script
frag
--
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 #10479: Failure to recognize libsybdb.so
From: [EMAIL PROTECTED] Operating system: Solaris PHP version: 4.0 Latest CVS (24/04/2001) PHP Bug Type: *Configuration Issues Bug description: Failure to recognize libsybdb.so Despite specification of --with-sybase=/sybase_dir , libphp4.so attempts to load /usr/local/lib/libsybdb.so , instead of /sybase_dir/lib/libsybdb.so . We checked the configure script, and it does configure the $SYBASE_LIBDIR correctly, so the problem must be in the make. Verified that this is the actual problem by putting a symlink in /usr/local/lib , libsybdb.so - /sybase_dir/lib/libsybdb.so . -- Edit Bug report at: http://bugs.php.net/?id=10479edit=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 #10480: ISAPI module conflicts with asp.dll
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.0.4pl1 PHP Bug Type: IIS related Bug description: ISAPI module conflicts with asp.dll I'm having the problem that has been reported before (looking at past bug reports) about the isapi .dll conflicting with asp.dll. When I run a php page, all successive attempts to run an asp page fail with a 500 Server Application Error under IIS5.0. Rebooting solves this problem until a php page is again executed. I have been able to verify that this does not affect php.exe - only the .dll seems to conflict. Still, the performance gain in running php as a SAPI instead of a CGI module would be nice! Scott Gould -- Edit Bug report at: http://bugs.php.net/?id=10480edit=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 #10480 Updated: ISAPI module conflicts with asp.dll
ID: 10480 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: IIS related Description: ISAPI module conflicts with asp.dll Original comment: I'm having the problem that has been reported before (looking at past bug reports) about the isapi .dll conflicting with asp.dll. When I run a php page, all successive attempts to run an asp page fail with a 500 Server Application Error under IIS5.0. Rebooting solves this problem until a php page is again executed. I have been able to verify that this does not affect php.exe - only the .dll seems to conflict. Still, the performance gain in running php as a SAPI instead of a CGI module would be nice! Scott Gould FOLLOWUP: The following message appears the in the event log when asp.dll stops responding: The server failed to load application '/LM/W3SVC/6/Root'. The error was 'The application called an interface that was marshalled for a different thread.'. Previous Comments: --- [2001-04-24 15:49:07] [EMAIL PROTECTED] I'm having the problem that has been reported before (looking at past bug reports) about the isapi .dll conflicting with asp.dll. When I run a php page, all successive attempts to run an asp page fail with a 500 Server Application Error under IIS5.0. Rebooting solves this problem until a php page is again executed. I have been able to verify that this does not affect php.exe - only the .dll seems to conflict. Still, the performance gain in running php as a SAPI instead of a CGI module would be nice! Scott Gould --- Full Bug description available at: http://bugs.php.net/?id=10480 -- 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] Bug in objects+XML
On Tue, Apr 24, 2001 at 08:31:26PM +0200, Thies C. Arntzen wrote: [workaround snipped] the problem here a cyclic references _and_ $this _not_ being the instantiated object (unless u use this ugly ampersand hack as illustrated) Granted, it is a problem that can be worked around in PHP code, but it still shouldn't crash the process with a segfault. An error or warning would be the correct result. -- 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] Bug #10478 Updated: --with-mcrypt leads to configure: error: Sorry
ID: 10478 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: *Configuration Issues PHP Version: 4.0.4pl1 Assigned To: Comments: Can you send me your configure.log file (privately)? Derick Previous Comments: --- [2001-04-24 14:06:51] [EMAIL PROTECTED] My configure line used to work on a redhat 6.2 system. Now I have upgraded, it does not work any more, it seems not to find any function in the mcrypt library... configure line: -- ./configure --with-mysql --enable-track-vars --with-apache=../../../apache/make/apache_1.3.19 --prefix=/home/local/php --with-config-file-path=/home/local/php/conf --without-gd --disable-debug --with-mhash=/home/local/mhash-0.8.9 --with-mcrypt=mcrypt-2.4.10 --with-mm=/home/local/mm --enable-trans-sid --with-dom= --with-magic-quotes --with-zlib-dir=/home/local/zlib --with-imap=/home/local/libimap configure output: --- (...) Configuring extensions checking for ASPELL support... no checking for bc style precision math functions... no checking for BZip2 support... no checking whether to enable calendar conversion support... no checking CCVS Support... no checking whether to include cpdflib support... no checking whether to enable ctype support... no checking for CURL support... no checking for CyberCash support... no checking whether to enable DAV support through mod_dav... no checking whether to include old xDBM support... no checking whether to enable DBA... no checking for GDBM support... no checking for NDBM support... no checking for Berkeley DB2 support... no checking for Berkeley DB3 support... no checking for DBM support... no checking for CDB support... no checking whether to enable DBA interface... no checking whether to enable the bundled dbase library... no checking for DOM support... yes checking for libxml version... = 2.2.7 checking for libz needed by libxml ... already zlib support checking whether to enable exif support... no checking for fdftk support... no checking whether to enable the bundled filePro support... no checking whether to add fribidi support... no checking whether to enable FTP support... no checking whether to enable truetype string function in gd... no checking for libjpeg (needed by gd-1.8+)... no configure: warning: If configure fails try --with-jpeg-dir=DIR checking for libXpm (needed by gd-1.8+)... no configure: warning: If configure fails try --with-xpm-dir=DIR checking whether to include GD support... no checking whether to include GNU gettext support... no checking for gmp support... no checking for Hyperwave support... no checking for ICAP support... no checking for Kerberos support in IMAP... no checking for SSL support in IMAP... no checking for IMAP support... yes checking for Informix support... no checking for Ingres II support... no checking for InterBase support... no checking for ircg support... no checking for Java support... no checking whether to include LDAP support... no checking for MCAL support... no checking for mcrypt support... yes checking for init_mcrypt in -lmcrypt... no checking for mcrypt_module_open in -lmcrypt... no configure: error: Sorry --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10478edit=2 -- 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] 4.0.5: Merge Request
On Tue, 24 Apr 2001, Rasmus Lerdorf wrote: An easily reproducable segfault in a common PHP extension is a serious issue which could lead to potential security breaches and thus lots of bad mojo from nasty bugtraq postings. If we know about such a segfault and we have a fix and go ahead and release a stable package without this fix then our entire QA process is a joke. If we find such bugs before a release, we fix them. That's what the process is for. Have you checked the bug database lately? There are 43 open reports with bug type 'Reproducible crash'. There are actually even more of them. I can easily reproduce at least 10 bugs which cause segfaults. Those haven't been fixed yet. Those haven't been fixed for a couple of releases now. So, with your logic, we shouldn't release before all of them are fixed? (of course some of these crashes aren't any bugs in PHP. e.g. the IMAP extension. The c-client that it relies on isn't really that stable. ) The QA process as it is IS a joke. Without the support from the developers there aren't any possible ways that it can ever succeed. It isn't the QA people who fix bugs. They just test and report to developers who should FIX those bugs. Some core developers seem to have forget this.. On the other hand, there have been dozens of crash fixes + other fixes in current RC. So why can't we release it, make many people happy and start the release cycle (for 4.0.6) ? And what prevents us from releasing new versions every month? As the QA process is a joke we can skip that anyway... :-p I haven't seen ANY stable releases yet..where are those kept? :) I have only seen release after release that PHP gets more and more new features (with old buggy ones) and with new bugs. What I would like to see now is a code freeze so that people would have to start fixing bugs instead of creating new features. Otherwise this really is a neverending circle. But this will never happen, I guess. Could we vote for this? :) I know it's more fun to create something new. But at least for me it's a matter of honour that my code works as it's intented to..you seem to disagree. --Jani -- 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] Timeout Function
I would like to see a timeout function implemented in PHP (something like Perl's alarm function would be perfect). I notice there is a set_time_limit() function in PHP, but it cannot be applied to a specified block of code (it applies to the entire script) and it causes a fatal error when the timeout is reached (instead of letting you run some alternate code if the timeout is reached). I would like to solve this by contributing to the PHP source, but I am not much of a programmer. I just know a bit of Perl and am pretty familiar with PHP. I have learned some C++ and I understand that C is similar to Perl. Is the PHP interpreter written in C? Maybe I could contribute. Where can I find details on getting a CVS account for PHP development? I am willing to learn and contribute. -- Jason Sims Senior Editor System Administrator Inside Mac Games http://www.insidemacgames.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] 4.0.5: Merge Request
An easily reproducable segfault in a common PHP extension is a serious issue which could lead to potential security breaches and thus lots of bad mojo from nasty bugtraq postings. If we know about such a segfault and we have a fix and go ahead and release a stable package without this fix then our entire QA process is a joke. If we find such bugs before a release, we fix them. That's what the process is for. Have you checked the bug database lately? There are 43 open reports with bug type 'Reproducible crash'. There are actually even more of them. I can easily reproduce at least 10 bugs which cause segfaults. Those haven't been fixed yet. Those haven't been fixed for a couple of releases now. So, with your logic, we shouldn't release before all of them are fixed? You ignored what I said, If we know about such a segfault and we have a fix And yes, if you can actually easily reproduce a segfault in a mainstream module right now, then we have a showstopper and we hold until it is fixed. Please provide specifics. Most of the ones I have looked at are platform and library version specific and either not easily reproducible nor common. The QA process as it is IS a joke. Without the support from the developers there aren't any possible ways that it can ever succeed. It isn't the QA people who fix bugs. They just test and report to developers who should FIX those bugs. Some core developers seem to have forget this.. QA is there to assure quality, not push out releases at all costs. Pushing out a release without this imap fix would produce lower quality rather than higher. That should be the first priority of QA. What I would like to see now is a code freeze so that people would have to start fixing bugs instead of creating new features. Otherwise this really is a neverending circle. But this will never happen, I guess. Could we vote for this? :) You are getting way off topic here. You objected to a segfault fix being merged into the release branch and thus slowing down the process. This was not a new feature. For the most part no new features have gone into the release branch. I know it's more fun to create something new. But at least for me it's a matter of honour that my code works as it's intented to..you seem to disagree. Not at all. -Rasmus -- 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] Timeout Function
I would like to see a timeout function implemented in PHP (something like Perl's alarm function would be perfect). I notice there is a set_time_limit() function in PHP, but it cannot be applied to a specified block of code (it applies to the entire script) and it causes a fatal error when the timeout is reached (instead of letting you run some alternate code if the timeout is reached). That's not true. If you use register_shutdown_function() then this function you register will be run once the timeout hits. See the chapter in the manual on connection handling. -Rasmus -- 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] 4.0.5: Merge Request
The QA process as it is IS a joke. Without the support from the developers there aren't any possible ways that it can ever succeed. It isn't the QA people who fix bugs. They just test and report to developers who should FIX those bugs. Some core developers seem to have forget this.. I can agree more the amount of times I have approached developers to say please fix this or what is the best way to get this fixed and just either 1) been ignored 2) told it doesnt matter 3) Told to fix it myself 4) In one extreme case (Ill leave the developer nameless) told its the users problem and not his.. he just writes the code doesnt make sure its bugless Now by no means all of the developers are guility of this but it seems I keep bugging those developers to get fixes which is unfair as its not always their extension. Shouldnt being an extension maintainer mean fixing bugs reported by the QA Team promptly? Rasmus you may say people here are voulenteers but by becoming in the project and being a maintainer they should be expected to fix bugs when asked. If they dont they loose their status as maintainer and we find someone else (unless they are away on holiday or somthing like that). I promise you that QA'ing isnt fun but when you eventually get to the bottom of a bug and can reproduce it well then a developer turns around and says nothing or its not my problem its really demoralising and you just end up thinking whats the point.. Somthing needs to be done and without a change of attitude from some of the developers it is pointless the QA Team being in existance. - James -- 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] 4.0.5: Merge Request
I can agree more the amount of times I have approached developers to say please fix this or what is the best way to get this fixed and just either 1) been ignored 2) told it doesnt matter 3) Told to fix it myself 4) In one extreme case (Ill leave the developer nameless) told its the users problem and not his.. he just writes the code doesnt make sure its bugless Now by no means all of the developers are guility of this but it seems I keep bugging those developers to get fixes which is unfair as its not always their extension. Shouldnt being an extension maintainer mean fixing bugs reported by the QA Team promptly? Rasmus you may say people here are voulenteers but by becoming in the project and being a maintainer they should be expected to fix bugs when asked. If they dont they loose their status as maintainer and we find someone else (unless they are away on holiday or somthing like that). You can't force people to do anything they don't feel like doing. It is as simple as that. No amount of posturing from me or anybody is going to make a developer fix something he doesn't feel like fixing. Taking away maintainer status isn't going to do anything other than give us one less resource to go to to try to fix issues. Anybody listed as the author of an extension is a maintainer for that extension to some extent. And anybody who wishes to step up and fix stuff is instantly a maintainer as well. As far as I am concerned the QA team should be testing and identifying bugs in the release candidates and tagging things as either showstopper or that-can-wait type of bugs. If nobody steps up to fix a showstopper bug, then there will be no release. Eventually enough developers will get annoyed at that and step up and fix that bug, but a showstopper is a showstopper, hence the term. You guys have done a great job going through the bug database and letting the developers cut straight to the real problems instead of wasting time trying to figure out what a report is actually trying to say. There will always be disagreement on what is a showstopper bug and what isn't. In this case Chuck said it was a showstopper. Few people know more about the imap extension than Chuck, so I don't see why his decision should be vetoed by QA or anybody. If any significant developer steps up and identifies a showstopper and provides a fix that needs to be respected. -Rasmus -- 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] Timeout Function
That's not true. If you use register_shutdown_function() then this function you register will be run once the timeout hits. See the chapter in the manual on connection handling. But this still doesn't let you apply a timeout to a specific block of code. I am doing ad calls to a remote server with PHP, and I want to be able to timeout just the readfile() function I'm using to do the call, and to execute an alternate block of code when it times out. I don't want to abort execution of the entire script; just that portion thereof. I am including a small file with some PHP code in a larger script; can I have a separate timeout for the included script, or does it apply to the main script? If I could have separate timeouts for included scripts, it could serve as a workaround for using timeouts on specific blocks of code. -- Jason Sims Senior Editor System Administrator Inside Mac Games http://www.insidemacgames.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] RE: 4.0.5: Merge Request
Have you checked the bug database lately? There are 43 open reports with bug type 'Reproducible crash'. There are actually even more of them. I can easily reproduce at least 10 bugs which cause segfaults. Those haven't been fixed yet. Those haven't been fixed for a couple of releases now. So, with your logic, we shouldn't release before all of them are fixed? [snip] I agree, no version will ever ever be 100% perfect. There will always be some quirk, or some feature which isnt always right. As you said, QA is to test it and make sure we've nailed down ALL the problems before it goes out, and those that can be fixed are. Those that cant in a reasonable amount of time, or arent deemed a necessary fix or common problem get left till next time. However, as you say, there are quite a few problems which STILL dont work. I appear to have closed 1 bug which was a seg fault, as I tested it with the CVS release of the time, but now again, it appears to have broken. So, I need to go back and reopen it. I can recreate it on 2 versions of linux, so, it suggests its something bad. And just to check, no it still seg faults.. it always has, except for 1 version of the CVS which meant it got closed. What I think we need to do is chat with the developers and come up an agreement Maybe something like this 1. Any problems which result in seg faults/gpfs are show stoppers, code doesnt go out till its fixed, or feature is removed till we can fix it. 2. When we hit say RC1 all the features we want to see in the new version are in, no one ones are added, only bugs fixed. 3. If a developer is unhappy/unable/unwilling/not able to solve problems within their module for whatever reason, a second person who is able needs to be sought. The QA team maybe need to vote on a bug and say if they could recreate it, if no one can recreate it a bug is perhaps less serious than one everyone can recreate and it gets a weighting flag accordingly.. Another idea would be to list supposedly fixed bugs in the release, and any new features.. Am I mad? this is how our QA team worked.. It does take give and take on both sides as if QA were right, no product would ever leave, but if most developers had their way (I speak as one as well) we'd rather play with new bits or not worry if we dont see it it cant be so important.. We arent children, we should be able to sort it out. -- 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] Timeout Function
That's not true. If you use register_shutdown_function() then this function you register will be run once the timeout hits. See the chapter in the manual on connection handling. But this still doesn't let you apply a timeout to a specific block of code. I am doing ad calls to a remote server with PHP, and I want to be able to timeout just the readfile() function I'm using to do the call, and to execute an alternate block of code when it times out. I don't want to abort execution of the entire script; just that portion thereof. Right, but when you are doing network work like this you should be using fsockopen() directly which does have timeout support. readfile() with a url argument just does a simple fsockopen anyway and issues a GET request. Trivial to do yourself using fsockopen() and fputs() and this way you can manage the timeouts yourself. Introducing a language-level timeout feature is complicated. I am including a small file with some PHP code in a larger script; can I have a separate timeout for the included script, or does it apply to the main script? If I could have separate timeouts for included scripts, it could serve as a workaround for using timeouts on specific blocks of code. No, included files are part of the same script. We do have the 'ticks' feature which lets you identify a block of code that will be interrupted every now and and a function you define is called. Doesn't quite do what you need though. The best approach for you is to just use fsockopen(). -Rasmus -- 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 #10312 Updated: xsl:strip elements ... tag isn't working properly
ID: 10312 Updated by: sterling Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Sablotron XSL PHP Version: 4.0.4pl1 Assigned To: Comments: Can you try this with sabcmd (the sablotron executable). So I can see whether or not this is a PHP extension problem (I doubt it) or a Sablotron problem (I'll report it to the Sablotron authors). Thanks! Previous Comments: --- [2001-04-12 20:01:14] [EMAIL PROTECTED] I think there may be a problem with Sablotron and xsl:strip-space tags. I'm using Sablotron with PHP to generate HTML (and other text based outputs) from a couple different stylesheets and XML data being pulled from my db. When I run all my stylesheets on the command line with Instant Saxon (by Michael Kay), the output looks just like I want it to. However, the output generated by PHP/Sablotron is messed up, because there are too many newline characters in the output. If I have textpageparamylistmylistitemlistitem/mylistitem/mylist/para/page/text I get the correct output: begin output * listitem end output However, since this XML isn't very human readable, I reformat my XML input to this: text page para myliist mylistitemlistitem/mylistitem /mylist /para /page /text Instant Saxon treats these two XML inputs as the same thing and produces the same output, since xsl:strip-space elements=* / appears in the stylesheet. However, the PHP/Sablotron translation gives me this: begin output * listitem end output I've also sent this note to the sab-bugs@gingerall people. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10312edit=2 -- 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 #4787 Updated: get_browser() still segments
ID: 4787
User Update by: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: Reproduceable crash
Description: get_browser() still segments
With 4.0.5RC7 this still occurs, it only worked for the CVS at the time it was closed.
Its never worked before or since.
I can also recreate this on Mandrake as well. Oh, and it seems under windows 2000
pro/IIS5
Previous Comments:
---
[2000-07-23 18:42:25] [EMAIL PROTECTED]
That works very nicely, thank you.
Although, the code on the get_browser() page actually returned.
Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
browser_name_pattern: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
parent: IE 5.0
version: 5.5
minorver: 5
platform: Win98
Beta: 1
browser: IE
Version: 5.0
majorver: 5
frames: 1
tables: 1
cookies: 1
backgroundsounds: 1
vbscript: 1
javascript: 1
javaapplets: 1
ActiveXControls: 1
Win16:
beta:
AK:
SK:
AOL:
crawler:
MSN:
CDF: 1
DHTML: 1
XML: 1
(ie the browser name pattern had extra backslashes in before the fullstops - but that
I suppose is a different problem)
---
[2000-07-23 13:35:09] [EMAIL PROTECTED]
Please try latest CVS and report what happens.
---
[2000-06-02 21:31:48] [EMAIL PROTECTED]
I have compiled PHP with
./configure' '--width-apache=/usr/src/apache-3.1.12' '--with-mysql'
'--enable-track-vars' '--disable-debug' '--enable-calendar' '--enable-dbase'
'--enable-ftp' '--enable-trans-sid' '--enable-inline-optimization'
'--enable-discard-path'
I have tried every which way but loose to get this to work, even tried compiling up a
CGI version. (as above but without apache)
OK, when I run it as a module, using the code for the get_browser() in the helpfile on
here aka
?php
function list_array( $browser ) {
while ( list( $key, $value ) = each( $browser ) ) {
$str .= b$key:/b $valuebrn;
}
return $str;
}
echo $HTTP_USER_AGENThrn;
$browser = get_browser();
echo list_array( (array) $browser );
?
All I get is
Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
0:
Whatever the browser/os is, I downloaded the browser.ini file from cyberscap I think -
whereever it was PHP suggested, and I know its reading it, as if I break the ini file
by making false entries it tells me - I checked that much
The CGI version does a segmentation fault.
A working example is on http://www.xcalibur.co.uk/browser.html
It also did it with
./configure' '--width-apache=/usr/src/apache-3.1.12'
---
Full Bug description available at: http://bugs.php.net/?id=4787
--
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 #10481: httpd -l gives mod_php4.c not compatible w/ 1.3.19
From: [EMAIL PROTECTED] Operating system: Solaris 2.6 PHP version: 4.0.4pl1 PHP Bug Type: Apache related Bug description: httpd -l gives mod_php4.c not compatible w/ 1.3.19 There seems to be an error with apache/php4 bin/httpd -l httpd: module mod_php4.c is not compatible with this version of Apache. Please contact the vendor for the correct version. My version of Apache=1.3.19 Version of PHP=4.0.4pl1 Configuration for PHP: configure --prefix=/homes/cbrg/Apache/php --with-apache=/homes/cbrg/Apache/install/apache_1.3.19 -enable-track-vars -with-mysql=/homes/cbrg/Database/mysql Configuration for Apache: configure --prefix=/homes/cbrg/Apache --enable-module=so --activate-module=src/modules/php4/libphp4.a --with-perl=/usr/local/bin/perl Do I not have the correct version of PHP? Thanks, -- Edit Bug report at: http://bugs.php.net/?id=10481edit=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 #10481 Updated: httpd -l gives mod_php4.c not compatible w/ 1.3.19
ID: 10481 Updated by: rasmus Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Apache related PHP Version: 4.0.4pl1 Assigned To: Comments: You compiled PHP against an older version of Apache and you are now trying to load it into a newer one. Recompile your PHP against this version of Apache. Previous Comments: --- [2001-04-24 17:23:52] [EMAIL PROTECTED] There seems to be an error with apache/php4 bin/httpd -l httpd: module mod_php4.c is not compatible with this version of Apache. Please contact the vendor for the correct version. My version of Apache=1.3.19 Version of PHP=4.0.4pl1 Configuration for PHP: configure --prefix=/homes/cbrg/Apache/php --with-apache=/homes/cbrg/Apache/install/apache_1.3.19 -enable-track-vars -with-mysql=/homes/cbrg/Database/mysql Configuration for Apache: configure --prefix=/homes/cbrg/Apache --enable-module=so --activate-module=src/modules/php4/libphp4.a --with-perl=/usr/local/bin/perl Do I not have the correct version of PHP? Thanks, --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10481edit=2 -- 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 #10306 Updated: xslt_process() causes page to be loaded twice
ID: 10306
Updated by: sterling
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Sablotron XSL
PHP Version: 4.0 Latest CVS (12/04/2001)
Assigned To:
Comments:
Well if it stopped, then I'll mark the bug as closed. If
starts happening again, or you have more information,
re-open this bug, or open up a new bug.
Previous Comments:
---
[2001-04-12 14:35:16] [EMAIL PROTECTED]
Ok, this is just plain wierd...it decided to stop doing that...I will investigate
further and see if I can reproduce it.
---
[2001-04-12 12:21:25] [EMAIL PROTECTED]
In one of my scripts, I make a function call to a function which contains the
xslt_process() function. After this function, I am inserting an entry into my database
for logging purposes.
test.php
function html_transform($xsl, $xml) {
if (!xslt_process($xsl, $xml, $html)) {
header(Status: 500 Server Error);
echo xslt_error();
echo ERROR .$php_error_msg;
exit;
}
else {
return($html);
}
}
$xml = loaded from file;
$xsl = loaded from file;
$html = html_transform($xsl,$xml);
echo $html;
mysql_query(INSERT INTO table...);
echo mysql_insert_id();
the insert id is incrementing my 2, unless I disable the xslt_process() function.
Really strange and I think its a bug in the xslt_process() function.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10306edit=2
--
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 #8412 Updated: transformations hang
ID: 8412 Updated by: sterling Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Sablotron XSL PHP Version: 4.0.4 Assigned To: sterling Comments: Ok, try it and re-open the report if it happens. I've used MySQL and Sablotron together fine... Previous Comments: --- [2001-04-09 19:42:27] [EMAIL PROTECTED] I don't have that machine available anymore to help test if it works or not... at least not in a reasonable amount of time before 4.0.5 gets out. --- [2001-04-05 14:29:32] [EMAIL PROTECTED] try this with the newest sablotron and php and let me know what happens... --- [2000-12-25 03:56:59] [EMAIL PROTECTED] My install hangs when hitting reload a lot and my httpd processes suck up my resources until the script times out. It takes between 5-15 quick reloads before it hangs. This seems to only happen when I grab stuff from MySQL in the same script as when I'm doing a transformation. ' ./configure' '--with-mysql' '--enable-track-vars' '--with-mcrypt' '--enable-ftp' '--enable-sockets' '--with-sablot' '--enable-sablot-errors-descriptive' '--with-apache=../apache_1.3.14' '--with-zlib' I'm using Sablotron 0.44.1 and Expat 1.1.2. A script with just MySQL works fine, and a script with just a transformation works fine. I don't see anything additionally descriptive about --enable-sablot-errors-descriptive either --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8412edit=2 -- 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] is_link() behavior
On Tue, Apr 24, 2001 at 10:50:36AM +0200, Andi Gutmans wrote:
It definitely seems as if the logic in the code (filestat.c) is kind of
screwed up.
If no one has time to look at it I can try and take a look at it later on.
Andi
At 01:35 AM 4/24/2001 -0500, J. Jones wrote:
Forgive me for my ignorance, but I've noticed some unwanted behavior
(IMO, at least) with the is_link() function. Given the simple code..
if ( is_link (/tmp/this_is_a_symlink) )
print (Success\n);
and the file..
lrwxrwxrwx 1 root root 5 Apr 23 21:19 /tmp/this_is_a_symlink - /bin/
the above obviously prints 'Success\n'.
However, if I BREAK the symlink, with something like the following..
lrwxrwxrwx 1 root root 4 Apr 23 21:21 /tmp/this_is_a_symlink - foo
the script fails with..
Warning: stat failed for /tmp/this_is_a_symlink (errno=2 - No such file or
directory) in ./test.php on line 3.
The file /tmp/this_is_a_symlink is still a symlink, so it seems to me that
the is_link() function should still return true, whether or not the symlink's
target exists. Is there perhaps a function I have yet to discover that
provides that behavior, without verifying the link's target?
I grew impatient, and devised a simple (2 line) workaround in filestat.c.
Basically it just required NOT doing a stat() if is_link() was calling
php_stat(). This probably isn't 'the' fix, but it works great for me, and
I know you guys are pretty busy. Attached is my diff against
php-4.0.4pl1's ext/standard/filestat.c.
Thanks for the great language! Keep it up!
J. Jones
--- php-4.0.4pl1/ext/standard/filestat.cThu Dec 7 13:15:02 2000
+++ php-4.0.4pl1/ext/standard/filestat.cTue Apr 24 16:43:06 2001
@@ -467,6 +467,7 @@
#if HAVE_SYMLINK
BG(lsb).st_mode = 0; /* mark lstat buf invalid */
#endif
+ if (type != 14) {
if (V_STAT(BG(CurrentStatFile),BG(sb))==-1) {
if (type != 15 || errno != ENOENT) { /* fileexists() test must
print no error */
php_error(E_NOTICE,stat failed for %s (errno=%d -
%s),BG(CurrentStatFile),errno,strerror(errno));
@@ -474,6 +475,7 @@
efree(BG(CurrentStatFile));
BG(CurrentStatFile)=NULL;
RETURN_FALSE;
+ }
}
}
--
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] Bug #10292: Corrupted VARCHAR values from SELECT when used in arrays or array functions
Hi, I have tracked down the bug in ./ext/interbase/interbase.c. I have posted the bugfix on the web-site as a diff between version 1.48 and the fixed version. Also bug #9257 has been identified and fixed. The diff has been posted under _bug_-report #10458 :-) Yours sincerely, Lars Westermann On 11 Apr 2001 11:33:55 -0700, [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Operating system: Linux / Windows PHP version: 4.0.4pl1 PHP Bug Type: InterBase related Bug description: Corrupted VARCHAR values from SELECT when used in arrays or array functions // f1 and f2 are of type varchar $id=ibase_query($tr_id, SELECT f1, f2 FROM t1;); $res = ibase_fetch_row($id); echo '.$res[0].'; // Working fine $arr[$res[0]] = 1; $arr[$res[1]] = 2; foreach ($res as $r = $v) echo '$r'\n; // will in some cases add unexpected // characters to end of $r // It is the same with each construct // The same applies to ibase_fetch_object() The values in the database are correct, as the unwanted characters may vary depending on the number of columns in the select-statement. But it is always the same characters on repeated executions. I have made a work-around in a way like this: $arr[str_pad($res[0], -1)] = 1; I think it has something to do with the Interbase-API, as it is the same errors regardless of the Webserver (Apache 1.3.14 1.3.19, PHP 4.0.4pl1 or Win9x PWS, CGI or ISAPI version of PHP 4.0.4pl1) connecting to Interbase 6.01 on RedHat 6.1 and RedHat 6.2 The bug was first observed when doing a split(), where the last element in the resulting array had strange characters attached to the end. PHP configured with minimal changes to defaults (Interbase support, enable-track-vars). Hope this is sufficient information, otherwise write me for further info, and I will try to deliver it (if I can). Regards /Lars -- Edit Bug report at: http://bugs.php.net/?id=10292edit=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 #10082 Updated: curl_setopt with CURLOPT_HTTPHEADER option is broken
ID: 10082 Updated by: sterling Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: cURL related PHP Version: 4.0 Latest CVS (30/03/2001) Assigned To: Comments: Changes incorporated in CVS, thanks. Previous Comments: --- [2001-04-02 15:26:19] [EMAIL PROTECTED] And in a related problem, it seems that if you specify CURLOPT_RETURNTRANSFER, in some cases you can get a truncated response due to two off by one errors. at the bottom of the curl_exec function, there is a line ret_data[stat_sb.st_size - 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] Timeout Function
Right, but when you are doing network work like this you should be using fsockopen() directly which does have timeout support. readfile() with a url argument just does a simple fsockopen anyway and issues a GET request. Trivial to do yourself using fsockopen() and fputs() and this way you can manage the timeouts yourself. Introducing a language-level timeout feature is complicated. I want to *write* to the connection to do a GET request? That sort of makes sense, but how do I get what the remote server returned after I issued the request? -- Jason Sims Senior Editor System Administrator Inside Mac Games http://www.insidemacgames.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] Timeout Function
Right, but when you are doing network work like this you should be using fsockopen() directly which does have timeout support. readfile() with a url argument just does a simple fsockopen anyway and issues a GET request. Trivial to do yourself using fsockopen() and fputs() and this way you can manage the timeouts yourself. Introducing a language-level timeout feature is complicated. I want to *write* to the connection to do a GET request? That sort of makes sense, but how do I get what the remote server returned after I issued the request? fputs() to write and fgets() to read. Type PostToHost into Google or something and you should turn up a function I wrote years ago that does something like this. It does a POST request which is a bit more complex. -Rasmus -- 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] Timeout Function:
Personally, I think having an alarm (timeout) function is a really good idea. Setting a timer, and then being able to jump from whatever you are doing if it is taking too long is something that has helped me do some really neat stuff in C and Perl... and I was a little dissapointed when I learned PHP didn't have. Of course, I have no idea how hard it would be to do... so my opinion isn't worth a hole lot more than .02 Brian Tanner http://www.zaam.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] hebrew error messages?
Andrei's Hebrew sure is getting better :)
At 21:15 24/4/2001, Andrei Zmievski wrote:
On Tue, 24 Apr 2001, Colin Viebrock wrote:
Parse error: parse error, expecting `T_PAAMAYIM_NEKUDOTAYIM' or `'('' in
/path/to/file.php on line 246
Zeev/Andi ... ? :)
Read expecting '::' or '('.
-Andrei
Commitment, n.:
Commitment can be illustrated by a breakfast of ham and eggs. The chicken
was involved, the pig was committed.
--
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]
--
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] Timeout Function:
Personally, I think having an alarm (timeout) function is a really good idea. Setting a timer, and then being able to jump from whatever you are doing if it is taking too long is something that has helped me do some really neat stuff in C and Perl... and I was a little dissapointed when I learned PHP didn't have. Although I've been able to solve my current problem with fsockopen(), I think an alarm function would be nice to have for other things. Perl is open-source, right? Probably the best way to implement this in PHP would be to look at how Perl is doing it and go from there. -- Jason Sims Senior Editor System Administrator Inside Mac Games http://www.insidemacgames.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] Timeout Function:
[Jason Sims [EMAIL PROTECTED]] Personally, I think having an alarm (timeout) function is a really good idea. Setting a timer, and then being able to jump from whatever you are doing if it is taking too long is something that has helped me do some really neat stuff in C and Perl... and I was a little dissapointed when I learned PHP didn't have. Although I've been able to solve my current problem with fsockopen(), I think an alarm function would be nice to have for other things. Perl is open-source, right? Probably the best way to implement this in PHP would be to look at how Perl is doing it and go from there. It's not that simple in PHP. Perl is a standalone environment, so you can use signals to your heart's delight. But PHP is usually one with Apache, and signals are not easily shared. I suggest implementing a timeout using ticks on the C level. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Timeout Function:
Perl uses SIGALRM to implement alarms, something which is not an option when you're an Apache module. Zeev At 02:13 25/4/2001, Jason Sims wrote: Personally, I think having an alarm (timeout) function is a really good idea. Setting a timer, and then being able to jump from whatever you are doing if it is taking too long is something that has helped me do some really neat stuff in C and Perl... and I was a little dissapointed when I learned PHP didn't have. Although I've been able to solve my current problem with fsockopen(), I think an alarm function would be nice to have for other things. Perl is open-source, right? Probably the best way to implement this in PHP would be to look at how Perl is doing it and go from there. -- Jason Sims Senior Editor System Administrator Inside Mac Games http://www.insidemacgames.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] -- 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] 4.0.5: Merge Request
On Wed, 25 Apr 2001, Zeev Suraski wrote: While I'd say Jani's letter was slightly over emotional ;), he does have a point. I think that taking a stop to look closely at the bugs database would be a good thing, and the turn of a new version is a good time to do it. Deciding 4.0.6 won't include any significant new features, and that we'll start its release process after a bugs-database-cleaning period sounds like a good idea to me. Hrmm.. 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. -Sterling Zeev At 23:44 24/4/2001, Jani Taskinen wrote: On Tue, 24 Apr 2001, Rasmus Lerdorf wrote: An easily reproducable segfault in a common PHP extension is a serious issue which could lead to potential security breaches and thus lots of bad mojo from nasty bugtraq postings. If we know about such a segfault and we have a fix and go ahead and release a stable package without this fix then our entire QA process is a joke. If we find such bugs before a release, we fix them. That's what the process is for. Have you checked the bug database lately? There are 43 open reports with bug type 'Reproducible crash'. There are actually even more of them. I can easily reproduce at least 10 bugs which cause segfaults. Those haven't been fixed yet. Those haven't been fixed for a couple of releases now. So, with your logic, we shouldn't release before all of them are fixed? (of course some of these crashes aren't any bugs in PHP. e.g. the IMAP extension. The c-client that it relies on isn't really that stable. ) The QA process as it is IS a joke. Without the support from the developers there aren't any possible ways that it can ever succeed. It isn't the QA people who fix bugs. They just test and report to developers who should FIX those bugs. Some core developers seem to have forget this.. On the other hand, there have been dozens of crash fixes + other fixes in current RC. So why can't we release it, make many people happy and start the release cycle (for 4.0.6) ? And what prevents us from releasing new versions every month? As the QA process is a joke we can skip that anyway... :-p I haven't seen ANY stable releases yet..where are those kept? :) I have only seen release after release that PHP gets more and more new features (with old buggy ones) and with new bugs. What I would like to see now is a code freeze so that people would have to start fixing bugs instead of creating new features. Otherwise this really is a neverending circle. But this will never happen, I guess. Could we vote for this? :) I know it's more fun to create something new. But at least for me it's a matter of honour that my code works as it's intented to..you seem to disagree. --Jani -- 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] -- 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] Bug #10482: if the filesize if more than 2GB, filesystem functions do not seem to recognize
From: [EMAIL PROTECTED]
Operating system: redhat 7.1
PHP version: 4.0.4pl1
PHP Bug Type: Filesystem function related
Bug description: if the filesize if more than 2GB, filesystem functions do not seem
to recognize
$folder = dir(.);
$folder-rewind() ;
clearstacache();
while ($file=$folder-read()) {
if (is_dir ($file)) {
do_some thing...
}
elif (is_file($file)) {
do_somethingelse.
}
..
.
}
is_file() call in the above code does not return ture if the file size is 2GB.
I was able to print $file, just inside the loop (meaning the folder object has the
file in the filelist
and hence it is the is_file() which is filtering it out.
I tried other functions like file_exists(), is_readable() etc in place of is_file()
without any success.
--
Edit Bug report at: http://bugs.php.net/?id=10482edit=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] 4.0.5: Merge Request
Zeev Suraski wrote: Deciding 4.0.6 won't include any significant new features, and that we'll start its release process after a bugs-database -cleaning period sounds like a good idea to me. So why restrict it to just the next release? It might make a lot of sense to have an RC candidate much more often, but with a longer QA period to fix all these bugs. Kind of like FreeBSD; have a -current, and a -stable branch. It's sort of been going that way with the 4.0.5 release (there's been a lot of uptake on merging bugfixes, but not adding new features, except for FastCGI). Anil -- 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] RE: 4.0.5: Merge Request
hi, Maybe something like this 1. Any problems which result in seg faults/gpfs are show stoppers, code doesnt go out till its fixed, or feature is removed till we can fix it. this is not correct (in general :) - there are segfaults in experimental stuff that do not imply exploits, are no security risk and are just a new/unused feature that does not work as expected. it IS ok to release with such a segfault. an example: bbonev@orange:~$ echo ? \$a=1 ? | php -a Interactive mode enabled X-Powered-By: PHP/4.0.5RC6 Content-type: text/html Segmentation fault see bug id 8621 i think commonsense shall be used to judge what is showstopper and what is not :) this one definitely is not b. -- 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 #10483: someFunction() OR break;
From: [EMAIL PROTECTED]
Operating system: all
PHP version: 4.0.4
PHP Bug Type: Feature/Change Request
Bug description: someFunction() OR break;
why is the syntax
someFunction() OR anotherFunction();
only possible with a function on the right side of the OR? cause it has to return
something?
would be nice to be able to to someFunction() OR break;
example:
$success = FALSE;
do { // try block
doSomething(foo) OR break;
doSomething(bar) OR break;
doSomething(hello) OR break;
doSomething(world) OR break;
$success = TRUE;
} while (FALSE);
echo ($success) ? 'yes' : 'no';
greetings
fab
--
Edit Bug report at: http://bugs.php.net/?id=10483edit=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.4pl1 configure/build questions
1) I have now been adding functions to an extension initiated by ext_skel for a couple of days and familiarized myself with the source code layout and build architecture. It appears everything is controlled by the ../php4/configure file which appears to be edited directly by ext_skel when it is run. Is this correct? 2) In regard to self-contained extensions, what does PHPIZE do? 3) The document README.SELF-CONTAINED-EXTENSIONS, it looks like an embedded extension is one that is in the ../php4/ext/.. subdirectory tree while a self contained extension is in a directory outside the normal location. Is this correct? OR, is a self contained extension one that requires dlopen( ) to gain access to the functions? 4) If a shared library is added into the PHP.INI file, does that mean it is loaded on startup the apache server/libphp4.so and stays loaded. Meaning that the library is loaded just one time instead of being reloaded for each script that calls dlopen( ) ? Thanks for any reply, Mark Diener -- 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] 4.0.5: Merge Request
At 02:24 AM 4/25/2001 +0300, Zeev Suraski wrote: While I'd say Jani's letter was slightly over emotional ;), he does have a point. I think that taking a stop to look closely at the bugs database would be a good thing, and the turn of a new version is a good time to do it. Deciding 4.0.6 won't include any significant new features, and that we'll start its release process after a bugs-database-cleaning period sounds like a good idea to me. Well I was saying exactly what Jani is saying. That if you want a bug free minor version then you have to be aware of all the existing crash bugs in the bugs database and not live in the illusion that this last 4.0.5 crash bug fix creates now a stable version. I don't think every crash bug can be a show stopper. Our releases would slow down to a halt. I don't think it's enough to decide that 4.0.6 won't have additional features (also because it has enough additional features already which are enough for another minor version), but the developers need to actually go through the bugs database and work on those crash bugs. It's not that easy to get everyone to work on them. Anyway, I think it's a good idea to decide on a one to two week intensive period where no features are added and all developers work hard on closing crash bugs and other serious bugs. The problem is that there will be lots of developers who will want their very important patches going into 4.0.6 and quite a few who won't be bothered to do the tough job. I'm not sure this would work. Andi -- 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 #9957 Updated: compile failure - errors in ext/standard/basic_functions.c
ID: 9957
Updated by: sterling
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Compile Failure
PHP Version: 4.0 Latest CVS (23/03/2001)
Assigned To:
Comments:
fixed in cvs
Previous Comments:
---
[2001-03-23 11:49:30] [EMAIL PROTECTED]
php4-200103230745
D:compilephpphp4-200103230745extstandardbasic_functions.c(2494) : error C2065:
'core_globals' : undeclared identifier
D:compilephpphp4-200103230745extstandardbasic_functions.c(2494) : error C2223: left of
'-safe_mode' must point to struct/union
the offending line:
if (PG(safe_mode) (!php_checkuid(Z_STRVAL_PP(new_path), NULL,
CHECKUID_CHECK_FILE_AND_DIR))) {
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9957edit=2
--
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] is_link() behavior
Hi, I just commited a patch which also cleaned up some other stuff (although it could still use some fixing up). Please check the latest CVS to see if it works now. Also can you please check the lstat() command? I think it has the same problem (I didn't fix it because I want to be sure) and I think filetype() might also not work correctly on links which aren't pointing to anything (at least not give all the right information). Andi At 04:51 PM 4/24/2001 -0500, J. Jones wrote: On Tue, Apr 24, 2001 at 10:50:36AM +0200, Andi Gutmans wrote: It definitely seems as if the logic in the code (filestat.c) is kind of screwed up. If no one has time to look at it I can try and take a look at it later on. Andi At 01:35 AM 4/24/2001 -0500, J. Jones wrote: Forgive me for my ignorance, but I've noticed some unwanted behavior (IMO, at least) with the is_link() function. Given the simple code.. if ( is_link (/tmp/this_is_a_symlink) ) print (Success\n); and the file.. lrwxrwxrwx 1 root root 5 Apr 23 21:19 /tmp/this_is_a_symlink - /bin/ the above obviously prints 'Success\n'. However, if I BREAK the symlink, with something like the following.. lrwxrwxrwx 1 root root 4 Apr 23 21:21 /tmp/this_is_a_symlink - foo the script fails with.. Warning: stat failed for /tmp/this_is_a_symlink (errno=2 - No such file or directory) in ./test.php on line 3. The file /tmp/this_is_a_symlink is still a symlink, so it seems to me that the is_link() function should still return true, whether or not the symlink's target exists. Is there perhaps a function I have yet to discover that provides that behavior, without verifying the link's target? I grew impatient, and devised a simple (2 line) workaround in filestat.c. Basically it just required NOT doing a stat() if is_link() was calling php_stat(). This probably isn't 'the' fix, but it works great for me, and I know you guys are pretty busy. Attached is my diff against php-4.0.4pl1's ext/standard/filestat.c. Thanks for the great language! Keep it up! J. Jones -- 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 #10484: Problem with insert in ODBC
From: [EMAIL PROTECTED]
Operating system: Win2000
PHP version: 4.0.4pl1
PHP Bug Type: ODBC related
Bug description: Problem with insert in ODBC
$BD = odbc_connect ('BdTest', SQL_CUR_USE_DRIVER);
$SQL = insert into test values ('a', 'b');
$TabUser = odbc_exec($BD, $SQL);
this don't work...nothing had been added in the table test
$BD = odbc_connect ('BdTest '', SQL_CUR_USE_DRIVER);
$SQL = select * from Utilisateur where Nom_utilisateur = '$Nom' and Mot_de_passe =
'$Pass';
$TabUser = odbc_exec($BD, $SQL);
This work fine!
How should i use insert statement in order to make it works??
--
Edit Bug report at: http://bugs.php.net/?id=10484edit=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] 4.0.5: Merge Request
Andi Gutmans ([EMAIL PROTECTED]) wrote: features (also because it has enough additional features already which are enough for another minor version), but the developers need to actually go through the bugs database and work on those crash bugs. It's not that easy to get everyone to work on them. The Debian project uses a practice which may be useful. Bugs are identified by project leaders as release-critical. Release-critical is a bug severity level which bugs (crashers, cosmetic, whatever) can get promoted to. There's a page giving stats on RC bugs: http://master.debian.org/~wakkerma/bugs/ And approximately monthly bug squashing parties held on IRC: http://lwn.net/2001/0222/a/db-bugsquash.php3 My suggestion, having watched a few open-source projects structured similarly to PHP, is to declare a particular date as a freeze date, with pressure NOT to commit major overhauls increasing as the freeze approached. At the freeze, a CVS branch is created and the bug squashing party begins - release critical bugs only! Once RC bugs get cleared, the branch changes get merged back into the mainline and development resumes until it's time to release again. -- 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] further notes on bug squashing parties
Looking at the RC bugs graph: http://master.debian.org/~wakkerma/bugs/ you'll see two precipitous drops in the number of RC bugs. Those are bug parties. - Steve -- 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] 4.0.5: Merge Request
At 02:24 AM 4/25/2001 +0300, Zeev Suraski wrote: While I'd say Jani's letter was slightly over emotional ;), he does have a point. I think that taking a stop to look closely at the bugs database would be a good thing, and the turn of a new version is a good time to do it. Deciding 4.0.6 won't include any significant new features, and that we'll start its release process after a bugs-database-cleaning period sounds like a good idea to me. Well I was saying exactly what Jani is saying. That if you want a bug free minor version then you have to be aware of all the existing crash bugs in the bugs database and not live in the illusion that this last 4.0.5 crash bug fix creates now a stable version. I don't think every crash bug can be a show stopper. Our releases would slow down to a halt. Nobody is talking about such an illusion. Let's not lose track of what caused this ruckus. A crash bug was found and fixed in a mainstream extension. It was just before a release. So the release was put off for a couple of days to get this fix in. I see absolutely nothing wrong with this. Of course there are still bugs. And yes there are still serious bugs lurking. But none we have a known and tested fix for. Anyway, I think it's a good idea to decide on a one to two week intensive period where no features are added and all developers work hard on closing crash bugs and other serious bugs. The problem is that there will be lots of developers who will want their very important patches going into 4.0.6 and quite a few who won't be bothered to do the tough job. I'm not sure this would work. This will definitely not work as all developers are at very different stages of development. Some extensions are very young and evolving quickly right now. Telling a developer with such an extension to stop developing the extension and only fix bugs doesn't make much sense. The realistic way to do this, and the way I thought we had agreed on, is to create a release branch at some semi-stable point and not add new features to it but focus on fixing the most serious bugs in it. And yes, I agree that it would be good if we could get more developers to focus on the release branch and devote more cycles to tracking down issues in the release branch, but here is where I would like the QA team or someone to step up and create a list of issues (likely just a list of bug id numbers) that they deem to be significant issues with the release branch. It should not be the QA team's job to track down developers and try to convince them to fix bugs. eg. Release branch 4.0.87 Showstoppers: #20457, #24099 Serious: #24, #354354, #546543 Moderate: #535436, #45326543, #5443543 Developers like finite-looking lists like this. They can see an end to the work. Fix 5 bugs and we are good to go for the release. Obviously there will still be bugs, but at least this would be an organized approach to it. -Rasmus -- 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] is_link() behavior
On Wed, Apr 25, 2001 at 07:22:03AM +0200, Andi Gutmans wrote:
Hi,
I just commited a patch which also cleaned up some other stuff (although it
could still use some fixing up).
Please check the latest CVS to see if it works now.
Also can you please check the lstat() command? I think it has the same
problem (I didn't fix it because I want to be sure) and I think filetype()
might also not work correctly on links which aren't pointing to anything
(at least not give all the right information).
Andi
Hey.. I pulled just the filestat.c out of CVS into php-4.0.4pl1..
hopefully that isn't the issue (I recieved no warnings during the compile,
and nothing really seemed to have changed much in the ext/standard/
directory).
--code:
function link_func_test ($file)
{
if ( is_link ($file)) { print (is_link passed\n); }
else { print (is_link failed\n); }
if (($temp_filetype = filetype ($file))) { print (filetype passed:
$temp_filetype\n); }
else { print (filetype failed\n); }
if (($temp_lstat = lstat ($file))) { print (lstat passed:\n\n);
print_r ($temp_lstat); }
else { print (lstat failed\n); }
}
$file = '/tmp/test-link-func';
// This was if (file_exists ($file)), but it's borked too! ;)
@ unlink ($file);
if (symlink ('/bin/false', $file)) { link_func_test ($file); }
else { print (Good symlink failed\n); }
@ unlink ($file);
if (symlink ('/this/file/does/not/exist', $file)) { link_func_test ($file); }
else { print (Bad symlink failed\n); }
--End
--output:
:(00:36am ~/php): ./fs-test.php
is_link passed
filetype passed: link
lstat passed:
Array
(
[0] = 770
[1] = 1273
[2] = 41471
[3] = 1
[4] = 0
[5] = 0
[6] = 0
[7] = 10
[8] = 988177003
[9] = 988177003
[10] = 988177003
[11] = 4096
[12] = 1
)
Warning: lstat failed for (null) (errno=14 - Bad address) in ./fs-test.php
on line 5
is_link failed
Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or
directory) in ./fs-test.php on line 8
filetype failed
Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or
directory) in ./fs-test.php on line 11
lstat failed
--end
If there are other changes to the tree which may be affecting this I will
grab the full CVS tree and try again. Feel free to send me any patches
directly for testing.
Thanks!
J. Jones
--
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] is_link() behavior
Oh.. the readlink () function works fine in both instances.. readlink passed: /bin/false readlink passed: /this/file/does/not/exist -- 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.4pl1 configure/build questions
I have now been adding functions to an extension initiated by ext_skel for a couple of days and familiarized myself with the source code layout and build architecture. It appears everything is controlled by the ../php4/configure file which appears to be edited directly by ext_skel when it is run. Is this correct? No. The configure script is built by the buildconf script. 2) In regard to self-contained extensions, what does PHPIZE do? It's a very simple shell script. Read through it. Basically it allows you to turn an extension into a standalone buildable distribution. Try this test: cd php4/ext/exif mkdir /tmp/exif make clean cp * /tmp/exif cd /tmp/exif ls (note how few files there are. No configure script or anything) phpize ls (compare to before) ./configure --enable-shared=exif make ls modules (note the exif.so file) 3) The document README.SELF-CONTAINED-EXTENSIONS, it looks like an embedded extension is one that is in the ../php4/ext/.. subdirectory tree while a self contained extension is in a directory outside the normal location. Is this correct? Sure. And phpize is used to turn an embedded extension into a self-contained extension. OR, is a self contained extension one that requires dlopen( ) to gain access to the functions? That's a separate issue. An embedded extension can still be built as a shared library using --with-mysql=shared (for example), but an embedded extension can also be built as a static extension. A self-contained extension can only be built as a shared library which is either loaded via an extension=foo.so in your php.ini file or via a dl() call in a script. 4) If a shared library is added into the PHP.INI file, does that mean it is loaded on startup the apache server/libphp4.so and stays loaded. Meaning that the library is loaded just one time instead of being reloaded for each script that calls dlopen( ) ? Correct. -Rasmus -- 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] 4.0.5: Merge Request
At 10:35 PM 4/24/2001 -0700, Rasmus Lerdorf wrote: At 02:24 AM 4/25/2001 +0300, Zeev Suraski wrote: While I'd say Jani's letter was slightly over emotional ;), he does have a point. I think that taking a stop to look closely at the bugs database would be a good thing, and the turn of a new version is a good time to do it. Deciding 4.0.6 won't include any significant new features, and that we'll start its release process after a bugs-database-cleaning period sounds like a good idea to me. Well I was saying exactly what Jani is saying. That if you want a bug free minor version then you have to be aware of all the existing crash bugs in the bugs database and not live in the illusion that this last 4.0.5 crash bug fix creates now a stable version. I don't think every crash bug can be a show stopper. Our releases would slow down to a halt. Nobody is talking about such an illusion. Let's not lose track of what caused this ruckus. A crash bug was found and fixed in a mainstream extension. It was just before a release. So the release was put off for a couple of days to get this fix in. I see absolutely nothing wrong with this. Neither do I. Of course there are still bugs. And yes there are still serious bugs lurking. But none we have a known and tested fix for. Yes but for example the crash bug I fixed in foreach(). I don't think it was a showstopper. It ended up slipping in because there was another RC anyway (and it was a one liner) but what I meant is that not all crash bugs are show stoppers. Anyway, I think it's a good idea to decide on a one to two week intensive period where no features are added and all developers work hard on closing crash bugs and other serious bugs. The problem is that there will be lots of developers who will want their very important patches going into 4.0.6 and quite a few who won't be bothered to do the tough job. I'm not sure this would work. This will definitely not work as all developers are at very different stages of development. Some extensions are very young and evolving quickly right now. Telling a developer with such an extension to stop developing the extension and only fix bugs doesn't make much sense. I disagree. I don't think having developers take off a couple of days from their stage of development and help the greater PHP cause is a big deal. After all it is these developers that can help fix bugs, and well what can we do, bugs aren't necessarily fixed by their authors. It's much more fun coding and writing your own extension, and it's a good thing, but it doesn't mean you can't do some of the dirty work for a couple of days. That suggestion to look at the Debian model is a good idea IMO. The realistic way to do this, and the way I thought we had agreed on, is to create a release branch at some semi-stable point and not add new features to it but focus on fixing the most serious bugs in it. And yes, I agree that it would be good if we could get more developers to focus on the release branch and devote more cycles to tracking down issues in the release branch, but here is where I would like the QA team or someone to step up and create a list of issues (likely just a list of bug id numbers) that they deem to be significant issues with the release branch. It should not be the QA team's job to track down developers and try to convince them to fix bugs. eg. Release branch 4.0.87 Showstoppers: #20457, #24099 Serious: #24, #354354, #546543 Moderate: #535436, #45326543, #5443543 Developers like finite-looking lists like this. They can see an end to the work. Fix 5 bugs and we are good to go for the release. Obviously there will still be bugs, but at least this would be an organized approach to it. Having a better defined/reproduced list of bugs is a must and if the QA team can do that PHP will definitely benefit from it. However, today when they ask people to fix bugs they are often not fixed and I don't even think that they are necessarily looked at. That is why a defined everyone join forces to kill the bugs period would be a good thing. And whoever doesn't help isn't allowed to hack on his extension anymore (Just kidding :). Andi -- 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] is_link() behavior
I commited another fix.
is_link() should work correctly now. If things have improved and you have
problems with lstat() and filetype() (which I think there's a good chance
that they are screwed up) let me know.
Thanks,
Andi
At 12:43 AM 4/25/2001 -0500, J. Jones wrote:
On Wed, Apr 25, 2001 at 07:22:03AM +0200, Andi Gutmans wrote:
Hi,
I just commited a patch which also cleaned up some other stuff
(although it
could still use some fixing up).
Please check the latest CVS to see if it works now.
Also can you please check the lstat() command? I think it has the same
problem (I didn't fix it because I want to be sure) and I think filetype()
might also not work correctly on links which aren't pointing to anything
(at least not give all the right information).
Andi
Hey.. I pulled just the filestat.c out of CVS into php-4.0.4pl1..
hopefully that isn't the issue (I recieved no warnings during the compile,
and nothing really seemed to have changed much in the ext/standard/
directory).
--code:
function link_func_test ($file)
{
if ( is_link ($file)) { print (is_link passed\n); }
else { print (is_link failed\n); }
if (($temp_filetype = filetype ($file))) { print (filetype passed:
$temp_filetype\n); }
else { print (filetype failed\n); }
if (($temp_lstat = lstat ($file))) { print (lstat passed:\n\n);
print_r ($temp_lstat); }
else { print (lstat failed\n); }
}
$file = '/tmp/test-link-func';
// This was if (file_exists ($file)), but it's borked too! ;)
@ unlink ($file);
if (symlink ('/bin/false', $file)) { link_func_test ($file); }
else { print (Good symlink failed\n); }
@ unlink ($file);
if (symlink ('/this/file/does/not/exist', $file)) { link_func_test ($file); }
else { print (Bad symlink failed\n); }
--End
--output:
:(00:36am ~/php): ./fs-test.php
is_link passed
filetype passed: link
lstat passed:
Array
(
[0] = 770
[1] = 1273
[2] = 41471
[3] = 1
[4] = 0
[5] = 0
[6] = 0
[7] = 10
[8] = 988177003
[9] = 988177003
[10] = 988177003
[11] = 4096
[12] = 1
)
Warning: lstat failed for (null) (errno=14 - Bad address) in ./fs-test.php
on line 5
is_link failed
Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or
directory) in ./fs-test.php on line 8
filetype failed
Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or
directory) in ./fs-test.php on line 11
lstat failed
--end
If there are other changes to the tree which may be affecting this I will
grab the full CVS tree and try again. Feel free to send me any patches
directly for testing.
Thanks!
J. Jones
--
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] Bug in objects+XML
On Tue, Apr 24, 2001 at 03:57:05PM -0400, Jon Parise wrote: On Tue, Apr 24, 2001 at 08:31:26PM +0200, Thies C. Arntzen wrote: [workaround snipped] the problem here a cyclic references _and_ $this _not_ being the instantiated object (unless u use this ugly ampersand hack as illustrated) Granted, it is a problem that can be worked around in PHP code, but it still shouldn't crash the process with a segfault. An error or warning would be the correct result. cyclic references aren't supported by the engine - same as infinite recursions (which crash the engine, too). tc -- 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] is_link() behavior
The readlink() function? You mean the is_link() function no? The readlink() function is something completely different. Can you also try those other two functions? lstat() and filetype()? Andi At 12:48 AM 4/25/2001 -0500, J. Jones wrote: Oh.. the readlink () function works fine in both instances.. readlink passed: /bin/false readlink passed: /this/file/does/not/exist -- 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] is_link() behavior
On Wed, Apr 25, 2001 at 08:56:47AM +0200, Andi Gutmans wrote: I commited another fix. is_link() should work correctly now. If things have improved and you have problems with lstat() and filetype() (which I think there's a good chance that they are screwed up) let me know. Thanks, Andi --new output :(01:02am ~/php): ./fs-test.php is_link passed readlink passed: /bin/false filetype passed: link lstat passed: Array ( [0] = 770 [1] = 749 [2] = 41471 [3] = 1 [4] = 0 [5] = 0 [6] = 0 [7] = 10 [8] = 988178527 [9] = 988178527 [10] = 988178527 [11] = 4096 [12] = 1 ) is_link passed readlink passed: /this/file/does/not/exist Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or directory) in ./fs-test.php on line 11 filetype failed Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or directory) in ./fs-test.php on line 14 lstat failed --end That's good enough for me.. is_link() and readlink() (what more do I really need for links?) both work perfect. One thing.. is source tree/main/fopen-wrappers.h renamed to source tree/main/fopen_wrappers.h in CVS, or is that a typo? ;) Thanks alot! Jeremy -- 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: 4.0.5: Merge Request
The question right now is how to best implement this. Do we add something to the bug database to flag bugs in some manner and have a release candidate summary page? Or do we separate it out of the bug database and maintain the list manually? OK, my opinion would be to put a copy of the currently known bugs with the RC source. To give people a local (ie offline) list to look at. Then, why not use a ranking scheme, people rate how much they feel a specific bug needs fixing before the new version.. ie As a major version say v5 would have lots of new features, but 4.0.6 for example mainly bug killings with maybe some feature improvements, 4.1 would contain bug killings (of course) but some new features but nothing earth shattering, and the bugs should be treated the same way. For 4.0.6 for example we should be aiming to get rid of all recreatable and rated very likely to be found bugs, with bugs ranking down to obscure things unlikely to be found by the masses - and weight them accordingly, so, the more likely it is to be found and annoy someone, the more we'd like to fix it before release. So, to your list, why not just add a voting for the QA people to vote how likely they feel it would come up/how much they would hope to see it in the next produce from the dev team? Is that a reasonable idea? -- 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] 4.0.5: Merge Request
At 11:04 PM 4/24/2001 -0700, Rasmus Lerdorf wrote: Having a better defined/reproduced list of bugs is a must and if the QA team can do that PHP will definitely benefit from it. However, today when they ask people to fix bugs they are often not fixed and I don't even think that they are necessarily looked at. That is why a defined everyone join forces to kill the bugs period would be a good thing. And whoever doesn't help isn't allowed to hack on his extension anymore (Just kidding :). Yes, but that is my point. They should not be asking people to fix bugs. They should simply be identifying and prioritizing the bugs. As a group we need to fix the bugs. Jani is complaining that they are ignored, so we need to change the atmosphere and remove that aspect from their duties. We are not going to change the way developers do their day-to-day jobs by much. But by changing the approach to one that is centered around an itemized list of issues I think we will completely change how things work. Imagine if there is only 1 criticl bug left on the list and it is in a piece of code you wrote? Everyone sees this list and everyone can see that as soon as this bug is fixed the release can go out. That will motivate a developer into holding off on playing with cool new features and taking a look at the bug. The question right now is how to best implement this. Do we add something to the bug database to flag bugs in some manner and have a release candidate summary page? Or do we separate it out of the bug database and maintain the list manually? For the QA guys it might be nice to be able to flag certain bugs in the bug database and then automatically create a summary page which could be sent to php-dev. However, I think it would take too much time to get started. Maybe just manually creating a list with a one line description of bug #, where the bug is and a short short summary would be best. This could be sent to php-dev. I think this is something for the QA guys to bite into and answer if they agree that this sort of approach would improve their lives and make them less grumpy. And the hackers will have to bite into the QA report because if they don't, then we get nowhere. Andi -- 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 #10485: no input file specified when running as a CGI
From: [EMAIL PROTECTED] Operating system: HP-UX 11 PHP version: 4.0.4pl1 PHP Bug Type: Scripting Engine problem Bug description: no input file specified when running as a CGI I am running PHP4 4.0.4pl1 on HP-UX11 (64 bit) and Apache 1.3.11. I compiled PHP4 with gcc and did not specify any options except --with-mysql. When I try to execute simple scripts like: #!/opt/php4/php -q echo foobar; I always get No input file specified. If I leave out the option -q my scripts work, but I always get as a first line #!/opt/php4/php which prevents me from using cookies :-( It is hardly possible to compile PHP on HP-UX, so I cannot (and do not want to) use PHP as an Apache module. I would be extremely happy to use PHP via CGI, but I am still running into this annoying bug which should be fixed long ago. At least the usenet is full of descriptions No input file specified when using PHP via CGI and I never encountered a solution. I have got it running on Apache and Windows 2000 without problems (since there was no need to compile anything :-), but this is not a suitable webserver. Cheers, Mark -- Edit Bug report at: http://bugs.php.net/?id=10485edit=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]
