[PHP-DEV] RE: Bug #11722 Updated: unable to fork with system command
Sorry you are correct about the versions.
I think it installed appache correctly it works with version php 4.0.1
I am using CGI version.
-Oorspronkelijk bericht-
Van: Bug Database [mailto:[EMAIL PROTECTED]]
Verzonden: donderdag 28 juni 2001 4:08
Aan: Erik Augustin
Onderwerp: Bug #11722 Updated: unable to fork with system command
ID: 11722
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Program Execution
Operating system:
PHP Version: 4.0.6
Assigned To:
Comments:
You have a time machine? Can you give me a copy of PHP 4.1? :)
I assume you meant PHP 4.0.1?
system() works for me just fine with PHP 4.0.6.
Are you sure you have installed PHP correctly?
Is it run as CGI or as Apache module?
Previous Comments:
---
[2001-06-27 03:23:09] [EMAIL PROTECTED]
I am running a appache 1.3 webserver with PHP 4.1
wen i use the command: system('md xxx');
everything works fine
now i have installed php4.6 and i get the message
unable to fork wenn i run the same script.
what am i doing wrong?
Do i need to start the process in background with an other program???
Many thanks in advance.
PHP is perfect.
Erik
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=11722edit=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 #11950 Updated: not sending e-mail at all
ID: 11950 Updated by: hholzgra Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Mail related Operating System: Debian Linux PHP Version: 4.0.5 New Comment: hm, i can't really belive this ... can you provide some example code a little bit more complete? Previous Comments: [2001-07-07 18:08:45] [EMAIL PROTECTED] A call to the mail function in the form: mail . will not send an e-mail. Using the following format: $something = mail . will send the e-mail correctly. I've encoutered this problem using the free web hosting provided by www.f2s.com, who are using Debian Linux. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11950edit=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 #11965: Compile falure when i trying to configure php with GD library
From: [EMAIL PROTECTED] Operating system: Solaris 2.7 Sparc PHP version: 4.0.5 PHP Bug Type: Compile Failure Bug description: Compile falure when i trying to configure php with GD library Compile falure when i trying to configure php with GD library. Configuration - ./configure --with-apache=../apache_1.3.19 --with-gd=/usr/local - passed (if i use another options such as --with or any other problem will stay). make (or gmake) filed Error code : Making all in gd gcc -I. -I/usr/local/src/php-4.0.5/ext/gd -I/usr/local/src/php-4.0.5/main -I/us r/local/src/php-4.0.5 -I/usr/local/src/apache_1.3.19/src/include -I/usr/local/sr c/apache_1.3.19/src/os/unix -I/usr/local/src/php-4.0.5/Zend -I/usr/local/include -I/usr/local/mysql/include/mysql -I/usr/local/src/php-4.0.5/ext/xml/expat/xmlto k -I/usr/local/src/php-4.0.5/ext/xml/expat/xmlparse -I/usr/local/src/php-4.0.5/T SRM -D_POSIX_PTHREAD_SEMANTICS -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -O2 -c gd .c touch gd.lo gd.c:91: conflicting types for `gdIOCtx' /usr/local/include/gd_io.h:18: previous declaration of `gdIOCtx' *** Error code 1 make: Fatal error: Command failed for target `gd.lo' Current working directory /usr/local/src/php-4.0.5/ext/gd *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/local/src/php-4.0.5/ext/gd *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/local/src/php-4.0.5/ext *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Without GD library all other options compiler and work correctly. -- Edit bug report at: http://bugs.php.net/?id=11965edit=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] Problem with globals ZTS
Hi derick, I did not know about that, since I could compile and work on my project for a while until this problem appear. So I should by VC++6 ? Gilles - Message d'origine - De : [EMAIL PROTECTED] À : Gilles Koffmann [EMAIL PROTECTED] Cc : Zeev Suraski [EMAIL PROTECTED]; PHP Developers Mailing List [EMAIL PROTECTED] Envoyé : jeudi 5 juillet 2001 09:02 Objet : Re: [PHP-DEV] Problem with globals ZTS On Thu, 5 Jul 2001, Gilles Koffmann wrote: Hello, I'm in ZTS mode. Building with VC++ 5, on win 98 with PHP 4.0.5 and apache 1.3.19. Is VC++ 5 supported? I thought you needed at least version 6... Derick - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net - -- 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 #11966: mysql_pconnect opens new connections with the same parameters
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.6 PHP Bug Type: MySQL related Bug description: mysql_pconnect opens new connections with the same parameters each new mysql_pconnect opens new connection. About system: see http://www.crimaniak.com/info.php Code: // defined constants: $DBServer, $DBUser, $DBPassword include(base.inc.php); // Open connection to server if(!$base=mysql_pconnect($DBServer,$DBUser,$DBPassword)) ErrExit(Error during connect to database: . mysql_error()); -- Edit bug report at: http://bugs.php.net/?id=11966edit=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 #11967: scan_set_error_return MUST NOT be inline
From: [EMAIL PROTECTED] Operating system: Compaq Tru64 Unix 5.1 PHP version: 4.0.6 PHP Bug Type: Compile Failure Bug description: scan_set_error_return MUST NOT be inline compiling PHP under Tru64 Unix 5.1 (using cc) results in a error if in the file ext/standard/scanf.h the function scan_set_error_return(int numVars,pval **turn_value); is defined inline void instead of simply void. /bin/sh /TI_a3/users/lele/php-4.0.6/libtool --silent --mode=compile cc -I. -I/TI_a3/users/lele/php-4.0.6/ext/standard -I/TI_a3/users/lele/php-4.0.6/main -I/TI_a3/users/lele/php-4.0.6 -I/usr/local/apache/include -I/TI_a3/users/lele/php-4.0.6/Zend -I/TI_a3/users/lele/php-4.0.6/ext/mysql/libmysql -I/TI_a3/users/lele/php-4.0.6/ext/xml/expat/xmltok -I/TI_a3/users/lele/php-4.0.6/ext/xml/expat/xmlparse -I/TI_a3/users/lele/php-4.0.6/TSRM -DOSF1 -DUSE_HSREGEX -DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -c file.c cc: Error: scanf.h, line 48: There is no definition for the inline function named scan_set_error_return in this compilation unit. (noinlfunc) inline void scan_set_error_return(int numVars,pval **return_value); ^ gmake[3]: *** [file.lo] Error 1 gmake[3]: Leaving directory `/TI_a3/users/lele/php-4.0.6/ext/standard' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/TI_a3/users/lele/php-4.0.6/ext/standard' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/TI_a3/users/lele/php-4.0.6/ext' gmake: *** [all-recursive] Error 1 defining the function as follows void scan_set_error_return(int numVars,pval **turn_value); results in a clean compilation -- Edit bug report at: http://bugs.php.net/?id=11967edit=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 #11968: Com Objects
From: [EMAIL PROTECTED]
Operating system: Windows
PHP version: 4.0.5
PHP Bug Type: COM related
Bug description: Com Objects
I am a Win 32 user of PHP 4 and I am trying to call a com component, the
PHP manual states that the following syntax work:
com_load()
com_invoke()
com_propget()
com_get()
com_propput()
com_propset()
com_set()
But they don't
After doing some reasearch I have fould that the actual syntax for
com_load() is COM('Component Name') and that com_invoke() is
$VariableAssignedToComObject-Comproperty = 'Value';
What I need to know is the actuall syntax used for:
com_propget()
com_get()
com_propput()
com_propset()
com_set()
It doesn't seem to be documented anywhere, can you help???
--
Edit bug report at: http://bugs.php.net/?id=11968edit=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 #11969: PHP repeats ODBC queries when using include()...
From: [EMAIL PROTECTED] Operating system: Windws 98 PHP version: 4.0.6 PHP Bug Type: Scripting Engine problem Bug description: PHP repeats ODBC queries when using include()... Hello, I have once again found another bug...you guys couldn't possibly remove them all, could you? :) Anyway, my problem is a very interesting one (this will take a while to read - so bear with me)...took me a while and lots of testing to verify that PHP v4.0.6 has a *MAJOR* problem with the ODBC engine when using include's (relative/absolute - doesn't matter). The short story is that there is no problem if you only include() one file. However, in my case, I've got includes 5-7 levels deep with file I/O and what-not...but no database calls except in the top-level routine. Here is the SQL code I was running against a database (trimmed down a bit): include($DBDir/initdb.php); $sql = SELECT MAX(ProdTitle_ID) AS Max_ProdTitle_ID FROM ProdTitle; $sql_result = odbc_exec($db, $sql); odbc_fetch_row($sql_result); ... $sql = INSERT INTO ProdTitle (ProdTitle_ID, ProdTitle_X, ProdDesc_X, ProdLogo_X, ProdScreens_X) VALUES ($Max_ProdTitle_ID, '$ProdTitle_X', '$ProdDesc_X', '$ProdLogo_X', '$ProdScreens_X'); echo $sqlbrbr; $sql_result = odbc_exec($db, $sql); ... include($DBDir/enddb.php); initdb.php and enddb.php perform normal odbc_connect and odbc_close operations. This portion of the code works fine. However, when I add the following line: include(index.php); PHP now does something extremely bizarre. index.php contains the following data: ? include(../index.php); ? PHP parses the includes and displays everything correctly on the page, however, when I check the database 1 extra row has been added, I have verified that PHP is re-executing the starting script, but it refuses to display anything from the 'echo $sqlbrbr;' line of code. Even more bizarre is that if I add, say, a SELECT statement and execute it but don't retrieve any results, PHP re-executes the starting script 3 times (thus 3 extra rows in the database). If there were a loopback in the script, PHP would run forever (I turned off the time-limit). If it was some scripting error, the 'echo $sqlbrbr;' result would have shown up in the response page. So, PHP is restarting the script on its own and destroying data integrity. Here is a snippet of a SQL capture that verifies what I've been talking about: First the SELECT statement... fffc020f-fffae443 ENTER SQLExecDirect HSTMT 00D7076C UCHAR * 0x00797670 [ -3] SELECT MAX(ProdTitle_ID) AS Max_ProdTitle_ID\ d\ aFROM ProdTitle\ 0 SDWORD-3 fffc020f-fffae443 EXIT SQLExecDirect with return code 0 (SQL_SUCCESS) HSTMT 00D7076C UCHAR * 0x00797670 [ -3] SELECT MAX(ProdTitle_ID) AS Max_ProdTitle_ID\ d\ aFROM ProdTitle\ 0 SDWORD-3 Now the INSERT statement - Note the values being inserted!!! fffc020f-fffae443 ENTER SQLExecDirect HSTMT 00D70C00 UCHAR * 0x0079AA60 [ -3] INSERT INTO ProdTitle (ProdTitle_ID, ProdTitle_X, ProdDesc_X, ProdLogo_X, ProdScreens_X)\ d\ a VALUES (5, 'asdf', 'asdf', ' ', ' ')\ 0 SDWORD-3 fffc020f-fffae443 EXIT SQLExecDirect with return code 0 (SQL_SUCCESS) HSTMT 00D70C00 UCHAR * 0x0079AA60 [ -3] INSERT INTO ProdTitle (ProdTitle_ID, ProdTitle_X, ProdDesc_X, ProdLogo_X, ProdScreens_X)\ d\ a VALUES (5, 'asdf', 'asdf', ' ', ' ')\ 0 SDWORD-3 So far so good. At this point the log file shows that the connection is being dropped and even the environment handle is destroyed. Then, all of a sudden, the connection is re-instated and two more queries are processed: First the SELECT statement (basically the same as before)... fffb7f03-fffb93db ENTER SQLExecDirect HSTMT 00D7076C UCHAR * 0x00796A90 [ -3] SELECT MAX(ProdTitle_ID) AS Max_ProdTitle_ID\ d\ aFROM ProdTitle\ 0 SDWORD-3 fffb7f03-fffb93db EXIT SQLExecDirect with return code 0 (SQL_SUCCESS) HSTMT 00D7076C UCHAR * 0x00796A90 [ -3] SELECT MAX(ProdTitle_ID) AS Max_ProdTitle_ID\ d\ aFROM ProdTitle\ 0 SDWORD-3 Next, the INSERT statement - this one is *VERY* different... fffb7f03-fffb93db ENTER
[PHP-DEV] Bug #11970: SEPARATE_ZVAL_TO_MAKE_IS_REF doesn't like 0x0
From: [EMAIL PROTECTED]
Operating system: SuSE7.0
PHP version: 4.0.6
PHP Bug Type: Scripting Engine problem
Bug description: SEPARATE_ZVAL_TO_MAKE_IS_REF doesn't like 0x0
function erm($key) {
return @$arr[$key];
}
$foo = erm('foo');
$bar = erm('bar');
(gdb) run bug3.php
Starting program: /usr/local/bin/php bug3.php
Program received signal SIGSEGV, Segmentation fault.
0x80a29e9 in execute (op_array=0x81d3348) at ./zend_execute.c:1592
1592 SEPARATE_ZVAL_TO_MAKE_IS_REF(retval_ptr_ptr);
(gdb) p retval_ptr_ptr
$1 = (zval **) 0x0
(gdb) bt
#0 0x80a29e9 in execute (op_array=0x81d3348) at ./zend_execute.c:1592
#1 0x80a26a8 in execute (op_array=0x81cdf5c) at ./zend_execute.c:1544
#2 0x8097234 in zend_execute_scripts (type=8, file_count=3) at
zend.c:752
#3 0x8065b4f in php_execute_script (primary_file=0xb694) at
main.c:1206
#4 0x8061173 in main (argc=2, argv=0xb724) at cgi_main.c:718
(gdb) list
1587(opline-op1.op_type != IS_CONST)
1588(opline-op1.op_type != IS_TMP_VAR)) {
1589
1590retval_ptr_ptr = get_zval_ptr_ptr(opline-op1, Ts, BP_VAR_W);
1591
1592SEPARATE_ZVAL_TO_MAKE_IS_REF(retval_ptr_ptr);
1593
1594(*retval_ptr_ptr)-refcount++;
1595(*EG(return_value_ptr_ptr)) = (*retval_ptr_ptr);
1596 } else {
notice that the second call [ erm('bar')] actually trigger the segfault.
patch: I dunno, Zeev somebody? :)
--
Edit bug report at: http://bugs.php.net/?id=11970edit=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 #11962 Updated: eval() doesn't handle multi-dimentional arrays.
ID: 11962 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Summary: eval() doesn't handle multi-dimentional arrays. Old Status: Open Status: Bogus Bug Type: Scripting Engine problem Operating System: RedHat 6.2 PHP Version: 4.0.6 New Comment: Your string equals 'echo $GLOBALS[page][title];', and RTFM why that doesn't work. Previous Comments: [2001-07-08 20:00:57] [EMAIL PROTECTED] It appears that eval() does not handle mutli-dimentional arrays properly e.g. $page[title] = 'Page'; $test = '$page[title]'; If I do: eval( 'echo '.$test.';' ); I get: Page as the output, however if I change $test to: $test = '$GLOBALS[page][title]'; then do: eval( 'echo '.$test.';' ); I get: Array[title] as my output. My best guess for the reason this is happening is that when eval() does a lookup for a variable in the symbol table it is going from top to bottom and stops on the first match, no matter how complete - From this I am assuming that the symbol table would be built as follows: $GLOBALS $GLOBALS[page] $GLOBALS[page][title] so if eval() searched from the top then it would find a partial match against $GLOBALS[page] which is what I think it is doing. A better example: $page[title] = 'Hello'; $string = '$page[title]'; eval( 'echo '.$string.';' ); echo br\n; $string = '$GLOBALS[page][title]'; eval( 'echo '.$string.';' ); I hope I make sense to you, if not then please let me know and I will try and be clearer. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11962edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: Bug #11962 Updated: eval() doesn't handle multi-dimentional arrays.
OK, so how come it works with 1 dimensional arrays? Surely it would make sense to make it work with multi-dimensional arrays or not with arrays full stop? Karl Austin -Original Message- From: Bug Database [mailto:[EMAIL PROTECTED]] Sent: 09 July 2001 12:09 To: [EMAIL PROTECTED] Subject: Bug #11962 Updated: eval() doesn't handle multi-dimentional arrays. ID: 11962 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Summary: eval() doesn't handle multi-dimentional arrays. Old Status: Open Status: Bogus Bug Type: Scripting Engine problem Operating System: RedHat 6.2 PHP Version: 4.0.6 New Comment: Your string equals'echo $GLOBALS[page][title];', and RTFM why that doesn't work. Previous Comments: [2001-07-08 20:00:57] [EMAIL PROTECTED] It appears that eval() does not handle mutli-dimentional arrays properly e.g. $page[title] = 'Page'; $test = '$page[title]'; If I do: eval( 'echo '.$test.';' ); I get: Page as the output, however if I change $test to: $test = '$GLOBALS[page][title]'; then do: eval( 'echo '.$test.';' ); I get: Array[title] as my output. My best guess for the reason this is happening is that when eval() does a lookup for a variable in the symbol table it is going from top to bottom and stops on the first match, no matter how complete - From this I am assuming that the symbol table would be built as follows: $GLOBALS $GLOBALS[page] $GLOBALS[page][title] so if eval() searched from the top then it would find a partial match against $GLOBALS[page] which is what I think it is doing. A better example: $page[title] = 'Hello'; $string = '$page[title]'; eval( 'echo '.$string.';' ); echo br\n; $string = '$GLOBALS[page][title]'; eval( 'echo '.$string.';' ); I hope I make sense to you, if not then please let me know and I will try and be clearer. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11962edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: Bug #11962 Updated: eval() doesn't handle multi-dimentional arrays.
Hi, My apologies to you, I have found how to make string substitution of multi-dimnetional arrays work - however, it was not until I downloaded a copy of the manual with user contributed errata that I found how to make it work, something like this really should be included in the actual manual and not just in the errata. Thank you, Karl Austin -- 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 #11962 Updated: eval() doesn't handle multi-dimentional arrays.
ID: 11962
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Summary: eval() doesn't handle multi-dimentional arrays.
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: RedHat 6.2
PHP Version: 4.0.6
New Comment:
Because the parser ain't smart enough, try echo $GLOBALS['page']['id']; or echo
{$GLOBALS['page']['id']}; (the first one is faster).
Derick
Previous Comments:
[2001-07-09 07:08:59] [EMAIL PROTECTED]
Your string equals
'echo $GLOBALS[page][title];', and RTFM why that doesn't work.
[2001-07-08 20:00:57] [EMAIL PROTECTED]
It appears that eval() does not handle mutli-dimentional arrays properly e.g.
$page[title] = 'Page';
$test = '$page[title]';
If I do:
eval( 'echo '.$test.';' );
I get:
Page
as the output, however if I change $test to:
$test = '$GLOBALS[page][title]';
then do:
eval( 'echo '.$test.';' );
I get:
Array[title]
as my output.
My best guess for the reason this is happening is that when eval() does a lookup for a
variable in the symbol table it is going from top to bottom and stops on the first
match, no matter how complete - From this I am assuming that the symbol table would be
built as follows:
$GLOBALS
$GLOBALS[page]
$GLOBALS[page][title]
so if eval() searched from the top then it would find a partial match against
$GLOBALS[page] which is what I think it is doing.
A better example:
$page[title] = 'Hello';
$string = '$page[title]';
eval( 'echo '.$string.';' );
echo br\n;
$string = '$GLOBALS[page][title]';
eval( 'echo '.$string.';' );
I hope I make sense to you, if not then please let me know and I will try and be
clearer.
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11962edit=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 #11972: library does not loaded
From: [EMAIL PROTECTED] Operating system: Windows2000 PHP version: 4.0.6 PHP Bug Type: MSSQL related Bug description: library does not loaded the following line is showed although library does exists on the specific folder together with others: PHP Warning: Unable to load dynamic library './extensions/php_mssql.dll' - The specified module could not be found. in Unknown on line 0 -- Edit bug report at: http://bugs.php.net/?id=11972edit=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 #11973: Parent's constructor uncallable directly from within child's methods.
From: [EMAIL PROTECTED]
Operating system: Windows 2000 Professional
PHP version: 4.0.5
PHP Bug Type: Class/Object related
Bug description: Parent's constructor uncallable directly from within child's methods.
Calling a parent class's constructor from a child's method does not work
without the parent:: operator, although the parent's constructor is listed
in the child's list of method as reported by get_class_methods().
Example script:
?PHP
class A
{
function A()
{
}
}
class B extends A
{
function foo()
{
A();
}
}
$obj = new B;
$obj-foo();
?
--
Edit bug report at: http://bugs.php.net/?id=11973edit=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 #10026 Updated: For loop always execute
ID: 10026 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Scripting Engine problem Operating System: RH Linux 6.1 PHP Version: 4.0.4pl1 New Comment: Please cut the background-color lines etc, and any line until it won't reproduce the bug. Then submit it again. And put a var_dump of all your imported globals and on the passed parameters on the beginning of the function, and submit it when you still think it's a bug. The script is too complicated to tell wether this is a bug, note that you pass $ref BY VALUE, and not by reference. Closed for now. Previous Comments: [2001-06-17 13:12:36] [EMAIL PROTECTED] I have solved the problem in another way. BUT; The value of $c *IS* 0 when entering for loop and the stange behavior of the for-loop explained above happens. I think it maybe is other part of the code BEFORE this function who make som crash in the system so this happen. I've never seen this before neither after so i dont know what more to say :) But for sure it was a strange behavior of PHP in this code. We are two persons coding this system and we both spent a lot of time trying to find out what happens (with echo and other debug code) but we could'nt find out. We had to drop the for-loop because it didnt work as it should. [2001-06-17 05:06:32] [EMAIL PROTECTED] I have spent twenty mins trying to recreate this, before you start your for loop please check the value of $c (echo it out etc) and make sure its what you expected. I very much doubt this is a bug, if the value of $c is indeed 0 then please reopen this report. - James [2001-04-04 08:34:26] [EMAIL PROTECTED] I'm sorry, but all other script i make work ok. Its just this one that cause the problem. I dont know how to make another script for you as i cant reproduce the error in any 5 line of code. - Svein [2001-04-04 08:28:35] [EMAIL PROTECTED] I asked for 'self-containing' script. ie. one that doesn't need anything outside but works as is. This example script you added is useless and can not be used to reproduce anything. Please create a SHORT (max 5 lines) script that doesn't work. --Jani [2001-04-04 06:26:22] [EMAIL PROTECTED] The parameter passed to the function i prev. post is the stricture returned from imag_fetchstructure... - Svein The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=10026 ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10026edit=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 #10026 Updated: For loop always execute
ID: 10026 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Scripting Engine problem Operating System: RH Linux 6.1 PHP Version: 4.0.4pl1 New Comment: Please cut the background-color lines etc, and any line until it won't reproduce the bug. Then submit it again. And put a var_dump of all your imported globals and on the passed parameters on the beginning of the function, and submit it when you still think it's a bug. The script is too complicated to tell wether this is a bug, note that you pass $ref BY VALUE, and not by reference. Closed for now. Previous Comments: [2001-07-09 07:51:42] [EMAIL PROTECTED] Please cut the background-color lines etc, and any line until it won't reproduce the bug. Then submit it again. And put a var_dump of all your imported globals and on the passed parameters on the beginning of the function, and submit it when you still think it's a bug. The script is too complicated to tell wether this is a bug, note that you pass $ref BY VALUE, and not by reference. Closed for now. [2001-06-17 13:12:36] [EMAIL PROTECTED] I have solved the problem in another way. BUT; The value of $c *IS* 0 when entering for loop and the stange behavior of the for-loop explained above happens. I think it maybe is other part of the code BEFORE this function who make som crash in the system so this happen. I've never seen this before neither after so i dont know what more to say :) But for sure it was a strange behavior of PHP in this code. We are two persons coding this system and we both spent a lot of time trying to find out what happens (with echo and other debug code) but we could'nt find out. We had to drop the for-loop because it didnt work as it should. [2001-06-17 05:06:32] [EMAIL PROTECTED] I have spent twenty mins trying to recreate this, before you start your for loop please check the value of $c (echo it out etc) and make sure its what you expected. I very much doubt this is a bug, if the value of $c is indeed 0 then please reopen this report. - James [2001-04-04 08:34:26] [EMAIL PROTECTED] I'm sorry, but all other script i make work ok. Its just this one that cause the problem. I dont know how to make another script for you as i cant reproduce the error in any 5 line of code. - Svein [2001-04-04 08:28:35] [EMAIL PROTECTED] I asked for 'self-containing' script. ie. one that doesn't need anything outside but works as is. This example script you added is useless and can not be used to reproduce anything. Please create a SHORT (max 5 lines) script that doesn't work. --Jani The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=10026 ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10026edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: Bug #11962 Updated: eval() doesn't handle multi-dimentionalarrays.
It's all in the manual. http://www.php.net/manual/en/language.types.string.php For parsing variables (and arrays) in strings, and also why it works with only one array-index. http://www.php.net/manual/en/language.types.array.php For how to access arrays (even variable ones). Jeroen On Mon, 9 Jul 2001, Karl Austin wrote: OK, so how come it works with 1 dimensional arrays? Surely it would make sense to make it work with multi-dimensional arrays or not with arrays full stop? Karl Austin -Original Message- From: Bug Database [mailto:[EMAIL PROTECTED]] Sent: 09 July 2001 12:09 To: [EMAIL PROTECTED] Subject: Bug #11962 Updated: eval() doesn't handle multi-dimentional arrays. ID: 11962 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Summary: eval() doesn't handle multi-dimentional arrays. Old Status: Open Status: Bogus Bug Type: Scripting Engine problem Operating System: RedHat 6.2 PHP Version: 4.0.6 New Comment: Your string equals'echo $GLOBALS[page][title];', and RTFM why that doesn't work. Previous Comments: [2001-07-08 20:00:57] [EMAIL PROTECTED] It appears that eval() does not handle mutli-dimentional arrays properly e.g. $page[title] = 'Page'; $test = '$page[title]'; If I do: eval( 'echo '.$test.';' ); I get: Page as the output, however if I change $test to: $test = '$GLOBALS[page][title]'; then do: eval( 'echo '.$test.';' ); I get: Array[title] as my output. My best guess for the reason this is happening is that when eval() does a lookup for a variable in the symbol table it is going from top to bottom and stops on the first match, no matter how complete - From this I am assuming that the symbol table would be built as follows: $GLOBALS $GLOBALS[page] $GLOBALS[page][title] so if eval() searched from the top then it would find a partial match against $GLOBALS[page] which is what I think it is doing. A better example: $page[title] = 'Hello'; $string = '$page[title]'; eval( 'echo '.$string.';' ); echo br\n; $string = '$GLOBALS[page][title]'; eval( 'echo '.$string.';' ); I hope I make sense to you, if not then please let me know and I will try and be clearer. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11962edit=1 Jeroen van Wolffelaar [EMAIL PROTECTED] http://www.A-Eskwadraat.nl/~jeroen -- 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 #11974: Pb with odbc_columns(); the 12th result(description)has a incorrect format
From: [EMAIL PROTECTED]
Operating system: Windows 98
PHP version: 4.0.6
PHP Bug Type: ODBC related
Bug description: Pb with odbc_columns(); the 12th result(description)has a incorrect
format
The problem is that after these 2 lines:
$resCol=odbc_columns($odbc_connect);
$des=odbc_result($resCol,12);
the print function works(the same for echo), and show the description as
asked, but when I have to use it
in an SQLreq., I have an error:
Warning: SQL error: [Microsoft][ODBC Microsoft Access Driver] Syntax error
in string in query expression ''(ex: media).'.,
SQL state 37000 in SQLExecDirect in
C:\Inetpub\wwwroot\cgi-bin\database\configok.php on line 95
As you can see I use an Access Database(2000)
I tried to cut the string in logical way or static way but I don't find
one working
for all. However, often, if I cut the last 30 c. with $des=substr ($des,
0,strlen($des)-30);, it works for several fields, but not all...I tried to
cut 3, to keep all until . that I had added to all my fields.
So here is a part of my code:(it's to make a table containing all fields
with their description all fields have a different name) and I can say that
there is not any problem with para 3(name of table),4(name of field):
$resCol=odbc_columns($odbc_connect);
$tablen=odbc_result($resTable,3);
while(odbc_fetch_row($resCol))
{
if (odbc_result($resCol,3)==$tablen)//if the table of
the column
{ //is
the table called
$i++ ;
$col=odbc_result($resCol,4); //set col to the name
of the field
//description doesn't
work###
$des=odbc_result($resCol,12);
//echo br;
//print strlen($des);
// echo br;
// $des=substr ($des, 0,strrpos ($des, .)-1);
$des=substr ($des, 0,strlen($des)-30);
// print strlen($des);
echo br;
if (empty($des))
{
$des=a definir;
}
echo description: $des ;
//###
if (!empty($HTTP_POST_VARS['fillFields']))
{
$sql=INSERT INTO [FieldsUsed] (field,tablen,
descript) VALUES ('$col', '$tablen','$des');
odbc_exec($odbc_connect,$sql);
}
--
Edit bug report at: http://bugs.php.net/?id=11974edit=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 #11972 Updated: library does not loaded
ID: 11972 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: MSSQL related Operating System: Windows2000 PHP Version: 4.0.6 New Comment: Try using a absolute path in your php.ini file. Derick Previous Comments: [2001-07-09 07:40:20] [EMAIL PROTECTED] the following line is showed although library does exists on the specific folder together with others: PHP Warning: Unable to load dynamic library './extensions/php_mssql.dll' - The specified module could not be found. in Unknown on line 0 ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11972edit=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 #9453 Updated: Reference issue
ID: 9453
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows 2000
PHP Version: 4.0.4pl1
New Comment:
This is expected behaviour. You *need* the $a = func(),
a mere function func() definition is not sufficient.
Agreed, this is not really nice... But $a = func() should
always return by value, you don't need to know how func() is
defined.
Equally, $a = func() shouldn't work when it isn't defined
as returning by reference, since the function might not be
expecting it.
Btw: This has nothing to with call_time_pass_ref
status-bogus
Previous Comments:
[2001-03-08 14:55:45] [EMAIL PROTECTED]
let's run this code
?php
class A{
function b($f) {
$d=$f;
$f='5';
return $d;
}
}
$c='3';
$d=new A();
$h=$d-b($c);
//$h=$d-b($c); //The is needed to work well
//we get $h=$c;
$h='9';
echo $c. ' '.$h;
//since we should see 9 9, but we can see 5 9
?
we get 5 9
If we adapt the code to:
//$h=$d-b($c);
$h=$d-b($c); //The is needed to work well
we get 9 9, and that should be the good value, rigth?
[2001-03-08 06:38:51] [EMAIL PROTECTED]
Works for me. What are the results in your case?
[2001-02-26 05:07:37] [EMAIL PROTECTED]
I tried it with: allow_call_time_pass_reference = Off and
allow_call_time_pass_reference= On
It seems that the result is not send automatically as a reference
class A{
function b($f) {
$d=$f;
$f='5';
return $d;
}
}
$c='3';
$d=new A();
$h=$d-b($c);
$h=$d-b($c); //The is needed to work well
$h='9';
echo $c. ' '.$h;
The value of c is not updated correctly if we don't ask for a reference
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9453edit=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] Re: [PHP-DOC] Re: [PHP-DEV] Security?
On Mon, 9 Jul 2001, Wez Furlong wrote: On 07/07/01, Andi Gutmans [EMAIL PROTECTED] wrote: Zeev suggested $__GET, $__POST and so on. I think this is a good idea, is very readable and saves a lot of typing. We also thought of possibly making these true globals such as $GLOBALS (just an idea, don't take my word for it :). What do you guys think? I'm all in for this too, but I thought there where some issues with making them true globals? regards, Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net - -- 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 #9420 Updated: url created arrays and isset
ID: 9420
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Redhat Linux 6.1
PHP Version: 4.0.4pl1
New Comment:
Very nasty, but not a bug :)
This proves why $string[offset] should be deprecated... took
me 10 minutes to find this out...
Anyway, $pair[key] == 'mwel'
$i[$pair[key]] = 0, and that is correct
And doing [ ] on a string will be interpreted as $str[offset].
As is in the manual, sysaction will be converted to 0, so
that means: get the first character of the string 0
shk: You chould have tracked it down a bit more... by
var_dumping step by step, and see that '0'['sysaction']
caused the same thing...
Previous Comments:
[2001-02-23 09:16:08] [EMAIL PROTECTED]
Make a file like this:
while($pair = each($i)) {
if (isset($i[$pair[key]][sysaction])) {
echo brWe have a bug!!br;
} else {
echo brThere are no bugs!!br;
}
}
and call it like this:
phpbug.php?i[mwsl]=0
Now isset will return true. If I create the array in php instead, it works fine.
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9420edit=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 #8413 Updated: connection_status() returns 0 on timeout
ID: 8413 Updated by: jeroen Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Scripting Engine problem Operating System: linux PHP Version: 4.0.4 New Comment: closing We should really nuke phpdoc/features/connection_handling, or rewrite it... Previous Comments: [2001-06-15 02:53:26] [EMAIL PROTECTED] This is obvious. The time the shutdown function is called, the status IS shutdown. AND the status IS timeout. That is obvious too :) It is a bit flag and it could also indicate that the connection was timeouted if only some php developer was not so lazy :))) And the connection_timeout() function is deprecated (and removed) as of 4.0.5 that is nice. The report was for 4.0.4 and the connection_timeout() was used only to make the code shorter. Change it to connection_status() and reopen the bug. How can I determine that the script was terminated due to execution_time limit? connection_status() is not depricated yet, is it? But it still doesn't return the TIMEOUT status. Just grep through the code... PHP_CONNECTION_TIMEOUT is defined but never used. Is it also depricated? =oleg [2001-06-14 16:44:00] [EMAIL PROTECTED] This is obvious. The time the shutdown function is called, the status IS shutdown. And the connection_timeout() function is deprecated (and removed) as of 4.0.5 [2001-01-15 08:55:55] [EMAIL PROTECTED] use standalone php to get the output or change the code somehow to get the result of connection_status() and connection_timeout() some other way (write to file, for example) the point is that it seems to be impossible to check for timeout state: connection_status() and connection_timeout() both return zero while the shutdown function was definitly called due to timeout. The example is stupid but it is short and clearly demonstartes the bug. oleg [2001-01-13 13:33:34] [EMAIL PROTECTED] I get no output at all (RH6.2 4.0.4 NT5 php4-200101130745) [2000-12-25 07:02:52] [EMAIL PROTECTED] I am not sure what bug type to choose... So I change it to Unknown/Other for now. oleg The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=8413 ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8413edit=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 #8413 Updated: connection_status() returns 0 on timeout
ID: 8413 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Scripting Engine problem Operating System: linux PHP Version: 4.0.4 New Comment: closing We should really nuke phpdoc/features/connection_handling, or rewrite it... Previous Comments: [2001-07-09 08:22:09] [EMAIL PROTECTED] closing We should really nuke phpdoc/features/connection_handling, or rewrite it... [2001-06-15 02:53:26] [EMAIL PROTECTED] This is obvious. The time the shutdown function is called, the status IS shutdown. AND the status IS timeout. That is obvious too :) It is a bit flag and it could also indicate that the connection was timeouted if only some php developer was not so lazy :))) And the connection_timeout() function is deprecated (and removed) as of 4.0.5 that is nice. The report was for 4.0.4 and the connection_timeout() was used only to make the code shorter. Change it to connection_status() and reopen the bug. How can I determine that the script was terminated due to execution_time limit? connection_status() is not depricated yet, is it? But it still doesn't return the TIMEOUT status. Just grep through the code... PHP_CONNECTION_TIMEOUT is defined but never used. Is it also depricated? =oleg [2001-06-14 16:44:00] [EMAIL PROTECTED] This is obvious. The time the shutdown function is called, the status IS shutdown. And the connection_timeout() function is deprecated (and removed) as of 4.0.5 [2001-01-15 08:55:55] [EMAIL PROTECTED] use standalone php to get the output or change the code somehow to get the result of connection_status() and connection_timeout() some other way (write to file, for example) the point is that it seems to be impossible to check for timeout state: connection_status() and connection_timeout() both return zero while the shutdown function was definitly called due to timeout. The example is stupid but it is short and clearly demonstartes the bug. oleg [2001-01-13 13:33:34] [EMAIL PROTECTED] I get no output at all (RH6.2 4.0.4 NT5 php4-200101130745) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=8413 ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8413edit=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 #10639 Updated: include() require()
ID: 10639
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: AIX 4.3.3
PHP Version: 4.0.4pl1
New Comment:
Could you submit the results when test.inc:
- is chmod a-r
- is chmod a+r ?
Apparently PHP crashes trying to open the file.
Try also, in stead of th include(), a
$fp = fopen('test.inc');
echo fread($fp,filesize('test.inc'));
fclose($fp);
To see wether the problem is in the include() or simply in
opening of the file. This also with word-readable on/off.
Previous Comments:
[2001-05-10 14:17:01] [EMAIL PROTECTED]
Just for information:
1. I've updated AIX 4.3.3 now to the Maintenance-Level 8 (the latest one). But the
problem is unchanged.
2. I'm using the binary package: php-4.0.4pl1-1.aix4.3.ppc.rpm
from: ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/RPMS/ppc/php
--stephan
[2001-05-10 14:00:20] [EMAIL PROTECTED]
In /var/opt/freeware/apache/logs/error_log i've found the following error:
[Thu May 10 19:41:41 2001] [notice] child pid 5444 exit signal Illegal instruction (4)
Every time when i try the test.php with the included file this error occurs.
-- Stephan
[2001-05-10 13:42:42] [EMAIL PROTECTED]
Without the test.inc file i've got the following lines:
this is a test
Warning: Failed opening 'test.inc' for inclusion
(include_path='.:/opt/freeware/lib/php') in
/usr/opt/freeware/apache/share/htdocs/test.php on line 4
With the test.inc file i've got only the IE error, that this page is not available.
-- Stephan
[2001-05-10 06:00:45] [EMAIL PROTECTED]
Try this script:
?php
echo this is a test;
error_reporting(E_ALL);
include(test.inc);
?
Any errors reported? In error_log maybe?
--Jani
[2001-05-10 05:53:49] [EMAIL PROTECTED]
Yes.
-- Stephan
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=10639
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10639edit=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 #10967 Updated: $x .= someFunction();
ID: 10967
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: win2k
PHP Version: 4.0.5
New Comment:
This is nonsense, what do you expect of $x .=
somefunction()? that the second part of $x gets referenced?
Previous Comments:
[2001-06-12 15:36:34] [EMAIL PROTECTED]
well your playing with references where they are not needed.. expect to get your
fingers burnt.
[2001-05-22 16:50:28] [EMAIL PROTECTED]
uhm, well, the thing with the $temp var is useless. i see now that i cannot reference
something into *a part* of something else.
but the silent loss of br\n is still a problem, imo.
fab
[2001-05-18 23:41:12] [EMAIL PROTECTED]
code i would like to use:
---cut---
function someShit() {
return 'foo';
}
$out = '';
for ($i = 1; $i = 3; $i++) {
$out .= someShit() . br\n;
}
echo $out;
---cut---
problem:
parse error on line
$out .= someShit() . br\n;
because .= and don't work together.
so the workaround would be:
$temp = someShit() . br\n;
$out .= $temp;
problem here:
it prints out 'foofoofoo' and not
'foobr\nfoobr\nfoobr\n'
so the code finally looks like:
---cut---
function someShit() {
return 'foo';
}
$out = '';
for ($i = 1; $i = 3; $i++) {
$temp = someShit();
$out .= $temp . br\n;
}
echo $out;
---cut---
is this the normal behavior?
fab
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10967edit=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 #11975: mix of hebrew english
From: [EMAIL PROTECTED] Operating system: Win98 PHP version: 4.0.6 PHP Bug Type: *General Issues Bug description: mix of hebrew english Hi, I have some problem using hebrevc() with mixed sentense of hebrew english. Text example from textarea (right-to-left): english-2hebrew-1 hebrew-3 The text result: hebrew-1english-2 hebrew-3 How can I solve this switching problem? Regards, Barak Shimoni. -- Edit bug report at: http://bugs.php.net/?id=11975edit=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 #11911 Updated: Speed Problem
ID: 11911
Updated by: kalowsky
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: ODBC related
Operating System: Linux RedHat 7.1
PHP Version: 4.0.6
New Comment:
on your linux build did you use --with-openlink or --with-iodbc?
if it was --with-openlink, try to rebuild using the --with-iodbc instead, as one is
maintained, the other isn't ;)
Previous Comments:
[2001-07-05 11:57:21] [EMAIL PROTECTED]
We have 2 machines, one NT and the other LInux. Both run PHP. The Linux machine runs
Apache and the NT machine runs IIS 4.
The Linux machine is a database server. If we run the PHP script on the NT machine
against the database on the Linux machine, the result is instantaneous, however if we
run the script from the Linux machine against it's local database, it takes 20 seconds
to respond.
The database method of access is via Openlink ODBC.
html
head
meta http-equiv=refresh content=10;url=http://ifusion.isoft.co.za/test.php;
/head
head
meta http-equiv=refresh content=10;url=http://ifusion.isoft.co.za/test.php;
H1 Omnix Interface into HEAT /H1
H2 Waiting for Transactions .. /H2
/head
?
//function dq($str) {
// $str = trim(\.$str.\,);
//return ($str);
//}
print Running Test.phpBR;
//$Err = ;
if (!($db = odbc_connect(Omnix000,,,1))) {
print ** There is no Omnix Server for Database sqlHEAT**;
exit();
}
$Sql = select name from drsmas;
//$Sql .=WHERE jobcard '';
$callLog = odbc_prepare($db,$Sql);
$x = odbc_execute($callLog);
//if ($x) PRINT Good = $x ;
//$callLog = odbc_exec($db,$Sql);
//print No of rows= .odbc_num_rows($callLog);
//while(odbc_fetch_row($callLog)){
/*for ($i = 1; $i 10; $i++){
//odbc_fetch_row($callLog);
$name = odbc_result($callLog,1);
print data= $name BR;
}
*/
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11911edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] php 4.1 or php 5.0
Well, I think to start with someone or multiple people need to take a look at the PHP code and figure out just exactly what we want to do to it. I can help out. I am pretty sure that Daniel Beckham will as well. As far as I know, we want to: 1. convert all function names to a standard naming convention. 2. convert all function params to a standard order. 3. get rid of old aliased functions. 4. Make sure all return codes are consistent. Some are 1 or 0 some are true or false. What else is there? I am sure there is more. Brian Moon -- dealnews.com, Inc. Makers of dealnews, dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Brian Moon [EMAIL PROTECTED]; php developers [EMAIL PROTECTED] Sent: Thursday, July 05, 2001 4:53 PM Subject: Re: [PHP-DEV] php 4.1 or php 5.0 I think both for Zend 2 and for the cleanup version of PHP (if they happen at the same time or not) it is important to come up with how to do the development. We can either work in a branch or create a new CVS tree. They both have their pros cons, but especially for the PHP CVS which is a moving target it's going to be hard to make a cleanup and keep the patches in sync with the being cleaned version. It'll be easier for Zend because it is very stable and doesn't change very much. Any ideas? Andi At 05:27 PM 7/4/2001 +0100, Phil Driscoll wrote: On Wednesday 04 July 2001 17:12, Brian Moon wrote: FWIW, I am +1 on PHP5. There are a lot of things in the language that need to be cleaned up. People here more familiar with other closed languages have gotten confused about things like case, underscores, haystack and needle, the way some array functions return an array and some modify the passed array. There is just a lot of stuff like that. I'm all for making the radical changes at 5.0, its just that it seems like Zeev is keen on a shortish timeframe for the new engine, whereas I suspect that tidying up the language will take quite a bit longer. FWIW my vote is for us to make a concerted start on tidying the language with a realistic time frame of guess 1 year. If the new Zend engine is going to be ready much sooner than that, and it will only affect OO stuff and the business of accessing individual characters in strings, then that change should be to 4.1. If the engine is going to take a year, then we'll have a big pile of stuff to launch as 5.0 Cheers -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] [PATCH] for bug#10721
Hi,
I've made a patch for 10721, based on justin's, and it now works
correctly.
Andi/Zeev, would you please commit this?
Jeroen
Jeroen van Wolffelaar
[EMAIL PROTECTED]
http://www.A-Eskwadraat.nl/~jeroen
Index: zend_builtin_functions.c
===
RCS file: /repository/Zend/zend_builtin_functions.c,v
retrieving revision 1.93
diff -u -r1.93 zend_builtin_functions.c
--- zend_builtin_functions.c2001/06/26 15:19:47 1.93
+++ zend_builtin_functions.c2001/07/09 13:39:05
@@ -958,11 +958,11 @@
}
function_add_ref(func);
- function_name = (char *)
emalloc(sizeof(0lambda_)+MAX_LENGTH_OF_LONG);
+ function_name = (char *)
+emalloc(sizeof(lambda_)+MAX_LENGTH_OF_LONG);
do {
- sprintf(function_name, %clambda_%d, 0, ++EG(lambda_count));
- function_name_length = strlen(function_name+1)+1;
+ sprintf(function_name, lambda_%d, ++EG(lambda_count));
+ function_name_length = strlen(function_name);
} while (zend_hash_add(EG(function_table), function_name,
function_name_length+1, func, sizeof(zend_function), NULL)==FAILURE);
zend_hash_del(EG(function_table), LAMBDA_TEMP_FUNCNAME,
sizeof(LAMBDA_TEMP_FUNCNAME));
RETURN_STRINGL(function_name, function_name_length, 0);
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10721 Updated: odd output in create_function()
ID: 10721
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: GNU/Linux
PHP Version: 4.0.6
Old Assigned To:
Assigned To: jeroen
New Comment:
Fixed the patch, only waiting for it to get committed.
Previous Comments:
[2001-06-27 16:21:20] [EMAIL PROTECTED]
Any word on this? Still exists in 4.0.6.
[2001-05-07 23:10:15] [EMAIL PROTECTED]
An odd character seems to appear in the return value of
create_function() (which should be of 'lambda_x' format
where x is an integer). This character is causing eval() to
crap out when trying to evaluate the created function. Just
before the 'l' is a character that looks like Pi in the
browser. The only way I knew to find out what it was was to
urlencode() the return value and the strange character was
encoded to '%00'. I'm no C coder, but the changes below
seemed to fix things.
*** /tmp/zend_builtin_functions.c Mon May 7 22:09:45 2001
--- /usr/local/src/php-4.0.5/Zend/zend_builtin_functions.c Mon May 7 22:03:31
2001
***
*** 965,974
}
function_add_ref(func);
! function_name = (char *)
emalloc(sizeof(0lambda_)+MAX_LENGTH_OF_LONG);
do {
!
sprintf(function_name, %clambda_%d, 0, ++EG(lambda_count));
function_name_length = strlen(function_name+1)+1;
} while (zend_hash_add(EG(function_table), function_name,
function_name_length+1, func, sizeof(zend_function),
NULL)==FAILURE);
zend_hash_del(EG(function_table), LAMBDA_TEMP_FUNCNAME,
sizeof(LAMBDA_TEMP_FUNCNAME));
--- 965,974
}
function_add_ref(func);
! function_name = (char *)
emalloc(sizeof(lambda_)+MAX_LENGTH_OF_LONG);
do {
!
sprintf(function_name, lambda_%d, ++EG(lambda_count));
function_name_length = strlen(function_name+1)+1;
} while (zend_hash_add(EG(function_table), function_name,
function_name_length+1, func, sizeof(zend_function),
NULL)==FAILURE);
zend_hash_del(EG(function_table), LAMBDA_TEMP_FUNCNAME,
sizeof(LAMBDA_TEMP_FUNCNAME));
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10721edit=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 #11976: image_copy_resized does not work properly
From: [EMAIL PROTECTED]
Operating system: windows 98 SE
PHP version: 4.0.6
PHP Bug Type: GD related
Bug description: image_copy_resized does not work properly
I used this function in a script with PHP 4.0.5. It works very well. I
installed PHP 4.0.6 and the script doesn't work anymore?
I found that it was this function who didn't work well.
Sorry about my English.
See my script:
?
Header(Content-type: image/png);
$x=400;
$y=400;
$data=array (3, 1, 7, 2, 5, 4, 6);
$im = imagecreate($x,$y);
$black = ImageColorAllocate($im, 0,0,0);
$blue = ImageColorAllocate($im, 0,36,135);
$white = ImageColorAllocate($im, 255,255,255);
ImageFilledRectangle($im,0,0,$x,$y,$white);
imageline($im,0,50,$x,50,$black);
imageline($im,$x-50,0,$x-50,$y,$black);
for($i=0;$isizeof($data);$i++)
{
ImageFilledRectangle($im,$i*50+15,51,$i*50+40,51+$data[$i]*30,$blue);
}
$image=imagecreate(500,500);
imagecopyresized($image,$im,0,0,0,0,400,400,400,400);
Imagepng($image);
?
--
Edit bug report at: http://bugs.php.net/?id=11976edit=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 #11977: no PHP.ini failure apache loading libphp4.so
From: [EMAIL PROTECTED] Operating system: Redhat 7.1 (Seawolf) PHP version: 4.0.6 PHP Bug Type: *Compile Issues Bug description: no PHP.ini failure apache loading libphp4.so I have installed PHP, but it seems that the install doesn't create a php.ini Can't find it anywhere. I have compiled php this way: ./configure \ --with-apxs=/usr/sbin/apxs \ --with-config-file-path=/etc/php \ --with-gd \ --with-xml \ --with-mysql \ --with-zlib \ --enable-track-vars \ --enable-inline-optimization \ --with-gd=shared \ --with-mysql=/usr/local \ --enable-force-cgi-redirect \ --enable-trans-sid \ --enable-ftp \ --with-magic-quotes \ --with-imap \ --with-ldap make make install I'm also getting an error if I try to start apache: Cannot load /usr/lib/apache/libphp4.so into server: /usr/lib/apache/libphp4.so: undefined symbol: mxdriver Is this a bug? With kind regards, Franck Nijhof -- Edit bug report at: http://bugs.php.net/?id=11977edit=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 #11978: ltconfig in infinite loop looking for echo
From: [EMAIL PROTECTED] Operating system: HP-UX 10.20 PHP version: 4.0.6 PHP Bug Type: *Compile Issues Bug description: ltconfig in infinite loop looking for echo This is 10958 all over again. Solved the problem by setting echo to 'print -r' at the top of the file. If you did remove ltconfig from the CVS version, you must have put it back. -- Edit bug report at: http://bugs.php.net/?id=11978edit=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 #11979: could not open ttf file
From: [EMAIL PROTECTED] Operating system: WINDOWS 98 PHP version: 4.0.6 PHP Bug Type: GD related Bug description: could not open ttf file ? Header (Content-type: image/png); $im = @imagecreate (700, 30)or die (no image crate !); $black = ImageColorAllocate ($im, 50, 50, 50); $white = ImageColorAllocate ($im, 255, 255, 255); ImageTTFText ($im, 20, 0, 10, 20, $white, arial.ttf,QUESTA E' UNA PAGINA DINAMICA DI PROVA !!!) or die (something wrong !!!); ImagePng($im); ? font is in the path ! win 98 apache mysql -- Edit bug report at: http://bugs.php.net/?id=11979edit=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 #11979 Updated: could not open ttf file
ID: 11979 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: GD related Operating System: WINDOWS 98 PHP Version: 4.0.6 New Comment: Try the full path to the font. and if that does not work, reopen this report. Derick Previous Comments: [2001-07-09 10:30:57] [EMAIL PROTECTED] ? Header (Content-type: image/png); $im = @imagecreate (700, 30)or die (no image crate !); $black = ImageColorAllocate ($im, 50, 50, 50); $white = ImageColorAllocate ($im, 255, 255, 255); ImageTTFText ($im, 20, 0, 10, 20, $white, arial.ttf,QUESTA E' UNA PAGINA DINAMICA DI PROVA !!!) or die (something wrong !!!); ImagePng($im); ? font is in the path ! win 98 apache mysql ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11979edit=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 #11980: problem with forms
From: [EMAIL PROTECTED] Operating system: windows PHP version: 4.0.6 PHP Bug Type: Unknown/Other Function Bug description: problem with forms i am using a combobox autocompleted by a mysql database uith citys. ex buenos aires (is one city with 2 names separated by 1 space). when the form is submited the variable is contening only the first name like buenos in my ex. why is this hapening? how can i fix that? -- Edit bug report at: http://bugs.php.net/?id=11980edit=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] Possible feature for current version of PHP or PHP 4.1/5.0.
On Sun, 08 Jul 2001, Andi Gutmans wrote: Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? I'll buy you a beer if this gets done. ;-) -Andrei Give a man a fish; you have fed him for today. Teach a man to fish; and you can sell him fishing equipment. -Author unknown -- 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: [Zend Engine 2] Fwd: Re: [PHP-DEV] php 4.1 or php 5.0
This discussion should take place on [EMAIL PROTECTED] On Mon, 9 Jul 2001, Jani Taskinen wrote: On Mon, 9 Jul 2001 [EMAIL PROTECTED] wrote: I would go for PHP5, however that means Zeev will commit suicide... Why not jump over numbers 5 6 and call it PHP 7 ? :) Or do the Microsoft: PHP 2001 (j/k) anyway, this way we can also break a lot of other things and make the language clean. I can't wait.. :-) I'm also in favor of creating a new branch because this way nothing can be messed up on the PHP4 branches and we can do some really experimental things with it too. If the goal is 4.1, branch should be enough. If PHP 5/6/7, then it should be separate cvs module, IMO. btw. To get rid of some of the unmaintained extensions we should have some directory for them? Something like /old /deprecated /unmaintained ? --Jani patches in sync with the being cleaned version. It'll be easier for Zend because it is very stable and doesn't change very much. Any ideas? Andi At 05:27 PM 7/4/2001 +0100, Phil Driscoll wrote: On Wednesday 04 July 2001 17:12, Brian Moon wrote: FWIW, I am +1 on PHP5. There are a lot of things in the language that need to be cleaned up. People here more familiar with other closed languages have gotten confused about things like case, underscores, haystack and needle, the way some array functions return an array and some modify the passed array. There is just a lot of stuff like that. I'm all for making the radical changes at 5.0, its just that it seems like Zeev is keen on a shortish timeframe for the new engine, whereas I suspect that tidying up the language will take quite a bit longer. FWIW my vote is for us to make a concerted start on tidying the language with a realistic time frame of guess 1 year. If the new Zend engine is going to be ready much sooner than that, and it will only affect OO stuff and the business of accessing individual characters in strings, then that change should be to 4.1. If the engine is going to take a year, then we'll have a big pile of stuff to launch as 5.0 Cheers -- Phil Driscoll -- 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] Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net - - 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 #11980 Updated: problem with forms
ID: 11980 Updated by: brianlmoon Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Unknown/Other Function Operating System: windows PHP Version: 4.0.6 New Comment: We would need to see your code to determine the problem. At first thought, it sounds like you might not have around the values in your option tags. Brian. Previous Comments: [2001-07-09 10:58:43] [EMAIL PROTECTED] i am using a combobox autocompleted by a mysql database uith citys. ex buenos aires (is one city with 2 names separated by 1 space). when the form is submited the variable is contening only the first name like buenos in my ex. why is this hapening? how can i fix that? ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11980edit=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 #11980 Updated: problem with forms
ID: 11980 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Bogus Bug Type: Unknown/Other Function Operating System: windows PHP Version: 4.0.6 New Comment: Use quotes as the HTML specs say you need to do that. Derick Previous Comments: [2001-07-09 11:06:17] [EMAIL PROTECTED] We would need to see your code to determine the problem. At first thought, it sounds like you might not have around the values in your option tags. Brian. [2001-07-09 10:58:43] [EMAIL PROTECTED] i am using a combobox autocompleted by a mysql database uith citys. ex buenos aires (is one city with 2 names separated by 1 space). when the form is submited the variable is contening only the first name like buenos in my ex. why is this hapening? how can i fix that? ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11980edit=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 #11826 Updated: Custom sessions handler using Metabase calls crashes Apache
ID: 11826
Updated by: rasmus
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: WinMe, Linux
PHP Version: 4.0.4
New Comment:
Your test handler doesn't crash PHP for me with the latest CVS version on Linux.
Previous Comments:
[2001-07-08 18:32:29] [EMAIL PROTECTED]
I have isolated the bug but did not find the cause. It makes strtok()
crash when attempting to free memory that has been trashed.
It only happens when strtok is called from session on read or on write
handles. I could not find what is wrong in strtok but I suspect there is
inconsistent use of PHP internal global variables (strtok_string) inside
session handle functions. So it seems to be a serious PHP bug that may
also crash scripts that use strtok or other functions from inside session
handle functions that use PHP internal global variables
Metabase is no longer affected by this PHP bug because I have banned all
the uses of strtok function. A new version of Metabase was uploaded to
http://phpclasses.UpperDesign.com/browse.html/package/20 . If you use
Metabase for session handling your are strongly encouraged to download this
version.
For reproducing the PHP strtok bug without Metabase, try the script below.
?php
function on_session_start ($save_path, $session_name)
{
return true;
}
function on_session_end()
{
return true;
}
function on_session_read ($key)
{
return true;
}
function on_session_write ($key, $val)
{
$query=SELECT * FROM sessions;
$select=(strtolower(strtok($query, ))==select);
return true;
}
function on_session_destroy ($key)
{
return true;
}
function on_session_gc ($max_lifetime)
{
return true;
}
// Set the save handlers
session_set_save_handler(on_session_start, on_session_end,
on_session_read,
on_session_write,
on_session_destroy,
on_session_gc);
session_start();
// Register the $counter variable as part of the sesssion
session_register('counter');
$counter = 1;
echo 'Session test started';
?
[2001-07-07 19:59:23] [EMAIL PROTECTED]
Most likely, none of the developers are actually USING
Metabase, so this bug is simply getting glossed over.
Perhaps a reproducible test case that does not require
usage or knowledge of Metabase would help...
IE, while we really appreciate all the work you have
gone through to document this bug, and make these scripts
available, until we can see the bug OUTSIDE of the Metabase
package, it probably won't get a lot of attention.
[2001-07-07 12:46:49]
It's interesting that in the last week this bug report has not gotten a single reply.
It is an easily reproducable bug that Manuel Lemos (author of the Metabase database
abstraction layer) believes is a problem with PHP. He has assured me that the problem
is not with Metabase so, accordingly:
There must be a bug with custom session handlers called
using
session_set_save_handler
(on_session_start, on_session_end,
on_session_read, on_session_write,
on_session_destroy, on_session_gc);
that is making it crash when Metabase calls are used in the start/end/read/write etc.
functions.
As Metabase is one of the best solutions out there for database abstraction with PHP
(are there any others that allow database schema in XML and the range of type
conversion options, etc? Or are as well documented?) I believe that this bug at least
deserves a reply from the developer community. (Even if it is along the lines of: 'We
don't care, fix it yourself' just so I know!)
I have included a link to all code necessary to reproduce the crash in my original bug
report and I've streamlined the code so that only logic necessary for the bug to be
seen is present.
[2001-07-01 16:39:14] [EMAIL PROTECTED]
I have included in the downloadable file a full installation of Metabase and also a
session handler that uses plain old MySQL calls to save the session information (this
does *not* crash the server and is there to help with your testing -- it is called
mysql_sessions.php and can be tested just by including it in the nabsession_test.php
and nabsession_test2.php scripts in the place of metabase_sessions.php.)
[2001-07-01 16:35:37] [EMAIL PROTECTED]
This error has been reproduced on WinMe running Apache 1.3.19, PHP 4.04, MySQL 3.23.37
and Linux running Apache 1.3.12, PHP 4.0.3pl1, MySQL 3.23.6.
When a custom session handler is set up that points to functions that use Manuel
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
Yeah, this has been requested several times. I think that changing the cwd to the directory of an included file makes good sense. It is, indeed, downwards incompatible and may break existing applications. We have 4 options: 1. Do nothing 2. Make include() and friends change directory to the directory of the file they include. This makes the most sense, but may break existing apps. 3. #2, only make it optional 4. Add the directory of the included file to the include_path when the included file is being executed. It can get a bit nasty with nested includes, even though I think it should work. It's also a bit tricky to implement, as the engine doesn't know about include_path (at least right now). I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. Zeev At 18:14 8/7/2001, Andi Gutmans wrote: Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? 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] -- 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 #11981: no ttf file open
From: [EMAIL PROTECTED] Operating system: win98 PHP version: 4.0.6 PHP Bug Type: GD related Bug description: no ttf file open ? Header (Content-type: image/png); $im = @imagecreate (700, 30)or die (no image crate !); $black = ImageColorAllocate ($im, 50, 50, 50); $white = ImageColorAllocate ($im, 255, 255, 255); ImageTTFText ($im, 20, 0, 10, 20, $white, arial.ttf,QUESTA E' UNA PAGINA DINAMICA DI PROVA !!!) or die (something wrong !!!); ImagePng($im); ? font is in the path ! win 98 apache mysql -- I try the full path ! but it doesn't work ! I try to reopen the the report 11969 but it doesn't work error with password (but the password is correct) . -- Edit bug report at: http://bugs.php.net/?id=11981edit=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] [patch] safe mode gid check
This is a patch against php-4.0.4pl1. Description: In Safe Mode, when opening files the UID of the script owner and the UID of the destination file are compared. In some circumstances it is desired that this check be relaxed to a GID compare. The attached patch adds a php ini directive safe_mode_gid (boolean, default: Off). When this is On, a GID compare is performed if the UID compare fails. Additionally this patch adds a new PHP function getmygid(), which returns the GID of the executing script (see getmyuid()). Author: James Flemer [EMAIL PROTECTED] CITS / Web Developer The University of Vermont [ Please CC me in all replies, I am not subscribed to the list. ] Thanks, -James --- php-4.0.4pl1/FUNCTION_LIST.txt 2001/07/09 15:11:32 1.1 +++ php-4.0.4pl1/FUNCTION_LIST.txt 2001/07/09 15:10:27 @@ -83,6 +83,7 @@ get_current_user getmyuid + getmygid getmypid u getmyinode getlastmod --- php-4.0.4pl1/php.ini-dist 2001/07/09 15:12:08 1.1 +++ php-4.0.4pl1/php.ini-dist 2001/07/09 15:15:27 @@ -90,6 +90,10 @@ ; Safe Mode safe_mode = Off +safe_mode_gid = Off + ; By default, Safe Mode does a UID compare + + ; check when opening files. If you want to + + ; relax this to a GID compare, then turn on + + ; safe_mode_gid. safe_mode_exec_dir = safe_mode_allowed_env_vars = PHP_ ; Setting certain environment variables ; may be a potential security breach. --- php-4.0.4pl1/php.ini-optimized 2001/07/09 15:12:11 1.1 +++ php-4.0.4pl1/php.ini-optimized 2001/07/09 15:15:37 @@ -77,6 +77,10 @@ ; Safe Mode safe_mode = Off +safe_mode_gid = Off + ; By default, Safe Mode does a UID compare + + ; check when opening files. If you want to + + ; relax this to a GID compare, then turn on + + ; safe_mode_gid. safe_mode_exec_dir = safe_mode_allowed_env_vars = PHP_ ; Setting certain environment variables ; may be a potential security breach. --- php-4.0.4pl1/main/main.c2001/07/08 20:53:18 1.1 +++ php-4.0.4pl1/main/main.c2001/07/09 00:27:42 @@ -228,6 +228,7 @@ STD_PHP_INI_BOOLEAN(register_argc_argv, 1,PHP_INI_ALL, OnUpdateBool, register_argc_argv, php_core_globals, core_globals) STD_PHP_INI_BOOLEAN(register_globals, 1,PHP_INI_ALL, OnUpdateBool, register_globals, php_core_globals, core_globals) STD_PHP_INI_BOOLEAN(safe_mode,0, PHP_INI_SYSTEM, OnUpdateBool, safe_mode, php_core_globals, core_globals) + STD_PHP_INI_BOOLEAN(safe_mode_gid,0, +PHP_INI_SYSTEM, OnUpdateBool, safe_mode_gid, + php_core_globals, core_globals) STD_PHP_INI_BOOLEAN(short_open_tag, 1, PHP_INI_SYSTEM|PHP_INI_PERDIR, OnUpdateBool, short_tags, zend_compiler_globals, compiler_globals) STD_PHP_INI_BOOLEAN(sql.safe_mode,0, PHP_INI_SYSTEM, OnUpdateBool, sql_safe_mode, php_core_globals, core_globals) STD_PHP_INI_BOOLEAN(track_errors, 0, PHP_INI_ALL,OnUpdateBool, track_errors, php_core_globals, core_globals) --- php-4.0.4pl1/main/php_globals.h 2001/07/08 20:53:18 1.1 +++ php-4.0.4pl1/main/php_globals.h 2001/07/09 00:17:38 @@ -63,6 +63,7 @@ zend_bool implicit_flush; zend_bool safe_mode; + zend_bool safe_mode_gid; zend_bool sql_safe_mode; zend_bool enable_dl; --- php-4.0.4pl1/main/safe_mode.c
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
On Mon, 09 Jul 2001, Zeev Suraski wrote: Yeah, this has been requested several times. I think that changing the cwd to the directory of an included file makes good sense. It is, indeed, downwards incompatible and may break existing applications. We have 4 options: 1. Do nothing 2. Make include() and friends change directory to the directory of the file they include. This makes the most sense, but may break existing apps. 3. #2, only make it optional 4. Add the directory of the included file to the include_path when the included file is being executed. It can get a bit nasty with nested includes, even though I think it should work. It's also a bit tricky to implement, as the engine doesn't know about include_path (at least right now). I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. How about #3 for 4.1 and #2 for 5.0? -Andrei * If it's never finished, you can't prove it doesn't work. * -- 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] Possible feature for current version of PHP or PHP 4.1/5.0.
At 10:02 AM 7/9/2001 -0500, Andrei Zmievski wrote: On Sun, 08 Jul 2001, Andi Gutmans wrote: Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? I'll buy you a beer if this gets done. ;-) Now I've got more incentive :) 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] Bug #8135 Updated: FTP_FPUT can't use a HTTP Filepointer
Sorry, I was half of sleep that night. The idea here is to be able to read from the fopen()'ed stream and ftp_fput() the data.. not the other way around. (Jason, READ the bug reports before closing them, also RTFM) Exaclty what manual would you like me to read, Jani? -Jason --Jani Previous Comments: [2001-07-07 00:21:15] [EMAIL PROTECTED] HTTP fopens are read only. -Jason [2000-12-06 10:43:07] [EMAIL PROTECTED] for example : $fp = fopen(http://www.php.net;, r); ftp_fput( $ftp_stream, remote, $fp, FTP_ASCII); doesn't work. But the following code-example : $fp = fopen(file.txt, r); ftp_fput( $ftp_stream, remote, $fp, FTP_ASCII); works. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8135edit=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 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 #11982: session_expires()
From: [EMAIL PROTECTED]
Operating system: Windows2000
PHP version: 4.0.6
PHP Bug Type: Feature/Change Request
Bug description: session_expires()
I have a feature request for the session module in php. This request should
be self-explaining. I would appreciate if a session_expires(int seconds)
function would be implemented. Defining when a session will expire in
seconds.
This function should destroy the session if the session is expired. Also,
let the function return 1 if the session is expired, and 0 if it's not
expired. Then it could be used in cases like:
if(session_is_expired()) {
...expired...die
}
else {
...not expired, continue...
}
--
Edit bug report at: http://bugs.php.net/?id=11982edit=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] [UPDATE] NGScan
New patches are available which address a couple of problems. - the HTML buffer was too conservative sometimes - single quotes were handled inefficiently - scanning strings (e.g. due to eval()) did not work - compiling a file did not initialize some things correctly - some escape sequences in double quotes were mistreated - 'cvs diff -N' is buggy, so that new files were created in the wrong place 'make test' works flawlessly now. Please refer to http://schumann.cx/ngscan.html for further information. Especially due to the last point which requires fixing up patches manually every time, I'd like to commit the PHP part of things. Would anyone object to that? - 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]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
How about #3 for 4.1 and #2 for 5.0? This would be wonderful! Aral :) __ ([EMAIL PROTECTED]) New Media Producer, Kismia, Inc. ([EMAIL PROTECTED]) Adj. Prof., American University ¯¯ -- 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 #11952 Updated: NO UNINSTALL
ID: 11952 Updated by: phildriscoll Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: *General Issues Operating System: Windows 98 PHP Version: 4.0.6 New Comment: Assuming you used the PHP Installer from the downloads page at www.php.net, it won't have done anything to your system or registry which will mess things up if you just deleting the files it installed. If you would actually like to get PHP working (since it really does work!) then send a message to the php-install list. Previous Comments: [2001-07-07 21:48:26] [EMAIL PROTECTED] I was looking for a program that would open/display *.php files. I thought this PHP program was it. I installed it, went to the websites that use *.php files for graphics. It still would not display the images. So, I went to uninstall your program and there is NO UNINSTALL. Not even anything in control panel for uninstalling it. There was a re-boot involved in this installation, so, I don't want to just delete the C:\PHP directory, as I have a feeling the registry was changed somewhere along the way. Thanks for your help. Pat C. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11952edit=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] [patch] safe mode gid check
Could you recreate this patch against current CVS? I think it is a good idea, but your patch doesn't work at all against the current code. Instructions about getting the code from CVS can be found here: http://php.net/anoncvs.php -Rasmus On Mon, 9 Jul 2001, James E. Flemer wrote: This is a patch against php-4.0.4pl1. Description: In Safe Mode, when opening files the UID of the script owner and the UID of the destination file are compared. In some circumstances it is desired that this check be relaxed to a GID compare. The attached patch adds a php ini directive safe_mode_gid (boolean, default: Off). When this is On, a GID compare is performed if the UID compare fails. Additionally this patch adds a new PHP function getmygid(), which returns the GID of the executing script (see getmyuid()). Author: James Flemer [EMAIL PROTECTED] CITS / Web Developer The University of Vermont [ Please CC me in all replies, I am not subscribed to the list. ] Thanks, -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]
[PHP-DEV] RE: Bug #11935 Updated: php 4.0.6 doesn't work with solid option
what doesn't work? and do please try 4.0.5, or even 4.0.6 as there have been changes for SOLID in both versions. Php 4.0.5 and 4.0.6 versions aren't ok, if I compile php module with solid option (--with-solid=[dir]) apache starts and stops immediatly. Without this options apache is good! I've follow the istructions on www.php.net and www.phpitalia.com, but the installation aren't good, i think there're the problem with php. -Original Message- From: Bug Database [mailto:[EMAIL PROTECTED]] Sent: Friday, July 06, 2001 6:11 PM To: [EMAIL PROTECTED] Subject: Bug #11935 Updated: php 4.0.6 doesn't work with solid option ID: 11935 Updated by: kalowsky Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Old-Bug Type: Apache related Bug Type: ODBC related Operating system: PHP Version: 4.0.6 Assigned To: Comments: can you please provide more information? what doesn't work? and do please try 4.0.5, or even 4.0.6 as there have been changes for SOLID in both versions. Previous Comments: --- [2001-07-06 11:42:21] [EMAIL PROTECTED] I've install php 4.0.4, but apache doesn't start with solid option --with-solid=[dir] --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11935edit=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] [UPDATE] NGScan
Especially due to the last point which requires fixing up patches manually every time, I'd like to commit the PHP part of things. Would anyone object to that? I wouldn't object. -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 #11935 Updated: php 4.0.6 doesn't work with solid option
ID: 11935 Updated by: kalowsky Reported By: [EMAIL PROTECTED] Old Summary: php 4.0.6 doesn't work with solid option Status: Feedback Bug Type: ODBC related Operating System: Linux RedHat 6.2 PHP Version: 4.0.6 New Comment: and what does it stop saying? the other thing to note, if this is with solid 3.5, you need the latest libraries from SolidTech for it to work properly. Previous Comments: [2001-07-06 12:10:37] [EMAIL PROTECTED] can you please provide more information? what doesn't work? and do please try 4.0.5, or even 4.0.6 as there have been changes for SOLID in both versions. [2001-07-06 11:42:21] [EMAIL PROTECTED] I've install php 4.0.4, but apache doesn't start with solid option --with-solid=[dir] ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11935edit=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] ANNOUNCE: SAPRFC extension
Koucký Eduard wrote: Maybe this extension can be useful not only for me. Therefore I would like get it into the official PHP extension tree (CVS: php4/ext/saprfc). I would like ask you, if is it possible and what can I do for it ? well, first of all there is a license issue you have chosen the GPL for your extension but both the SAP libraries and PHP are currently under a license not compatible with the GPL things might change as far as PHP is concerned, but chances that SAP changes the license for the RFC libraries are not good IMHO you have three options to resolve this: 1) switch to the PHP license which is a BSD style license 2) switch to the LGPL which gives your code the same protection as the GPL but allows to link against code not GPL compatible 3) stay with the GPL but add a special permission clause that allows to link your extension against PHP, the Zend Engine and the RFC libs besides that you should apply for a CVS account (theres a request form somewhere on php.net) or ask someone who already has one to check in the code for you i might volunteer for this as i already started a RFC extension of my own so that i should be able to 'judge' your code somehow ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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] [UPDATE] NGScan
On Mon, Jul 09, 2001 at 08:55:09AM -0700, Rasmus Lerdorf wrote: Especially due to the last point which requires fixing up patches manually every time, I'd like to commit the PHP part of things. Would anyone object to that? I wouldn't object. same here 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] [UPDATE] NGScan
Sascha Schumann wrote: Would anyone object to that? +1 -- sebastian bergmannhttp://www.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [patch] safe mode gid check
Here is the patch against current CVS. Use: cd php4; patch -p0 php-safe-gid.diff -James CITS / Web Developer The University of Vermont On Mon, 9 Jul 2001, Rasmus Lerdorf wrote: Could you recreate this patch against current CVS? I think it is a good idea, but your patch doesn't work at all against the current code. Instructions about getting the code from CVS can be found here: http://php.net/anoncvs.php -Rasmus On Mon, 9 Jul 2001, James E. Flemer wrote: This is a patch against php-4.0.4pl1. Description: In Safe Mode, when opening files the UID of the script owner and the UID of the destination file are compared. In some circumstances it is desired that this check be relaxed to a GID compare. The attached patch adds a php ini directive safe_mode_gid (boolean, default: Off). When this is On, a GID compare is performed if the UID compare fails. Additionally this patch adds a new PHP function getmygid(), which returns the GID of the executing script (see getmyuid()). Author: James Flemer [EMAIL PROTECTED] CITS / Web Developer The University of Vermont [ Please CC me in all replies, I am not subscribed to the list. ] Thanks, -James Index: php.ini-dist === RCS file: /repository/php4/php.ini-dist,v retrieving revision 1.86 diff -u -r1.86 php.ini-dist --- php.ini-dist2001/07/04 03:53:12 1.86 +++ php.ini-dist2001/07/09 16:23:57 @@ -111,6 +111,11 @@ ; safe_mode = Off +; By default, Safe Mode does a UID compare check when +; opening files. If you want to relax this to a GID compare, +; then turn on safe_mode_gid. +safe_mode_gid = Off + ; When safe_mode is on, only executables located in the safe_mode_exec_dir ; will be allowed to be executed via the exec family of functions. safe_mode_exec_dir = Index: php.ini-optimized === RCS file: /repository/php4/php.ini-optimized,v retrieving revision 1.40 diff -u -r1.40 php.ini-optimized --- php.ini-optimized 2001/06/24 22:40:41 1.40 +++ php.ini-optimized 2001/07/09 16:23:57 @@ -81,6 +81,10 @@ ; Safe Mode safe_mode = Off +safe_mode_gid = Off + ; By default, Safe Mode does a UID compare + + ; check when opening files. If you want to + + ; relax this to a GID compare, then turn on + + ; safe_mode_gid. safe_mode_exec_dir = safe_mode_allowed_env_vars = PHP_ ; Setting certain environment variables ; may be a potential security breach. Index: ext/standard/basic_functions.c === RCS file: /repository/php4/ext/standard/basic_functions.c,v retrieving revision 1.357 diff -u -r1.357 basic_functions.c --- ext/standard/basic_functions.c 2001/07/09 10:20:40 1.357 +++ ext/standard/basic_functions.c 2001/07/09 16:24:03 @@ -268,6 +268,7 @@ #endif PHP_FE(getmyuid, NULL) + PHP_FE(getmygid, + NULL) PHP_FE(getmypid, NULL) PHP_FE(getmyinode, NULL) PHP_FE(getlastmod, NULL) @@ -846,6 +847,7 @@ BG(mmap_file) = NULL; #endif BG(page_uid) = -1; + BG(page_gid) = -1; BG(page_inode) = -1; BG(page_mtime) = -1; #ifdef HAVE_PUTENV Index: ext/standard/basic_functions.h === RCS file: /repository/php4/ext/standard/basic_functions.h,v retrieving revision 1.80 diff -u -r1.80 basic_functions.h --- ext/standard/basic_functions.h 2001/05/22 19:19:04 1.80 +++ ext/standard/basic_functions.h 2001/07/09 16:24:03 @@ -155,6 +155,7 @@ /* pageinfo.c */ long page_uid; + long page_gid; long page_inode; long page_mtime; Index: ext/standard/pageinfo.c === RCS file: /repository/php4/ext/standard/pageinfo.c,v retrieving revision 1.23 diff -u -r1.23 pageinfo.c --- ext/standard/pageinfo.c 2001/06/06 13:05:51 1.23 +++
[PHP-DEV] Bug #11965 Updated: Compile falure when i trying to configure php with GD library
ID: 11965 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Compile Failure Operating System: Solaris 2.7 Sparc PHP Version: 4.0.5 New Comment: Fixed in PHP 4.0.6. Previous Comments: [2001-07-09 04:04:44] [EMAIL PROTECTED] Compile falure when i trying to configure php with GD library. Configuration - ./configure --with-apache=../apache_1.3.19 --with-gd=/usr/local - passed (if i use another options such as --with or any other problem will stay). make (or gmake) filed Error code : Making all in gd gcc -I. -I/usr/local/src/php-4.0.5/ext/gd -I/usr/local/src/php-4.0.5/main -I/us r/local/src/php-4.0.5 -I/usr/local/src/apache_1.3.19/src/include -I/usr/local/sr c/apache_1.3.19/src/os/unix -I/usr/local/src/php-4.0.5/Zend -I/usr/local/include -I/usr/local/mysql/include/mysql -I/usr/local/src/php-4.0.5/ext/xml/expat/xmlto k -I/usr/local/src/php-4.0.5/ext/xml/expat/xmlparse -I/usr/local/src/php-4.0.5/T SRM -D_POSIX_PTHREAD_SEMANTICS -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -O2 -c gd .c touch gd.lo gd.c:91: conflicting types for `gdIOCtx' /usr/local/include/gd_io.h:18: previous declaration of `gdIOCtx' *** Error code 1 make: Fatal error: Command failed for target `gd.lo' Current working directory /usr/local/src/php-4.0.5/ext/gd *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/local/src/php-4.0.5/ext/gd *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/local/src/php-4.0.5/ext *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Without GD library all other options compiler and work correctly. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11965edit=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 #8135 Updated: FTP_FPUT can't use a HTTP Filepointer
ID: 8135 Updated by: jason Reported By: [EMAIL PROTECTED] Old Summary: FTP_FPUT can't use a HTTP Filepointer Old Status: Open Status: Assigned Bug Type: FTP related Operating System: Linux 7.0 PHP Version: 4.0.3pl1 Old Assigned To: Assigned To: [EMAIL PROTECTED] New Comment: Sorry nico, I misread the ticket, The problem is that the ftp extension hasn't been updated to support socket based file descriptors. I will take a look at a fix for this. -Jason Previous Comments: [2001-07-08 18:46:32] [EMAIL PROTECTED] The idea here is to be able to read from the fopen()'ed stream and ftp_fput() the data.. not the other way around. (Jason, READ the bug reports before closing them, also RTFM) --Jani [2001-07-07 00:21:15] [EMAIL PROTECTED] HTTP fopens are read only. -Jason [2000-12-06 10:43:07] [EMAIL PROTECTED] for example : $fp = fopen(http://www.php.net;, r); ftp_fput( $ftp_stream, remote, $fp, FTP_ASCII); doesn't work. But the following code-example : $fp = fopen(file.txt, r); ftp_fput( $ftp_stream, remote, $fp, FTP_ASCII); works. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8135edit=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 #11983: GLOBAL vars HTTP_RAW_POST_DATA and HTTP_FDF_DATA do not exist
From: [EMAIL PROTECTED] Operating system: PHP version: 4.0.5 PHP Bug Type: FDF related Bug description: GLOBAL vars HTTP_RAW_POST_DATA and HTTP_FDF_DATA do not exist Neither of the GLOBAL variables HTTP_RAW_POST_DATA or HTTP_FDF_DATA exist is the session environment. Although the FDF forms variables DO appear as parsed variables, but the raw form data is gone? There's nothing to configure in the FDFTK. -- Edit bug report at: http://bugs.php.net/?id=11983edit=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 #11969 Updated: PHP repeats ODBC queries when using include()...
ID: 11969 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Scripting Engine problem Operating System: Windws 98 PHP Version: 4.0.6 New Comment: What if you change the include()'s to include_once() ? --Jani Previous Comments: [2001-07-09 06:13:37] [EMAIL PROTECTED] Hello, I have once again found another bug...you guys couldn't possibly remove them all, could you? :) Anyway, my problem is a very interesting one (this will take a while to read - so bear with me)...took me a while and lots of testing to verify that PHP v4.0.6 has a *MAJOR* problem with the ODBC engine when using include's (relative/absolute - doesn't matter). The short story is that there is no problem if you only include() one file. However, in my case, I've got includes 5-7 levels deep with file I/O and what-not...but no database calls except in the top-level routine. Here is the SQL code I was running against a database (trimmed down a bit): include($DBDir/initdb.php); $sql = SELECT MAX(ProdTitle_ID) AS Max_ProdTitle_ID FROM ProdTitle; $sql_result = odbc_exec($db, $sql); odbc_fetch_row($sql_result); ... $sql = INSERT INTO ProdTitle (ProdTitle_ID, ProdTitle_X, ProdDesc_X, ProdLogo_X, ProdScreens_X) VALUES ($Max_ProdTitle_ID, '$ProdTitle_X', '$ProdDesc_X', '$ProdLogo_X', '$ProdScreens_X'); echo $sqlbrbr; $sql_result = odbc_exec($db, $sql); ... include($DBDir/enddb.php); initdb.php and enddb.php perform normal odbc_connect and odbc_close operations. This portion of the code works fine. However, when I add the following line: include(index.php); PHP now does something extremely bizarre. index.php contains the following data: ? include(../index.php); ? PHP parses the includes and displays everything correctly on the page, however, when I check the database 1 extra row has been added, I have verified that PHP is re-executing the starting script, but it refuses to display anything from the 'echo $sqlbrbr;' line of code. Even more bizarre is that if I add, say, a SELECT statement and execute it but don't retrieve any results, PHP re-executes the starting script 3 times (thus 3 extra rows in the database). If there were a loopback in the script, PHP would run forever (I turned off the time-limit). If it was some scripting error, the 'echo $sqlbrbr;' result would have shown up in the response page. So, PHP is restarting the script on its own and destroying data integrity. Here is a snippet of a SQL capture that verifies what I've been talking about: First the SELECT statement... fffc020f-fffae443 ENTER SQLExecDirect HSTMT 00D7076C UCHAR * 0x00797670 [ -3] SELECT MAX(ProdTitle_ID) AS Max_ProdTitle_ID\ d\ aFROM ProdTitle\ 0 SDWORD-3 fffc020f-fffae443 EXIT SQLExecDirect with return code 0 (SQL_SUCCESS) HSTMT 00D7076C UCHAR * 0x00797670 [ -3] SELECT MAX(ProdTitle_ID) AS Max_ProdTitle_ID\ d\ aFROM ProdTitle\ 0 SDWORD-3 Now the INSERT statement - Note the values being inserted!!! fffc020f-fffae443 ENTER SQLExecDirect HSTMT 00D70C00 UCHAR * 0x0079AA60 [ -3] INSERT INTO ProdTitle (ProdTitle_ID, ProdTitle_X, ProdDesc_X, ProdLogo_X, ProdScreens_X)\ d\ a VALUES (5, 'asdf', 'asdf', ' ', ' ')\ 0 SDWORD-3 fffc020f-fffae443 EXIT SQLExecDirect with return code 0 (SQL_SUCCESS) HSTMT 00D70C00 UCHAR * 0x0079AA60 [ -3] INSERT INTO ProdTitle (ProdTitle_ID, ProdTitle_X, ProdDesc_X, ProdLogo_X, ProdScreens_X)\ d\ a VALUES (5, 'asdf', 'asdf', ' ', ' ')\ 0 SDWORD-3 So far so good. At this point the log file shows that the connection is being dropped and even the environment handle is destroyed. Then, all of a sudden, the connection is re-instated and two more queries are processed: First the SELECT statement (basically the same as before)... fffb7f03-fffb93db ENTER SQLExecDirect HSTMT 00D7076C UCHAR * 0x00796A90 [ -3] SELECT MAX(ProdTitle_ID) AS Max_ProdTitle_ID\ d\ aFROM ProdTitle\ 0 SDWORD-3 fffb7f03-fffb93db EXIT SQLExecDirect with return code 0 (SQL_SUCCESS) HSTMT 00D7076C UCHAR * 0x00796A90 [ -3] SELECT
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
At 18:35 9/7/2001, Andrei Zmievski wrote: I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. How about #3 for 4.1 and #2 for 5.0? Yep, that's what I meant. 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] [UPDATE] NGScan
I think this whole thing is messy. Abstracting PHP to work with multiple scanners, or putting a scanner outside the scripting engine, both make no sense. I don't want to see something which is purely wrong from a technical standpoint, done because of some licensing issue. If you don't want to implement it in the way that makes sense from a technical standpoint (i.e., replace the Zend flex scanner), there are several options. One, you can wait. As we discussed on Thursday and on Saturday, the Zend Engine license may change, and may make you feel more comfortable in submitting this code into it. This scanner issue is not very pressing, as it only makes a considerable improvement in thread-safe builds of PHP. Secondly, if you don't want to wait for so long, we (as in, people other than you) can implement this re2c scanner ourselves. Andi actually began doing a bit of research on this about two weeks before you published your patches (he heard re2c was faster), so he stopped for now (I actually didn't know he was playing with it :) Attaching an eye to PHP's foot because you don't like the way the eye socket looks right now, makes no sense. Zeev At 18:49 9/7/2001, Sascha Schumann wrote: New patches are available which address a couple of problems. - the HTML buffer was too conservative sometimes - single quotes were handled inefficiently - scanning strings (e.g. due to eval()) did not work - compiling a file did not initialize some things correctly - some escape sequences in double quotes were mistreated - 'cvs diff -N' is buggy, so that new files were created in the wrong place 'make test' works flawlessly now. Please refer to http://schumann.cx/ngscan.html for further information. Especially due to the last point which requires fixing up patches manually every time, I'd like to commit the PHP part of things. Would anyone object to that? - 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] -- 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] Possible feature for current version of PHP or PHP 4.1/5.0.
I actually had in mind something like option #4 but not exactly what Zeev wrote. I thought that what we could do is if cwd and include_path fail then try and open at the same directory level as the currently executing script. I think it can be done but haven't completely checked it from a technical point of view. Andi At 07:50 PM 7/9/2001 +0300, Zeev Suraski wrote: At 18:35 9/7/2001, Andrei Zmievski wrote: I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. How about #3 for 4.1 and #2 for 5.0? Yep, that's what I meant. 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] Possible feature for current version of PHP or PHP 4.1/5.0.
Just want to pipe up and say I'm worried about a potential performance hit here. I'm building an enterprise web app that includes over 30 files on every request. Will changing the directory for the include file, and changing it back after create a significant performance hit? (I would think so). Just to point out -- things might get a little more confusing here... because if people get to pretend that the file they are including is being executed in the directory where it is stored, they may have problems adjusting to the idea of making links and images (in HTML) relative to the script that called their file, and they might have to end up re-implementing existing workarounds anyway. Just a thought. -Brian Tanner -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: July 9, 2001 5:48 AM To: Andi Gutmans Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. Yeah, this has been requested several times. I think that changing the cwd to the directory of an included file makes good sense. It is, indeed, downwards incompatible and may break existing applications. We have 4 options: 1. Do nothing 2. Make include() and friends change directory to the directory of the file they include. This makes the most sense, but may break existing apps. 3. #2, only make it optional 4. Add the directory of the included file to the include_path when the included file is being executed. It can get a bit nasty with nested includes, even though I think it should work. It's also a bit tricky to implement, as the engine doesn't know about include_path (at least right now). I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. Zeev At 18:14 8/7/2001, Andi Gutmans wrote: Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? 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] -- 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 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] Possible feature for current version of PHP or PHP 4.1/5.0.
At 12:07 PM 7/9/2001 -0700, Brian Tanner wrote: Just want to pipe up and say I'm worried about a potential performance hit here. I'm building an enterprise web app that includes over 30 files on every request. Will changing the directory for the include file, and changing it back after create a significant performance hit? (I would think so). I think that it will effect performance and therefore I wouldn't want to go in the direction of chdir(). Andi Just to point out -- things might get a little more confusing here... because if people get to pretend that the file they are including is being executed in the directory where it is stored, they may have problems adjusting to the idea of making links and images (in HTML) relative to the script that called their file, and they might have to end up re-implementing existing workarounds anyway. Just a thought. -Brian Tanner -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: July 9, 2001 5:48 AM To: Andi Gutmans Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. Yeah, this has been requested several times. I think that changing the cwd to the directory of an included file makes good sense. It is, indeed, downwards incompatible and may break existing applications. We have 4 options: 1. Do nothing 2. Make include() and friends change directory to the directory of the file they include. This makes the most sense, but may break existing apps. 3. #2, only make it optional 4. Add the directory of the included file to the include_path when the included file is being executed. It can get a bit nasty with nested includes, even though I think it should work. It's also a bit tricky to implement, as the engine doesn't know about include_path (at least right now). I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. Zeev At 18:14 8/7/2001, Andi Gutmans wrote: Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? 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] -- 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 Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11984: filetype function not working for non-existant files
From: [EMAIL PROTECTED] Operating system: Windows 98 PHP version: 4.0.6 PHP Bug Type: Filesystem function related Bug description: filetype function not working for non-existant files Regression error from 4.0.5 to 4.0.6. Looks like using filetype on a non-existant file, returns the value of the last valid call. Seen on the pre-compiled win32 flavour download with all modules. ?php echo filetype(c:/zz.zzz); echo filetype(c:/); echo filetype(c:/zz.zzz); ? Produces br bWarning/b: Unknown file type (0) in b-/b on line b2/bbr unknowndirdir on 4.0.6. The file zzz.zzz does not exist. 4.0.5 returns dir with no warning. clearstatcache() has no effect. Have to explicitly check for file existance with file_exists under this release. -- Edit bug report at: http://bugs.php.net/?id=11984edit=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 #11983 Updated: GLOBAL vars HTTP_RAW_POST_DATA and HTTP_FDF_DATA do not exist
ID: 11983 Updated by: rasmus Reported By: [EMAIL PROTECTED] Status: Open Bug Type: FDF related Operating System: PHP Version: 4.0.5 New Comment: $HTTP_RAW_POST_DATA only exists when the mime type of the POST is unrecognized, so in the case of an FDF post it is normal that the raw post data array doesn't exist. $HTTP_FDF_DATA should however exist and from looking at the code in ext/fdf/fdf.c in the fdf_post_handler() function, I don't quite see how you are managing to get the fdf vars but not the HTTP_FDF_DATA array, but then again there could very well be a bug hiding here. Previous Comments: [2001-07-09 12:46:01] [EMAIL PROTECTED] Neither of the GLOBAL variables HTTP_RAW_POST_DATA or HTTP_FDF_DATA exist is the session environment. Although the FDF forms variables DO appear as parsed variables, but the raw form data is gone? There's nothing to configure in the FDFTK. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11983edit=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] Possible feature for current version of PHP or PHP 4.1/5.0.
I think it's the 'right' thing to do, even though that too requires some thinking. If we move to always use the virtual cwd system in TSRM (any reason not to?) then there'll be pretty much no performance implications either. Zeev At 20:08 9/7/2001, Andi Gutmans wrote: At 12:07 PM 7/9/2001 -0700, Brian Tanner wrote: Just want to pipe up and say I'm worried about a potential performance hit here. I'm building an enterprise web app that includes over 30 files on every request. Will changing the directory for the include file, and changing it back after create a significant performance hit? (I would think so). I think that it will effect performance and therefore I wouldn't want to go in the direction of chdir(). Andi Just to point out -- things might get a little more confusing here... because if people get to pretend that the file they are including is being executed in the directory where it is stored, they may have problems adjusting to the idea of making links and images (in HTML) relative to the script that called their file, and they might have to end up re-implementing existing workarounds anyway. Just a thought. -Brian Tanner -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: July 9, 2001 5:48 AM To: Andi Gutmans Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. Yeah, this has been requested several times. I think that changing the cwd to the directory of an included file makes good sense. It is, indeed, downwards incompatible and may break existing applications. We have 4 options: 1. Do nothing 2. Make include() and friends change directory to the directory of the file they include. This makes the most sense, but may break existing apps. 3. #2, only make it optional 4. Add the directory of the included file to the include_path when the included file is being executed. It can get a bit nasty with nested includes, even though I think it should work. It's also a bit tricky to implement, as the engine doesn't know about include_path (at least right now). I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. Zeev At 18:14 8/7/2001, Andi Gutmans wrote: Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? 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] -- 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 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] -- 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] PSPELL with PHP
pspell-.12.2 ./configure --prefix=/usr/local/encap/aspell-33.6.3 --enable-ltdl-install aspell-.33.6.3 ./configure --prefix=/usr/local/encap/aspell-33.6.3 then I built php-4.0.6 ./configure --prefix=/usr/local/encap/php-4.0.6 --with-mysql=/usr/local/mysql --without-ttf --with-apache=../apache_1.3.19 --with-pspell=/usr/local/encap/asp ell-33.6.3 then I built apache Codeboy in message Re: [PHP-DEV] PSPELL with PHP (Thu, 07/05 16:57): What versions of Aspell, Pspell PHP were you using? Also what are you configure lines for all three, and lastly what was your compile order? Thanks, -Jonathan - Original Message - From: Lindsey Simon [EMAIL PROTECTED] To: Vlad Krupin [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, July 05, 2001 4:05 PM Subject: Re: [PHP-DEV] PSPELL with PHP Well, the mystery is solved. I was --with-php=/usr/local which is where my package manager symlinks my installs to. Instead, once I compiled php with the absolute prefix of aspell, with pspell installed in the same prefix, things seem to be working fine. So now I'm working on some scripts and functions for a spellchecker. The API is perfect for it, and I wonder why I don't see any finished versions out there.. Are you working on one Vlad? I was really shocked by the lack of quality free spellchecking applications for forms. In fact, every one I found was expensive and seems unnecessary complicated to implement. Thanks for your help Vlad! -lindsey Vlad Krupin in message Re: [PHP-DEV] PSPELL with PHP (Tue, 07/03 15:18): Please, tell me what 1. your configure line is for php 2. configure lines for aspell and pspell 3. location of your dictionaries Another thing. You said: I've created a file en-american.pwli in the pkgdata directory which points absolutely to a wordlist american-words.95. What's pkgdata? I have not heard of such a thing. And neither do I have en-american.pwli on my system. On my system .pwli files are located in /usr/local/share/pspell (default location) and the one you probably want is called en-american-aspell.pwli with the record in it referencing /usr/local/lib/aspell/american. Note the -aspell part of the filename. Or file en-aspell.pwli that is used for straight (non-americanized) English that references /usr/local/lib/aspell/english. BTW, this is the library you used when running the test ./example-c from pspell. Anyways, rather than figuring out the mysteries of the spellchecker, it is the easiest to do a default install of pspell and aspell, without creating any new dictionaries by hand and all that kind of stuff. Once you have this working with php, you can wonder off and do whatever custom stuff you need.. Vlad Lindsey Simon wrote: Oddly, Pspell and Aspell seem to work properly, but the pspell_new function can't load the en dict. in the pspell/examples dir I can run the ./example.c en fine. I'm recompiling apache with php again right now to see if it may have to do with the --with-pspell path I was giving. -l Justin Plock in message Re: [PHP-DEV] PSPELL with PHP (Tue, 07/03 16:29): yea, I had a similiar problem trying to get this to work as well, here's the email i received from Vlad (author of the pspell php library) which seemed to work for me. (I was attempting to install both pspell and aspell from the freebsd ports tree). See if this gives any insight, hehe: -- -- --- I bet you did not run the 'add-modules' script. The steps to properly build the thing are: First, in pspell directory: ./configure make make install Then, in aspell directory ./configure make make install Finally, go back to pspell directory and do cd modules ./add-modules cd .. make make install That last step is probably what you missed, at least, that gave me similar problems. Also, make sure that the directory where aspell and pspell place their shared files is amond the directories where your ldconfig will look into (I do not know how this is done in BSD) This solves the chicken-and-egg problem when you can't build aspell without having pspell in place, yet pspell needs to know that aspell (or ispell) exists to function properly. It is also described in pspell README. -- -- --- Hope that helps, Justin. - Original Message - From: Lindsey Simon [EMAIL PROTECTED] To: Justin Plock [EMAIL PROTECTED] Sent: Tuesday, July 03, 2001 4:17 PM Subject: Re: [PHP-DEV] PSPELL with PHP yeah, and pspell and aspell seem to be working fine. which is odd.. Justin Plock in message RE: [PHP-DEV] PSPELL with PHP (Tue, 07/03
Re: [PHP-DEV] [UPDATE] NGScan
Abstracting PHP to work with multiple scanners, or putting a scanner outside the scripting engine, both make no sense. I don't want to see something which is purely wrong from a technical standpoint, done because of some licensing issue. I don't see why abstracting PHP to work with multiple scanners, or better yet, multiple engines is a bad idea. If it can be done in a clean and consistent manner, why not? -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] [patch] safe mode gid check
Here is the patch against current CVS. Ok, I checked through your patch, tested it and committed it. Good work on the patch. It was quite thorough. If you anticipate doing further PHP work, please let us know and we can set you up with a CVS account. -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 #11986: the problem of php and sybase connection has not been fixed
From: [EMAIL PROTECTED] Operating system: windows 2000 PHP version: 4.0.6 PHP Bug Type: Sybase-ct (ctlib) related Bug description: the problem of php and sybase connection has not been fixed Dear all, I have searched for more than 3 months for the solution of the connection problem on using php to connect sybase on the windows 2000 with IIS5 installed. However, in this bug report system, I found a number of closed cases, in which the solution providers said that the connection problem was fixed in php4.06, however after an intensive testing, I give up! If there is any sucessful case, please post the solution here in detail. Thank you very much. tomcwh -- Edit bug report at: http://bugs.php.net/?id=11986edit=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] [UPDATE] NGScan
Sascha, You definitely have the nerve, young boy, and you just crossed the border, so I'll tell my thoughts exactly, too. Your contribution to the PHP project since you joined don't come near the contributions that came from me, Andi, or some other guys. As a matter of fact, some of your negative contributions, i.e., having a horrible attitude and a limitless ego, caused PHP's development a great deal of damage. This isn't theory I'm talking about here. I'm talking about real-world cases of developers who stopped contributing or were afraid to contribute because of your sucky, condescending attitude. I'd be happy to hear what other people think about 'you vs. me'. Perhaps I'll be surprised, but my guess is that most people could live seeing you disappear from the PHP Group and PHP development in general, a few lightyears before they would like to see me disappear from there. It doesn't mean that neither of us has to step away from this project, but perhaps you should finally take some time to figure out the meaning of the word humility, like our Norwegian friend once suggested. Frankly, I think it may be too late for you, though, you don't appear to learn. And to the point - I don't quite care about what you feel about the last 1.5 years - I still have no intention of letting you do wrong things with the PHP project. Zeev At 20:35 9/7/2001, Sascha Schumann wrote: Zeev, I've given you more than half a year already to add the necessary logic to support accepting strings as input and exactly nothing happened. While I'm convinced that you are fully capable of implementing all needed items, I don't anticipate any results anymore. I'm tired of waiting for you to get up to speed. And I certainly don't want to burn all the dynamic of the PHP project by sitting around and hoping that you may change your license at some undetermined point in the future. Thanks, but no. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- 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] [UPDATE] NGScan
At 20:29 9/7/2001, Rasmus Lerdorf wrote: Abstracting PHP to work with multiple scanners, or putting a scanner outside the scripting engine, both make no sense. I don't want to see something which is purely wrong from a technical standpoint, done because of some licensing issue. I don't see why abstracting PHP to work with multiple scanners, or better yet, multiple engines is a bad idea. Let's not divert the discussion to yet-another-completely-hypothetical-and-useless discussion, please, shall we? We're dealing with a very real-world situation here, in which a piece of software that does *exactly* the same thing is now available. Why not have abstraction for it? I don't know, perhaps because it just makes no sense? Think about it for a while, perhaps you'd realize that; I don't think I can explain this in any better way. Perhaps somebody else on this list can help me? 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] [UPDATE] NGScan
On Mon, Jul 09, 2001 at 08:52:11PM +0300, Zeev Suraski wrote: I'd be happy to hear what other people think about 'you vs. me'. I personally don't really care what you two think about each other. What I do care about is the overall quality of this project, as I'm sure a lot of other people do. To that end, flames like this are a complete waste of time and bandwidth. Please don't take this any farther than it has already gone. You're both incredible intelligent and talented individuals, and this is a professional forum and group. Please keep the discussion technical and civil, and let the merits of the code speak for itself. -- 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] [UPDATE] NGScan
What I do care about is the overall quality of this project, as I'm sure a lot of other people do. To that end, flames like this are a complete waste of time and bandwidth. Please don't take this any farther than it has already gone. You're both incredible intelligent and talented individuals, and this is a professional forum and group. Please keep the discussion technical and civil, and let the merits of the code speak for itself. I couldn't agree more. - 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]
Re: [PHP-DEV] [UPDATE] NGScan
There's a good reason for me asking for this. It hasn't been the first time Mr. Schumann behaved the way he did, and frankly, I'm completely tired of this. Either I'm dumb and missing something, or people should tell him about his behavior. Silencing this down will not work in this case. When personal matters start affecting professional decisions, the way Sascha demonstrated today, the personal matters have to be first resolved. I'm afraid this is the case here. Zeev At 21:02 9/7/2001, Jon Parise wrote: On Mon, Jul 09, 2001 at 08:52:11PM +0300, Zeev Suraski wrote: I'd be happy to hear what other people think about 'you vs. me'. I personally don't really care what you two think about each other. What I do care about is the overall quality of this project, as I'm sure a lot of other people do. To that end, flames like this are a complete waste of time and bandwidth. Please don't take this any farther than it has already gone. You're both incredible intelligent and talented individuals, and this is a professional forum and group. Please keep the discussion technical and civil, and let the merits of the code speak for itself. -- Jon Parise ([EMAIL PROTECTED]) . Rochester Inst. of Technology http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] [UPDATE] NGScan
At 21:02 9/7/2001, Sascha Schumann wrote: What I do care about is the overall quality of this project, as I'm sure a lot of other people do. To that end, flames like this are a complete waste of time and bandwidth. Please don't take this any farther than it has already gone. You're both incredible intelligent and talented individuals, and this is a professional forum and group. Please keep the discussion technical and civil, and let the merits of the code speak for itself. I couldn't agree more. No, it's not going to end like this this time - you should have thought about this before you bashed me one time too many. I don't think we can go on working in the same project with you thinking about me the things you do, and me thinking about you the things I do. We got a clear example today of how it doesn't work. 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 #11977 Updated: no PHP.ini failure apache loading libphp4.so
ID: 11977 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Old Bug Type: *Compile Issues Bug Type: IMAP related Operating System: Redhat 7.1 (Seawolf) PHP Version: 4.0.6 New Comment: the php.ini file is NOT created by configure. It's a static file called php.ini-dist which you should modify and copy to right place. Also, the mxdriver error is not PHP problem but something that is wrong with the RH 7.1 rpms. Submit a bug report to them instead. --Jani Previous Comments: [2001-07-09 10:08:50] [EMAIL PROTECTED] I have installed PHP, but it seems that the install doesn't create a php.ini Can't find it anywhere. I have compiled php this way: ./configure \ --with-apxs=/usr/sbin/apxs \ --with-config-file-path=/etc/php \ --with-gd \ --with-xml \ --with-mysql \ --with-zlib \ --enable-track-vars \ --enable-inline-optimization \ --with-gd=shared \ --with-mysql=/usr/local \ --enable-force-cgi-redirect \ --enable-trans-sid \ --enable-ftp \ --with-magic-quotes \ --with-imap \ --with-ldap make make install I'm also getting an error if I try to start apache: Cannot load /usr/lib/apache/libphp4.so into server: /usr/lib/apache/libphp4.so: undefined symbol: mxdriver Is this a bug? With kind regards, Franck Nijhof ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11977edit=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] [UPDATE] NGScan
No, it's not going to end like this this time - you should have thought about this before you bashed me one time too many. I don't think we can go on working in the same project with you thinking about me the things you do, and me thinking about you the things I do. We got a clear example today of how it doesn't work. I'm actually not sure what in my email could be used to construct a personal attack. Even after rereading it three times, it does not jump into my eye. All I was trying to do is to express my frustration with the current situation. - 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 #11978 Updated: ltconfig in infinite loop looking for echo
ID: 11978 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: *Compile Issues Operating System: HP-UX 10.20 PHP Version: 4.0.6 New Comment: The latest CVS means PHP 4.0.7-dev version. Get the snapshot from http://snaps.php.net/ and if it doesn't work, reopen the #10958 and not another report about same issue. Previous Comments: [2001-07-09 10:25:22] [EMAIL PROTECTED] This is 10958 all over again. Solved the problem by setting echo to 'print -r' at the top of the file. If you did remove ltconfig from the CVS version, you must have put it back. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11978edit=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] Possible feature for current version of PHP or PHP 4.1/5.0.
I would *love* to see that! Vlad Andi Gutmans wrote: Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? 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] Faster zend_hash
Guys, I've commited a patch for zend_hash.* in the Zend CVS branch PRE_NEW_HASH_FUNC_PATCH (yeah the branch name shouldn't be with the PRE ) which increases the speed of our hash tables significantly. Can you please try it out and see that it works for you and give me feedback if you notice a difference? testarray seems to be about 20% faster now but it's not a typical script has it has many hash lookups. Make sure you build PHP from scratch (do a make clean) because the dependencies don't work very well and with an unclean build you'll probably get a crash. If it works for everyone I'll merge it. 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 #11979 Updated: could not open ttf file
ID: 11979 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Bogus Status: Closed Bug Type: GD related Operating System: WINDOWS 98 PHP Version: 4.0.6 Previous Comments: [2001-07-09 10:30:57] [EMAIL PROTECTED] ? Header (Content-type: image/png); $im = @imagecreate (700, 30)or die (no image crate !); $black = ImageColorAllocate ($im, 50, 50, 50); $white = ImageColorAllocate ($im, 255, 255, 255); ImageTTFText ($im, 20, 0, 10, 20, $white, arial.ttf,QUESTA E' UNA PAGINA DINAMICA DI PROVA !!!) or die (something wrong !!!); ImagePng($im); ? font is in the path ! win 98 apache mysql ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11979edit=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] [UPDATE] NGScan
I'm talking about real-world cases of developers who stopped contributing or were afraid to contribute because of your sucky, condescending attitude. Uh? I don't recall a single instance of Sascha scaring someone off. I frankly didn't see a personal attack from Sascha on you here. He doesn't want to contribute his code under the Zend License. I see nothing personal about this decision of his. So what options does he have? Should he then just not try to work on aspects of PHP he thinks are important to work on and sit around and wait for you to do it? This doesn't make much sense to me. He should be allowed to play in whatever sandbox he wants and if we can accomodate him without making a mess of things, we should try. So please stop with the personal attacks and concentrate on the real technical issues. -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] NGScan - technical explanation
I consider it obvious why it makes no sense to abstract the scanner input of the engine, and I guess this is not very good - since some of you may not understand what it is about. The reason it makes no sense is very simple. The scanner Sascha wrote doesn't behave in a different way than the current scanner. Nor does it have any drawbacks when compared to the flex scanner. It's a replacement, that performs better and is more compatible than the C++ based flex scanner. Now, let's imagine someone sent us a new implementation of the DOM-XML module, which has an identical API to the last bit (perhaps with some additions), performs faster, and is more compatible. Would we add DOM-XML-NG, and let people choose? Of course not, because it's a plain dumb thing to do. The old DOM-XML extension will be removed and the new one would take its place. The scanner case is similar, except it's a much more fundamental component, which makes even *less* sense to abstract. Abstracting it gives *nothing* from a technical point of view. The single reason Sascha did that, was because he is not happy with the Zend Engine license, and doesn't want to submit it the way it is, to make a point. I've been discussing the Zend Engine license with the 'leaders' of the German PHP community on Thursday, and with members of the community and the PHP Group on Friday. As mentioned there, the Zend Engine license is being reviewed, and may change in the next few months. Especially in the light of this, I see Sascha's changes as making even less sense than what they would have made before, and that wasn't too much to begin with. Abstracting the scanner buys you *nothing* from a technical point of view. 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] NGScan - technical explanation
I've been discussing the Zend Engine license with the 'leaders' of the German PHP community on Thursday, and with members of the community and the PHP Group on Friday. As mentioned there, the Zend Engine license is being reviewed, and may change in the next few months. Well, great. We may switch over to the best technical solution in the next few months then. In the meantime, I don't see any problem with providing a solution to people who actually cannot use PHP because the Flex-based scanners don't work for them. - 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 #11826 Updated: Custom sessions handler using Metabase calls crashes Apache
ID: 11826
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Reproducible crash
Operating System: WinMe, Linux
PHP Version: 4.0.4
New Comment:
Please try the latest CVS from http://snaps.php.net/
or for Windows: http://www.zend.com/snapshots/
--Jani
Previous Comments:
[2001-07-09 11:24:37] [EMAIL PROTECTED]
Your test handler doesn't crash PHP for me with the latest CVS version on Linux.
[2001-07-08 18:32:29] [EMAIL PROTECTED]
I have isolated the bug but did not find the cause. It makes strtok()
crash when attempting to free memory that has been trashed.
It only happens when strtok is called from session on read or on write
handles. I could not find what is wrong in strtok but I suspect there is
inconsistent use of PHP internal global variables (strtok_string) inside
session handle functions. So it seems to be a serious PHP bug that may
also crash scripts that use strtok or other functions from inside session
handle functions that use PHP internal global variables
Metabase is no longer affected by this PHP bug because I have banned all
the uses of strtok function. A new version of Metabase was uploaded to
http://phpclasses.UpperDesign.com/browse.html/package/20 . If you use
Metabase for session handling your are strongly encouraged to download this
version.
For reproducing the PHP strtok bug without Metabase, try the script below.
?php
function on_session_start ($save_path, $session_name)
{
return true;
}
function on_session_end()
{
return true;
}
function on_session_read ($key)
{
return true;
}
function on_session_write ($key, $val)
{
$query=SELECT * FROM sessions;
$select=(strtolower(strtok($query, ))==select);
return true;
}
function on_session_destroy ($key)
{
return true;
}
function on_session_gc ($max_lifetime)
{
return true;
}
// Set the save handlers
session_set_save_handler(on_session_start, on_session_end,
on_session_read,
on_session_write,
on_session_destroy,
on_session_gc);
session_start();
// Register the $counter variable as part of the sesssion
session_register('counter');
$counter = 1;
echo 'Session test started';
?
[2001-07-07 19:59:23] [EMAIL PROTECTED]
Most likely, none of the developers are actually USING
Metabase, so this bug is simply getting glossed over.
Perhaps a reproducible test case that does not require
usage or knowledge of Metabase would help...
IE, while we really appreciate all the work you have
gone through to document this bug, and make these scripts
available, until we can see the bug OUTSIDE of the Metabase
package, it probably won't get a lot of attention.
[2001-07-07 12:46:49]
It's interesting that in the last week this bug report has not gotten a single reply.
It is an easily reproducable bug that Manuel Lemos (author of the Metabase database
abstraction layer) believes is a problem with PHP. He has assured me that the problem
is not with Metabase so, accordingly:
There must be a bug with custom session handlers called
using
session_set_save_handler
(on_session_start, on_session_end,
on_session_read, on_session_write,
on_session_destroy, on_session_gc);
that is making it crash when Metabase calls are used in the start/end/read/write etc.
functions.
As Metabase is one of the best solutions out there for database abstraction with PHP
(are there any others that allow database schema in XML and the range of type
conversion options, etc? Or are as well documented?) I believe that this bug at least
deserves a reply from the developer community. (Even if it is along the lines of: 'We
don't care, fix it yourself' just so I know!)
I have included a link to all code necessary to reproduce the crash in my original bug
report and I've streamlined the code so that only logic necessary for the bug to be
seen is present.
[2001-07-01 16:39:14] [EMAIL PROTECTED]
I have included in the downloadable file a full installation of Metabase and also a
session handler that uses plain old MySQL calls to save the session information (this
does *not* crash the server and is there to help with your testing -- it is called
mysql_sessions.php and can be tested just by including it in the nabsession_test.php
and nabsession_test2.php scripts in the place of metabase_sessions.php.)
The remainder of the comments
[PHP-DEV] Bug #11981 Updated: no ttf file open
ID: 11981 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: GD related Operating System: win98 PHP Version: 4.0.6 New Comment: reopened the original one. Bogused this. Previous Comments: [2001-07-09 11:31:03] [EMAIL PROTECTED] ? Header (Content-type: image/png); $im = @imagecreate (700, 30)or die (no image crate !); $black = ImageColorAllocate ($im, 50, 50, 50); $white = ImageColorAllocate ($im, 255, 255, 255); ImageTTFText ($im, 20, 0, 10, 20, $white, arial.ttf,QUESTA E' UNA PAGINA DINAMICA DI PROVA !!!) or die (something wrong !!!); ImagePng($im); ? font is in the path ! win 98 apache mysql -- I try the full path ! but it doesn't work ! I try to reopen the the report 11969 but it doesn't work error with password (but the password is correct) . ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11981edit=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 #11979 Updated: could not open ttf file
ID: 11979 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Closed Status: Open Bug Type: GD related Operating System: WINDOWS 98 PHP Version: 4.0.6 New Comment: reopened. The full path didn't work. Previous Comments: [2001-07-09 10:34:09] [EMAIL PROTECTED] Try the full path to the font. and if that does not work, reopen this report. Derick [2001-07-09 10:30:57] [EMAIL PROTECTED] ? Header (Content-type: image/png); $im = @imagecreate (700, 30)or die (no image crate !); $black = ImageColorAllocate ($im, 50, 50, 50); $white = ImageColorAllocate ($im, 255, 255, 255); ImageTTFText ($im, 20, 0, 10, 20, $white, arial.ttf,QUESTA E' UNA PAGINA DINAMICA DI PROVA !!!) or die (something wrong !!!); ImagePng($im); ? font is in the path ! win 98 apache mysql ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11979edit=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] NGScan - technical explanation
On Mon, Jul 09, 2001 at 09:27:17PM +0300, Zeev Suraski wrote: I consider it obvious why it makes no sense to abstract the scanner input of the engine, and I guess this is not very good - since some of you may not understand what it is about. The reason it makes no sense is very simple. The scanner Sascha wrote doesn't behave in a different way than the current scanner. Nor does it have any drawbacks when compared to the flex scanner. It's a replacement, that performs better and is more compatible than the C++ based flex scanner. Now, let's imagine someone sent us a new implementation of the DOM-XML module, which has an identical API to the last bit (perhaps with some additions), performs faster, and is more compatible. Would we add DOM-XML-NG, and let people choose? Of course not, because it's a plain dumb thing to do. The old DOM-XML extension will be removed and the new one would take its place. The scanner case is similar, except it's a much more fundamental component, which makes even *less* sense to abstract. Abstracting it gives *nothing* from a technical point of view. The single reason Sascha did that, was because he is not happy with the Zend Engine license, and doesn't want to submit it the way it is, to make a point. I've been discussing the Zend Engine license with the 'leaders' of the German PHP community on Thursday, and with members of the community and the PHP Group on Friday. As mentioned there, the Zend Engine license is being reviewed, and may change in the next few months. Especially in the light of this, I see Sascha's changes as making even less sense than what they would have made before, and that wasn't too much to begin with. Abstracting the scanner buys you *nothing* from a technical point of view. technical i agree (kinda) - so what should he do: - not work on it? - not even think about digging into the ZendEngine and look for possible improvements (and leave all that up to you and andi)? - put his changes under your QPL? as long as the (perception of the) Zend License stopps him from submitting it to the ZendEngine he has no other choice than to put it somewhere where he feels comfortable with it. besides that i can actually think of one or two usages for a scanner in PHP which is not QPL. for exacle that reason the your DOMXML sample is void - if we had a better DOMXML under the same license we would use the better one. licenses do matter (and yes, i have heard what you said about the future - and so has sascha -and- he has expressed his opinion about this issue) 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] [UPDATE] NGScan
At 11:24 AM 7/9/2001 -0700, Rasmus Lerdorf wrote: I'm talking about real-world cases of developers who stopped contributing or were afraid to contribute because of your sucky, condescending attitude. Uh? I don't recall a single instance of Sascha scaring someone off. I don't want to enter myself into the argument but a lot of people have mentioned to me via Email on IRC that Sascha has a very condescending attitude with them too. Rasmus, you know he can be very harsh on people. I'm sure it's not new to you. And if it is, I'm sure there are some examples in the php-dev archives. I frankly didn't see a personal attack from Sascha on you here. He doesn't want to contribute his code under the Zend License. I see nothing personal about this decision of his. So what options does he have? Should he then just not try to work on aspects of PHP he thinks are important to work on and sit around and wait for you to do it? This doesn't make much sense to me. He should be allowed to play in whatever sandbox he wants and if we can accomodate him without making a mess of things, we should try. So please stop with the personal attacks and concentrate on the real technical issues. Well I'm not sure if you realized but abstracting a scanner doesn't make sense, period. No other language interpreter or compiler does this because there is only one option, the best for the job. A scanner isn't like a programming language where it depends on the persons taste if he prefers one or the other. It either does its job better or it doesn't. If it needs abstracting then the worse implementation should be thrown away. Sascha could have discussed this with us in the open instead of trying to go through the back door. A healthy discussion usually leads to results. And if he really has a hard time with the current Zend License we could have done the re2c for him if we all had decided this is what PHP needs and that it really makes such a huge performance difference (I'm not even sure how much the patch helps in a real world PHP script). About the feature he wanted as to I/O filtering for Apache 2. I thought about it and as Apache 2 was put back to alpha (I think that is its current status) I must admit it wasn't on the top of my priority list. Had Sascha reminded me or opened a discussion I'm sure we would have found a solution which everyone is happy with. OK I'm going home... This is too much for me :) 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] NGScan - technical explanation
So have a patch on your directory as you published it, for those few for which the flex scanner doesn't work (and they *are* very few). Don't break PHP. Zeev At 21:31 9/7/2001, Sascha Schumann wrote: I've been discussing the Zend Engine license with the 'leaders' of the German PHP community on Thursday, and with members of the community and the PHP Group on Friday. As mentioned there, the Zend Engine license is being reviewed, and may change in the next few months. Well, great. We may switch over to the best technical solution in the next few months then. In the meantime, I don't see any problem with providing a solution to people who actually cannot use PHP because the Flex-based scanners don't work for them. - 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] -- 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] NGScan - technical explanation
At 21:38 9/7/2001, Thies C. Arntzen wrote: as long as the (perception of the) Zend License stopps him from submitting it to the ZendEngine he has no other choice than to put it somewhere where he feels comfortable with it. Yes, but if he puts it in PHP, it also has to be comfortable with other people. I'm pretty uncomfortable with this structural mess. besides that i can actually think of one or two usages for a scanner in PHP which is not QPL. for exacle that reason the your DOMXML sample is void - if we had a better DOMXML under the same license we would use the better one. Can you share your thoughts as to how exactly GPL scanner built into PHP in an odd way would improve your world for the better? Remember, the scanner is already there, you can use it if you think it's useful. We're arguing on whether it should be plugged into PHP in a backwards way or not. 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] [UPDATE] NGScan
On Mon, Jul 09, 2001 at 09:37:35PM +0300, Zeev Suraski wrote: So please stop with the personal attacks and concentrate on the real technical issues. I'd appreciate it if you stayed out of this one. I'm fed up with Sascha's i _really_ dislike this statement! attitude towards me and other developers, and decided it was time to point that issue out. i'm not on IRC - but i do not see how working with sascha has not always gotten us the better result. i do not remember sascha beeing rude to people - but i do admit that he is *direct*. that might just be a matter of perception. you - on the other hand - leave _no_ room for interpretation in this very situation. 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]
