[PHP-DEV] Bug #13380: PHP 4.0.6 could not be downloaded from your site.
From: [EMAIL PROTECTED] Operating system: PHP version: 4.0.6 PHP Bug Type: *General Issues Bug description: PHP 4.0.6 could not be downloaded from your site. PHP 4.0.6 could not be downloaded from your site. -- Edit bug report at: http://bugs.php.net/?id=13380edit=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 #13382: PHP - MySQL select statement
From: [EMAIL PROTECTED]
Operating system: windows2000
PHP version: 4.0.6
PHP Bug Type: Output Control
Bug description: PHP - MySQL select statement
Dear supporter,
My name is Thuyen Tran (KPMG CT Information) and I am working now with PHP
and MySQL.
I just have a problem when I try to read and write the data from the
database to the OUTFILE
using the following statement on the Unix web server:
$q_users = (SELECT * INTO OUTFILE '$base_dir$csv_dir_name/$csv_file_users'
FROM user_info);
but unfortunetly this doesn't work. The following error occurs:
Database error: Invalid SQL: SELECT * INTO OUTFILE
'/space/web/kct/projects/testshop/export/outfile_users.csv' FROM
user_info
MySQL Error: 1 (Can't create/write to file
'/space/web/kct/projects/testshop/export/outfile_users.csv' (Errcode: 2))
It seem to me that the path '$base_dir$csv_dir_name'
which is
/space/web/kct/projects/testshop/export as below can
be seen, is not recognised (may be system drive??)
For the same code it works well for other web server.
What I want to do is to put the *.csv file in a certain
specified directory.
I tried to open new file with success in the same directory as follows in
order to see what happens:
$fp = fopen(./hallo.txt, w+); // only try to test
and also
$q_users = (SELECT * INTO OUTFILE './$csv_file_users' FROM user_info
);
all of these work well.
So please could you tell me what was wrong?
Your quick response will graetly be appreciated. Many thanks!
Regards,
Thuyen
Here below is my code:
?php
//Create and make *.csv files to export
//$base_dir = /space/web/kct/projects/testshop/;
$csv_dir_name = export;
$csv_file_orders= outfile_orders.csv;
$csv_file_users = outfile_users.csv;
// open the directory with the path which is supplied as the sole
parameter
chmod ($base_dir, 0777);
$dir = opendir(.);
$exist_flag = false; // the csv directory doesn't exist, need to create
one.
while ($dir_name=readdir($dir)) {
if ($dir_name == $csv_dir_name){
$exist_flag = true;
break;
}
}
// create a new directory to store the *.csv file
if ($exist_flag == false) {
mkdir(./$csv_dir_name, );
echo (New sub directory '$base_dir$csv_dir_name' is created!);
}
// change permission for the created directory
chmod (./$csv_dir_name, 0777);
// Set the current directory and open it
chdir (./$csv_dir_name);
$dir = opendir(.);
// Here just read all the 'entries' in it (both files and sub-folders)
while ($file=readdir($dir)) {
//echo($fileBR);// only use to show all in the current
directory
// delete the csv file permanently if it exists.
if ($file == $csv_file_users) {
unlink ($csv_file_users);
}
if ($file == $csv_file_orders) {
unlink ($csv_file_orders);
}
}
$fp = fopen(./hallo.txt, w+); // only try to test if it can, it
works.
// Get all information of USERS and store them in *.csv file
$q_users = (SELECT * INTO OUTFILE
'$base_dir$csv_dir_name/$csv_file_users' FROM user_info);
//$q_users = (SELECT * INTO OUTFILE './$csv_file_users' FROM
user_info ); it works.
$db-query($q_users);
$db-next_record();
?
--
Edit bug report at: http://bugs.php.net/?id=13382edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] [] php-dev ?
¾È³çÇϼ¼¿ä. kkmoon¿î¿µÀÚÀÔ´Ï´Ù. º»¸ÞÀÏÀÌ ÇÊ¿ä¾øÀ¸½Ã¸é ¸ÞÀϼö½Å°ÅºÎ¼³Á¤À» ÇϽðųª [EMAIL PROTECTED] ·Î ¼ö½Å°ÅºÎ¸ÞÀϹٶø´Ï´Ù. ¾ÕÀ¸·Î ¹ß¼Û ÇÏÁö ¾Ê°Ú½À´Ï´Ù ÀúÀÇ È¨ÆäÀÌÁökkmoonÀÌ »õ·Ó°Ô °³ÆíµÇ¾ú½À´Ï´Ù. ³î·¯ ¸¹ÀÌ¿À¼¼¿ä Àý´ë ¹«·á»çÀÌÆ®ÀÔ´Ï´Ù. kkmoonÀÇ Æ¯Â¡ 1. ¹«·áÁ¾ÇÕ ¼ºÀΰ¡À̵å(¹«·á »çÀÌÆ® ¼³¸í ¹× Á¤º¸Á¦°ø) 2. ÀÚü ¹Ì¼Ò³à °¶·¯¸® ¹× À¯¸Ó, Ç÷¡½Ã, µ¿¿µ»ó Á¦°ø 3. »çÀÌÆ® µ¿¸Í ½Åû °¡´É(Á¦ÇÑ ¾øÀ½) ÀÌ»ó °£·«È÷ »çÀÌÆ®¿¡ °üÇؼ ¼³¸í µå·È½À´Ï´Ù. ÀÚ¼¼ÇÑ°ÍÀº ȨÆäÀÌÁö¿¡ ³î·¯ ¿À¼Å¼ È®ÀÎ ¹Ù¶ø´Ï´Ù. ÁÖ¼Ò´Â http://kkmoon.wo.to ÀÔ´Ï´Ù. ÀúÀÇ »çÀÌÆ®´Â ¼ºÀÎÀü¿ë »çÀÌÆ®·Î¼ ¼ºÀι°¿¡ ´ëÇÑ °ÅºÎ°¨ÀÌ ÀÖÀ¸½ÅºÐÀ̳ª ¸¸19¼¼¹Ì¸¸ÀÇ Ã»¼Ò³âÀÇ Á¢±ÙÀ» ±ÝÁöÇÕ´Ï´Ù.
[PHP-DEV] Bug #13383: The specified CGI application misbehaved by not returning a complete set of HTT
From: [EMAIL PROTECTED]
Operating system: Windows 2000 with IIS 5.0
PHP version: 4.0.6
PHP Bug Type: Unknown/Other Function
Bug description: The specified CGI application misbehaved by not returning a complete
set of HTT
?php
//header (Content-type: image/gif) ;
?
html
body
?php
$dbh = ibase_connect(localhost:c:\program
files\borland\interbase\bin\Binary_Data.gdb, SYSDBA, masterkey);
$sth = ibase_query($dbh, select description, bin_data from binary_data
where id = 5) ;
$row = ibase_fetch_row($sth) ;
print (Description : $row[0]) ;
$blobid = ibase_blob_open($row[1]) ;
$tempibase = tempnam(temp, TMP) ;
$tempibase .= .gif ;
//$fp = fopen($tempibase, w) ;
while($data = ibase_blob_get($blobid, 1024))
{
// fputs($fp, $data) ;
$finaldata .= $data ;
}
//fclose($fp) ;
ibase_blob_close($blobid) ;
ibase_free_query($sth) ;
//print (Got the blob field) ;
//print ($finaldata) ;
//echo brcenterimg src=$tempibase /center ;
/*$blobid = ibase_blob_create() ;
ibase_blob_add($blobid, $data) ;
$blob_id_save = ibase_blob_close($blobid) ;*/
ibase_close($dbh) ;
?
/body
html
--
Edit bug report at: http://bugs.php.net/?id=13383edit=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 #13384: Enctype multipart/form-date
From: [EMAIL PROTECTED] Operating system: Linux hurricane 2.2.19-5tr PHP version: 4.0.6 PHP Bug Type: Unknown/Other Function Bug description: Enctype multipart/form-date I'm not sure it's a bug. But I have checked all of my configuration system and I think the problem is not in my system. The problem is : When i used tag form and enctype=multipart/form-data (we must use this for input type=file or for upload file), There's no variables delivered to 'action' file. The problem disappeared if I use PHP 4.0.5 with the exactly same script and everthing is ok for the form. That's all, pls reply if you're have found the solution for me. Thanks a lot -- Edit bug report at: http://bugs.php.net/?id=13384edit=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] Seeding rand() at process start?
Does it make sense for PHP to seed rand() with srand() when it starts up, during MINIT in basic_functions.c? It just seems that there is no good way to ensure you have a good seed for random, and if rand() were ready to use, out of the box a lot of people would not be pulling their hair out trying to fabricate a clean seed. Besides one should seed only once, more often than that circumvents the randomness of a random number generator. On UNIX we could seed rand() with /dev/urandom, else we could use time of day. (Any other suggestions would be welcome.) -- PHP Development Mailing List http://www.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 #13384 Updated: Enctype multipart/form-date
ID: 13384 Updated by: hholzgra Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Unknown/Other Function Operating System: Linux hurricane 2.2.19-5tr PHP Version: 4.0.6 New Comment: Is Linux hurricane a RedHat based distribution and you are using the distributions PHP RPMs? Previous Comments: [2001-09-21 20:40:14] [EMAIL PROTECTED] I'm not sure it's a bug. But I have checked all of my configuration system and I think the problem is not in my system. The problem is : When i used tag form and enctype=multipart/form-data (we must use this for input type=file or for upload file), There's no variables delivered to 'action' file. The problem disappeared if I use PHP 4.0.5 with the exactly same script and everthing is ok for the form. That's all, pls reply if you're have found the solution for me. Thanks a lot Edit this bug report at http://bugs.php.net/?id=13384edit=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] enable truetype string function in gd
Hi! I try to get the above mentioned to work with the 4.0.6 release on Linux! But even though I provide the configure script with the --enable-gd-native-ttf switch, it reports that the feature is a no go ./configure --enable-modules=so --without-mysql --with-pgsql=/usr/local \ --with-apxs=/usr/sbin/apxs --with-raima --with-gd=/usr/local \ --with-freetype-dir=/usr/local/include/freetype2 --enable-gd-native-ttf \ --with-jpeg-dir=/usr --with-xpm-dir=/usr/X11R6 --with-zlib-dir=/usr --with-png-dir=/usr : checking whether to include GD support... yes checking whether to enable truetype string function in gd... no - This really bugs me!! Never the less... We enable it anyway checking for the location of libjpeg... yes checking for jpeg_read_header in -ljpeg... (cached) yes checking for the location of libpng... yes checking for png_info_init in -lpng... (cached) yes checking for the location of libXpm... yes checking for XpmFreeXpmImage in -lXpm... (cached) yes checking for freetype(2)... yes checking whether to include include FreeType 1.x support... no checking whether to include T1lib support... no checking for gdImageString16 in -lgd... (cached) yes checking for gdImagePaletteCopy in -lgd... (cached) yes checking for gdImageCreateFromPng in -lgd... (cached) yes checking for gdImageCreateFromGif in -lgd... (cached) no checking for gdImageWBMP in -lgd... (cached) yes checking for gdImageCreateFromJpeg in -lgd... (cached) yes checking for gdImageCreateFromXpm in -lgd... (cached) yes checking for gdImageCreateTrueColor in -lgd... (cached) no checking for gdImageSetTile in -lgd... (cached) yes checking for gdImageSetBrush in -lgd... (cached) yes checking for gdImageStringFTEx in -lgd... (cached) no checking for gdImageColorClosestHWB in -lgd... (cached) yes checking for gdImageColorResolve in -lgd... (cached) yes checking for gdImageGifCtx in -lgd... (cached) no : The Never the less... line comes from me trying to force the definition of USE_GD_IMGSTRTTF in ext/gd/config.m4... And still it doesn't work CAAARP!!! (I simply altered = yes to != yes) Any thoughts?? /T. -- PHP Development Mailing List http://www.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 #13384 Updated: Enctype multipart/form-date
ID: 13384 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Unknown/Other Function Operating System: Linux hurricane 2.2.19-5tr PHP Version: 4.0.6 New Comment: Can you provide a short script which is showing this problem? And you should use enctype=multipart/form-data (with the quotes), because without it's invalid HTML (only [a-zA-Z0-9.-]+ is allowed in HTML-attribute values without quotes, see http://www.htmlhelp.com/reference/html40/structure.html#attributes) Previous Comments: [2001-09-21 21:10:03] [EMAIL PROTECTED] Is Linux hurricane a RedHat based distribution and you are using the distributions PHP RPMs? [2001-09-21 20:40:14] [EMAIL PROTECTED] I'm not sure it's a bug. But I have checked all of my configuration system and I think the problem is not in my system. The problem is : When i used tag form and enctype=multipart/form-data (we must use this for input type=file or for upload file), There's no variables delivered to 'action' file. The problem disappeared if I use PHP 4.0.5 with the exactly same script and everthing is ok for the form. That's all, pls reply if you're have found the solution for me. Thanks a lot Edit this bug report at http://bugs.php.net/?id=13384edit=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 #13385: nl2br hangs on specific strings
From: [EMAIL PROTECTED] Operating system: Linux glibc 2.2 PHP version: 4.0CVS-2001-09-21 PHP Bug Type: Strings related Bug description: nl2br hangs on specific strings bbonev@orange:~/php/php4$ ./php ? echo nl2br(asd\n\ndsa\r\rqwe\r\n\newq\n\r\r) ? X-Powered-By: PHP/4.0.8-dev Content-type: text/html br bFatal error/b: Maximum execution time of 30 seconds exceeded in b-/b on line b1/bbr btw. i have noticed this while trying to rewrite nl2br to be faster and more compatible. -- Edit bug report at: http://bugs.php.net/?id=13385edit=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]
Fwd: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd)
Guys, I think this is the last problem which is holding up RC3 and hopefully 4.0.7. Does anyone here know the code in rfc1867? I don't know it well enough in order to decide if this patch is OK or not. If no one answers I'll apply it and we should as the QA guys to test file uploads extensively in RC3. Andi Date: Tue, 18 Sep 2001 17:22:41 +0200 (CEST) From: Jani Taskinen [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Could someone who knows the current code better check this out and apply this patch? My work for the other issues is not done yet..and it's too big of a change for this release. --Jani -- Forwarded message -- Date: Tue, 18 Sep 2001 03:21:52 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch - Dont Use Previous Sorry Sorry Sorry, about an hour ago i send you my patch for the critical BUG with the ID 11998. Unfourtunately, i sent a totally fucked up patch (file). DO NOT APPLY it. Here is the correct patch, with some additional checks and with the header end check finally working. Sorry for my mistake ;) My only apology is, that it is deep midnight here in germany *g* Yours, Ralf PS: as a side effect of my patch, the 30 files crash bug is fixed, too :) --- Weitergeleitete Nachricht / Forwarded Message --- Date: Tue, 18 Sep 2001 02:05:42 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch Hello, today i browsed through the php bug database on the search for critical bugs. I then saw Bug id #11998 which speaks of some bugs in rfc1867.c. Due to the fact i saw several flaws in the source code some time ago, i patched my version. I now send you my patch and the patch applied to the cvs snapshot of today, that fixes several bugs... first and foremost the fix that went into 4.0.6 was not only broken, but also implemented a possible NULL pointer dereference. The main problem with that fix was, that it applied the search end of headers functionality to the wrong place. The array upload was also crashable by simply using a name like invalid][ as var name. I fixed it by correcting the IF clause that decides if it is an array upload or not. In fact my fix consists of several stability fixes that also make the upload more robust against browsers that are not 100% rfc conform. Hope my patch helps you to improve php even more. I really like the whole idea of php and would be lucky if my contribution helps to make it even better than it already is. Yours, Ralf Bolte -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.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] rfc1867-real-bugfix.tar.gz -- PHP Development Mailing List http://www.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 id #11998 - source code patch - Dont Use Previous (fwd)
please check bug id 13385, i hope that this is my mistake or inappropriate build, but if i am not wrong, it is a serious thing... in short ? echo nl2br(asd\n\ndsa\r\rqwe\r\n\newq\n\r\r) ? hangs with latest cvs. b. - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 21, 2001 6:18 PM Subject: Fwd: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Guys, I think this is the last problem which is holding up RC3 and hopefully 4.0.7. Does anyone here know the code in rfc1867? I don't know it well enough in order to decide if this patch is OK or not. If no one answers I'll apply it and we should as the QA guys to test file uploads extensively in RC3. Andi Date: Tue, 18 Sep 2001 17:22:41 +0200 (CEST) From: Jani Taskinen [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Could someone who knows the current code better check this out and apply this patch? My work for the other issues is not done yet..and it's too big of a change for this release. --Jani -- Forwarded message -- Date: Tue, 18 Sep 2001 03:21:52 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch - Dont Use Previous Sorry Sorry Sorry, about an hour ago i send you my patch for the critical BUG with the ID 11998. Unfourtunately, i sent a totally fucked up patch (file). DO NOT APPLY it. Here is the correct patch, with some additional checks and with the header end check finally working. Sorry for my mistake ;) My only apology is, that it is deep midnight here in germany *g* Yours, Ralf PS: as a side effect of my patch, the 30 files crash bug is fixed, too :) --- Weitergeleitete Nachricht / Forwarded Message --- Date: Tue, 18 Sep 2001 02:05:42 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch Hello, today i browsed through the php bug database on the search for critical bugs. I then saw Bug id #11998 which speaks of some bugs in rfc1867.c. Due to the fact i saw several flaws in the source code some time ago, i patched my version. I now send you my patch and the patch applied to the cvs snapshot of today, that fixes several bugs... first and foremost the fix that went into 4.0.6 was not only broken, but also implemented a possible NULL pointer dereference. The main problem with that fix was, that it applied the search end of headers functionality to the wrong place. The array upload was also crashable by simply using a name like invalid][ as var name. I fixed it by correcting the IF clause that decides if it is an array upload or not. In fact my fix consists of several stability fixes that also make the upload more robust against browsers that are not 100% rfc conform. Hope my patch helps you to improve php even more. I really like the whole idea of php and would be lucky if my contribution helps to make it even better than it already is. Yours, Ralf Bolte -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.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 Development Mailing List http://www.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] Bug id #11998 - source code patch - Dont Use Previous (fwd)
Seems like boyer_str_to_str() is buggy. If I change it to php_str_to_str() it seems to work. I think Sascha added this function but I might be wrong. Andi At 06:46 PM 9/21/2001 +0300, Boian Bonev wrote: please check bug id 13385, i hope that this is my mistake or inappropriate build, but if i am not wrong, it is a serious thing... in short ? echo nl2br(asd\n\ndsa\r\rqwe\r\n\newq\n\r\r) ? hangs with latest cvs. b. - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 21, 2001 6:18 PM Subject: Fwd: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Guys, I think this is the last problem which is holding up RC3 and hopefully 4.0.7. Does anyone here know the code in rfc1867? I don't know it well enough in order to decide if this patch is OK or not. If no one answers I'll apply it and we should as the QA guys to test file uploads extensively in RC3. Andi Date: Tue, 18 Sep 2001 17:22:41 +0200 (CEST) From: Jani Taskinen [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Could someone who knows the current code better check this out and apply this patch? My work for the other issues is not done yet..and it's too big of a change for this release. --Jani -- Forwarded message -- Date: Tue, 18 Sep 2001 03:21:52 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch - Dont Use Previous Sorry Sorry Sorry, about an hour ago i send you my patch for the critical BUG with the ID 11998. Unfourtunately, i sent a totally fucked up patch (file). DO NOT APPLY it. Here is the correct patch, with some additional checks and with the header end check finally working. Sorry for my mistake ;) My only apology is, that it is deep midnight here in germany *g* Yours, Ralf PS: as a side effect of my patch, the 30 files crash bug is fixed, too :) --- Weitergeleitete Nachricht / Forwarded Message --- Date: Tue, 18 Sep 2001 02:05:42 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch Hello, today i browsed through the php bug database on the search for critical bugs. I then saw Bug id #11998 which speaks of some bugs in rfc1867.c. Due to the fact i saw several flaws in the source code some time ago, i patched my version. I now send you my patch and the patch applied to the cvs snapshot of today, that fixes several bugs... first and foremost the fix that went into 4.0.6 was not only broken, but also implemented a possible NULL pointer dereference. The main problem with that fix was, that it applied the search end of headers functionality to the wrong place. The array upload was also crashable by simply using a name like invalid][ as var name. I fixed it by correcting the IF clause that decides if it is an array upload or not. In fact my fix consists of several stability fixes that also make the upload more robust against browsers that are not 100% rfc conform. Hope my patch helps you to improve php even more. I really like the whole idea of php and would be lucky if my contribution helps to make it even better than it already is. Yours, Ralf Bolte -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.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 Development Mailing List http://www.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] Bug id #11998 - source code patch - Dont Use Previous(fwd)
On Fri, 21 Sep 2001, Andi Gutmans wrote: Seems like boyer_str_to_str() is buggy. If I change it to php_str_to_str() it seems to work. I think Sascha added this function but I might be wrong. I did not change nl2br though. I probably would have noticed that, if the commit message would not have been so tense: revision 1.238 - Fix for bug 11904 #- This is possibly not the best solution... feel free to improve - 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] Bug id #11998 - source code patch - Dont Use Previous (fwd)
currently i am rewriting the nl2br stuff. two reasons: 1. current ver does not handle nicely text with mixed dos/unix/mac line endings 2. using generic str_replace for exactly 1 or 2 chars is really slower (IMHO this is used too often to pay the 200-500 bytes code overhead) when it is stable, i'll post a patch b. - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Boian Bonev [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Sascha Schumann [EMAIL PROTECTED] Sent: Friday, September 21, 2001 7:13 PM Subject: Re: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Seems like boyer_str_to_str() is buggy. If I change it to php_str_to_str() it seems to work. I think Sascha added this function but I might be wrong. Andi At 06:46 PM 9/21/2001 +0300, Boian Bonev wrote: please check bug id 13385, i hope that this is my mistake or inappropriate build, but if i am not wrong, it is a serious thing... in short ? echo nl2br(asd\n\ndsa\r\rqwe\r\n\newq\n\r\r) ? hangs with latest cvs. b. - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 21, 2001 6:18 PM Subject: Fwd: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Guys, I think this is the last problem which is holding up RC3 and hopefully 4.0.7. Does anyone here know the code in rfc1867? I don't know it well enough in order to decide if this patch is OK or not. If no one answers I'll apply it and we should as the QA guys to test file uploads extensively in RC3. Andi Date: Tue, 18 Sep 2001 17:22:41 +0200 (CEST) From: Jani Taskinen [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Could someone who knows the current code better check this out and apply this patch? My work for the other issues is not done yet..and it's too big of a change for this release. --Jani -- Forwarded message -- Date: Tue, 18 Sep 2001 03:21:52 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch - Dont Use Previous Sorry Sorry Sorry, about an hour ago i send you my patch for the critical BUG with the ID 11998. Unfourtunately, i sent a totally fucked up patch (file). DO NOT APPLY it. Here is the correct patch, with some additional checks and with the header end check finally working. Sorry for my mistake ;) My only apology is, that it is deep midnight here in germany *g* Yours, Ralf PS: as a side effect of my patch, the 30 files crash bug is fixed, too :) --- Weitergeleitete Nachricht / Forwarded Message --- Date: Tue, 18 Sep 2001 02:05:42 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch Hello, today i browsed through the php bug database on the search for critical bugs. I then saw Bug id #11998 which speaks of some bugs in rfc1867.c. Due to the fact i saw several flaws in the source code some time ago, i patched my version. I now send you my patch and the patch applied to the cvs snapshot of today, that fixes several bugs... first and foremost the fix that went into 4.0.6 was not only broken, but also implemented a possible NULL pointer dereference. The main problem with that fix was, that it applied the search end of headers functionality to the wrong place. The array upload was also crashable by simply using a name like invalid][ as var name. I fixed it by correcting the IF clause that decides if it is an array upload or not. In fact my fix consists of several stability fixes that also make the upload more robust against browsers that are not 100% rfc conform. Hope my patch helps you to improve php even more. I really like the whole idea of php and would be lucky if my contribution helps to make it even better than it already is. Yours, Ralf Bolte -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.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 Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list
Re: [PHP-DEV] Re: Seeding rand() at process start?
That's not the point. If PHP seeds the random number generator at MINIT time, with a pretty good random seed it will save a lot of work for devlopers tying to use rand() to come up with a good random number. As it is now, they need some sort of flag that indicates that they have seeded the random generator in this process, or find some sort of way of repeatedly seeding the generator. Either way, rand() is useless without a proper seed and it is difficult create a good seed in PHP. On Fri, 21 Sep 2001 09:09:07 -0400 (EDT) [EMAIL PROTECTED] wrote: :Does it make sense for PHP to seed rand() with srand() when it starts up, :during MINIT in basic_functions.c? : :It just seems that there is no good way to ensure you have a good seed for :random, and if rand() were ready to use, out of the box a lot of people :would not be pulling their hair out trying to fabricate a clean seed. :Besides one should seed only once, more often than that circumvents the :randomness of a random number generator. : :On UNIX we could seed rand() with /dev/urandom, else we could use time of :day. (Any other suggestions would be welcome.) http://www.fourmilab.ch/hotbits/ You can pick up as many random bytes as you want; usually use a 16-bit INT as a seed. -- Tony Reed [EMAIL PROTECTED] The President was assassinated by a precision guerrilla team of at least seven men ... -- Jim Garrison -- PHP Development Mailing List http://www.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] Re: Seeding rand() at process start?
On Fri, 21 Sep 2001 [EMAIL PROTECTED] wrote: That's not the point. If PHP seeds the random number generator at MINIT time, with a pretty good random seed it will save a lot of work for devlopers tying to use rand() to come up with a good random number. As it is now, they need some sort of flag that indicates that they have seeded the random generator in this process, or find some sort of way of repeatedly seeding the generator. Either way, rand() is useless without a proper seed and it is difficult create a good seed in PHP. srand(); As of the CVS version of PHP, if you leave the seed out, the rand implementation will autogenerate it for you (it really wasn't that hard beforehand, but...) I'm currently debating whether seeding at startup is a good idea, because alot of scripts don't use rand() (alot do I know, but still), and seeding at startup will cause a slow down in PHP... another thought is to have rand() check whether or not its been seeded, and if it has been seeded, use the previous seed, otherwise, seed the generator (I'm currently leaning towards the latter). -Sterling On Fri, 21 Sep 2001 09:09:07 -0400 (EDT) [EMAIL PROTECTED] wrote: :Does it make sense for PHP to seed rand() with srand() when it starts up, :during MINIT in basic_functions.c? : :It just seems that there is no good way to ensure you have a good seed for :random, and if rand() were ready to use, out of the box a lot of people :would not be pulling their hair out trying to fabricate a clean seed. :Besides one should seed only once, more often than that circumvents the :randomness of a random number generator. : :On UNIX we could seed rand() with /dev/urandom, else we could use time of :day. (Any other suggestions would be welcome.) http://www.fourmilab.ch/hotbits/ You can pick up as many random bytes as you want; usually use a 16-bit INT as a seed. -- Tony Reed [EMAIL PROTECTED] The President was assassinated by a precision guerrilla team of at least seven men ... -- Jim Garrison -- PHP Development Mailing List http://www.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] Bug id #11998 - source code patch - Dont Use Previous(fwd)
On Fri, 21 Sep 2001, Andi Gutmans wrote: Seems like boyer_str_to_str() is buggy. If I change it to php_str_to_str() it seems to work. I think Sascha added this function but I might be wrong. When I added some support for MAC line endings, I was told boyer_str_to_Str() was the faster method... so I choose that one. Not knowing that it was still experimental. Maybe place a comment about things being experimental in the source next time would guard against this kind of problems Derick Andi At 06:46 PM 9/21/2001 +0300, Boian Bonev wrote: please check bug id 13385, i hope that this is my mistake or inappropriate build, but if i am not wrong, it is a serious thing... in short ? echo nl2br(asd\n\ndsa\r\rqwe\r\n\newq\n\r\r) ? hangs with latest cvs. b. - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 21, 2001 6:18 PM Subject: Fwd: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Guys, I think this is the last problem which is holding up RC3 and hopefully 4.0.7. Does anyone here know the code in rfc1867? I don't know it well enough in order to decide if this patch is OK or not. If no one answers I'll apply it and we should as the QA guys to test file uploads extensively in RC3. Andi Date: Tue, 18 Sep 2001 17:22:41 +0200 (CEST) From: Jani Taskinen [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Could someone who knows the current code better check this out and apply this patch? My work for the other issues is not done yet..and it's too big of a change for this release. --Jani -- Forwarded message -- Date: Tue, 18 Sep 2001 03:21:52 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch - Dont Use Previous Sorry Sorry Sorry, about an hour ago i send you my patch for the critical BUG with the ID 11998. Unfourtunately, i sent a totally fucked up patch (file). DO NOT APPLY it. Here is the correct patch, with some additional checks and with the header end check finally working. Sorry for my mistake ;) My only apology is, that it is deep midnight here in germany *g* Yours, Ralf PS: as a side effect of my patch, the 30 files crash bug is fixed, too :) --- Weitergeleitete Nachricht / Forwarded Message --- Date: Tue, 18 Sep 2001 02:05:42 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch Hello, today i browsed through the php bug database on the search for critical bugs. I then saw Bug id #11998 which speaks of some bugs in rfc1867.c. Due to the fact i saw several flaws in the source code some time ago, i patched my version. I now send you my patch and the patch applied to the cvs snapshot of today, that fixes several bugs... first and foremost the fix that went into 4.0.6 was not only broken, but also implemented a possible NULL pointer dereference. The main problem with that fix was, that it applied the search end of headers functionality to the wrong place. The array upload was also crashable by simply using a name like invalid][ as var name. I fixed it by correcting the IF clause that decides if it is an array upload or not. In fact my fix consists of several stability fixes that also make the upload more robust against browsers that are not 100% rfc conform. Hope my patch helps you to improve php even more. I really like the whole idea of php and would be lucky if my contribution helps to make it even better than it already is. Yours, Ralf Bolte -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.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 Development Mailing List http://www.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 #13007 Updated: is there such meaning of unsigned long in PHP?
ID: 13007 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: *General Issues Operating System: FreeBSD PHP Version: 4.0.6 New Comment: PHP does not support unsigned longs, and will not provide them in the near future. Previous Comments: [2001-08-28 15:43:21] [EMAIL PROTECTED] 65536 4096 = 0 (right) 65536 65536 = 65536 (right) but 3221225472 1073741824 = 0 (this is wrong, right answer isn't 0 but 2147483648) what I need to do to make above mentioned operations works correctly with unsigned long variables in PHP? thanks. Edit this bug report at http://bugs.php.net/?id=13007edit=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 #13386: problem supressing errors by '@' and including files
From: [EMAIL PROTECTED]
Operating system: SuSE Linux 7.1
PHP version: 4.0.6
PHP Bug Type: Unknown/Other Function
Bug description: problem supressing errors by '@' and including files
Hi Folks!
Pls. look at the following problem: I have a database
application which
returns me up to n datasets containing 40 data fields each.
Every field can hold an URL to an image or anything else.
To detect
if it is an image, I check the image size (which I need
anyway) and if
the test returns TRUE, then it returns an anchor tag to the
calling
application. So far so good...
It works fine until I have less than 13 sets. If I have
more, the PHP
parser returns a warning at every include() I use, telling
me not beeing
able to include the file. Very strange, isn't it?
If I don't use the
if ($img_size_array = @getimagesize
($image_dir.$input_array[$i])
to check if there's an image or not, the problem doesn't
happen. It
seems to be a problem of too much errors or warnings
(supressed by
the '@'). Maybe a stack overflow or something like this?
This is the function I use:
(p.s.: I already have a workaround, so the problem is not
urgent)
?
function get_img_tags($input_array) {
include (bcontent.php);
$img_tag = array();
for ($i = 0; $i = count($input_array); $i++) {
$img_sp1 = $img_space1;
$img_sp2 = $img_space2;
if (preg_match ((\Apdf), $input_array[$i])) {
$img_tag[$i] = $img_sp1.a
href=\.$image_url.$input_array[$i].\
alt=\.$input_array[$i+1].\.$input_array[$i+1]./a.
$img_sp2;
} else if ($img_size_array = @getimagesize
($image_dir.$input_array[$i])) {
$img_tag[$i] = $img_sp1.img
src=\.$image_url.$input_array[$i].\
.$img_size_array[3].
alt=\.$input_array[$i+1].\.$img_sp2;
}
}
return ($img_tag);
}
?
Kind regards,
Ulrich S. Kapp
BIGPiNG! oHG
Raamkamp 8
22397 Hamburg
phone: 0049 40 608892-77
fax: 0049 40 608892-88
eMail: [EMAIL PROTECTED]
--
Edit bug report at: http://bugs.php.net/?id=13386edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd)
indeed boyer-moore is slower for short strings... anyway i have made a patch that addresses both mac/unix/dos line endings and also works with files that have different endings inside (imagine a file created on *nix edited under windows), which is a very common case. it is slightly slower than current ver (89 seconds before patch/92 seconds after patch for a very big test) but makes stuff more compatible. b. - Original Message - From: Derick Rethans [EMAIL PROTECTED] To: Andi Gutmans [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, September 21, 2001 8:14 PM Subject: Re: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) On Fri, 21 Sep 2001, Andi Gutmans wrote: Seems like boyer_str_to_str() is buggy. If I change it to php_str_to_str() it seems to work. I think Sascha added this function but I might be wrong. When I added some support for MAC line endings, I was told boyer_str_to_Str() was the faster method... so I choose that one. Not knowing that it was still experimental. Maybe place a comment about things being experimental in the source next time would guard against this kind of problems Derick Andi At 06:46 PM 9/21/2001 +0300, Boian Bonev wrote: please check bug id 13385, i hope that this is my mistake or inappropriate build, but if i am not wrong, it is a serious thing... in short ? echo nl2br(asd\n\ndsa\r\rqwe\r\n\newq\n\r\r) ? hangs with latest cvs. b. - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 21, 2001 6:18 PM Subject: Fwd: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Guys, I think this is the last problem which is holding up RC3 and hopefully 4.0.7. Does anyone here know the code in rfc1867? I don't know it well enough in order to decide if this patch is OK or not. If no one answers I'll apply it and we should as the QA guys to test file uploads extensively in RC3. Andi Date: Tue, 18 Sep 2001 17:22:41 +0200 (CEST) From: Jani Taskinen [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd) Could someone who knows the current code better check this out and apply this patch? My work for the other issues is not done yet..and it's too big of a change for this release. --Jani -- Forwarded message -- Date: Tue, 18 Sep 2001 03:21:52 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch - Dont Use Previous Sorry Sorry Sorry, about an hour ago i send you my patch for the critical BUG with the ID 11998. Unfourtunately, i sent a totally fucked up patch (file). DO NOT APPLY it. Here is the correct patch, with some additional checks and with the header end check finally working. Sorry for my mistake ;) My only apology is, that it is deep midnight here in germany *g* Yours, Ralf PS: as a side effect of my patch, the 30 files crash bug is fixed, too :) --- Weitergeleitete Nachricht / Forwarded Message --- Date: Tue, 18 Sep 2001 02:05:42 +0200 (MEST) From: Ralf Bolte [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug id #11998 - source code patch Hello, today i browsed through the php bug database on the search for critical bugs. I then saw Bug id #11998 which speaks of some bugs in rfc1867.c. Due to the fact i saw several flaws in the source code some time ago, i patched my version. I now send you my patch and the patch applied to the cvs snapshot of today, that fixes several bugs... first and foremost the fix that went into 4.0.6 was not only broken, but also implemented a possible NULL pointer dereference. The main problem with that fix was, that it applied the search end of headers functionality to the wrong place. The array upload was also crashable by simply using a name like invalid][ as var name. I fixed it by correcting the IF clause that decides if it is an array upload or not. In fact my fix consists of several stability fixes that also make the upload more robust against browsers that are not 100% rfc conform. Hope my patch helps you to improve php even more. I really like the whole idea of php and would be lucky if my contribution helps to make it even better than it already is. Yours, Ralf Bolte -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- GMX - Die
[PHP-DEV] Bug #13387: Parser chokes on first case in switch statement if seperately script-delimited
From: [EMAIL PROTECTED]
Operating system: Mandrake Linux
PHP version: 4.0.5
PHP Bug Type: *Compile Issues
Bug description: Parser chokes on first case in switch statement if seperately
script-delimited
Description:
The parser chokes on the first case in switch statment if the switch and
case statements are separately script-delimited.
Error message:
Parse error: parse error, expecting `T_CASE' or `T_DEFAULT' or `'}''
Example:
? switch( $item[type] ) { ?
? case copy: ?- CHOKES ON THIS LINE
?= $item[copy] ?br
? break; ?
? case tidbit: ?
? $item[tidbit]-WriteHTML(); ?
? break; ?
...
? } ?
Removing the ? ? between the switch and first case, like this, works:
? switch( $item[type] ) {
case copy: ?
?= $item[copy] ?br
? break; ?
? case tidbit: ?
? $item[tidbit]-WriteHTML(); ?
? break; ?
...
? } ?
Thanks, you guys rock!
--
Edit bug report at: http://bugs.php.net/?id=13387edit=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 #13388: Could not connect to server
From: [EMAIL PROTECTED] Operating system: PHP version: 4.0.6 PHP Bug Type: IIS related Bug description: Could not connect to server Configuration: 1. Windows 2000 Server (SP2) with PHP 4.0.6 using php4isapi.dll 2. Problem: Warning: Failed to Connect in..pathphp_fileline 3. Interesting Notes: The mail function works when configuring PHP enabled website with PHP.exe -- Edit bug report at: http://bugs.php.net/?id=13388edit=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 #13388 Updated: Could not connect to server
ID: 13388 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: IIS related Operating System: PHP Version: 4.0.6 New Comment: This all makes no sense, please reopen with real information. (And read www.php.net/bugs-dos-and-donts.php before posting). Derick Previous Comments: [2001-09-22 09:05:10] [EMAIL PROTECTED] Configuration: 1. Windows 2000 Server (SP2) with PHP 4.0.6 using php4isapi.dll 2. Problem: Warning: Failed to Connect in..pathphp_fileline 3. Interesting Notes: The mail function works when configuring PHP enabled website with PHP.exe Edit this bug report at http://bugs.php.net/?id=13388edit=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] RISC OS port
On 11/9/2001 I wrote: James Moore [EMAIL PROTECTED] wrote: There's only a handful of small patches to various files, and a new SAPI module. Should I post the changes to this list, mail them to someone, or apply for a CVS account? I don't envisage too many more changes, but there might be the odd thing now and again if other peoples changes cause things to break. Post them to the list for review then if they are to be incorporated then you need to apply for a CVS account and you will be given access to the relevant parts of the code. OK, here they are. In some places I've used #ifdef riscos as this is defined by the compiler. It looks a bit odd though as it is not upper case. Has anyone had a look at them yet? Or does the silence mean they're fine? Alex -- Alex Waugh [EMAIL PROTECTED] RISC OS software from http://www.alexwaugh.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] enable truetype string function in gd
I try to get the above mentioned to work with the 4.0.6 release on Linux! But even though I provide the configure script with the --enable-gd-native-ttf switch, it reports that the feature is a no go There was a slight buglet in 4.0.6. Use --enable-gd-native-tt instead. -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] ZEND_INIT_MODULE_GLOBALS problem
I've run into the following problem recently:
PHP_MINIT(foo)
{
ZEND_INIT_MODULE_GLOBALS(foo, NULL, NULL);
}
If ZTS is not defined then the compilation aborts with called object is
not a function because ZEND_INIT_MODULE_GLOBALS tries to call NULl as a
function name. How should this be corrected?
-Andrei
Documentation is worth it just to be able
to answer all your mail with 'RTFM'. -- Alan Cox
--
PHP Development Mailing List http://www.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 #13388 Updated: Could not connect to server
How could you say this is bogus? What does this mean? Do you reject the bug? On what grounds. This is very simple. 1. Windows 2000 server with SP2 running IIS 5.0. 2. There are 2 ways to setup PHP with IIS. First way: a) IIS manager b) Select Website properties c) Select Home Directory Tab d) Select Configuration e) Select Add f) Select Executable: c:\php\php.exe (this is where I installed it) g) Select Extention: .php h) Select All Verbs and Script Engine check boxes. THIS METHOD WORKS CORRECTLY WITH OUR SMTP SERVER AND THE PHP MAIL FUNCTION WE CAN SEND OUT MAIL NO PROBLEM. Second way: a) IIS manager b) Select Website properties c) Select Home Directory Tab d) Select Configuration e) Select Add f) Select Executable: c:\php\sapi\php4isapi.dll (this is where I installed it) g) Select Extention: .php h) Select All Verbs and Script Engine check boxes. THIS METHOD DOES NOT WORK WITH OUR SMTP SERVER. WE CANNOT SEND OUT MAIL NO PROBLEM. Derek, I suggest you give some more details as to why you rejected this problem. How can you determine it is bogus within 2 minutes, please provide your rational. Thank-You, Dean Gossi PSG Network Systems Software Engineering The Document Company, XEROX Office: 716.422.1062 Lab: 716.422.0068 Pager: 716.921.0489 Email: [EMAIL PROTECTED] -Original Message- From: Bug Database [mailto:[EMAIL PROTECTED]] Sent: Saturday, September 22, 2001 3:31 AM To: [EMAIL PROTECTED] Subject: Bug #13388 Updated: Could not connect to server ID: 13388 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: IIS related Operating System: PHP Version: 4.0.6 New Comment: This all makes no sense, please reopen with real information. (And read www.php.net/bugs-dos-and-donts.php before posting). Derick Previous Comments: [2001-09-22 09:05:10] [EMAIL PROTECTED] Configuration: 1. Windows 2000 Server (SP2) with PHP 4.0.6 using php4isapi.dll 2. Problem: Warning: Failed to Connect in..pathphp_fileline 3. Interesting Notes: The mail function works when configuring PHP enabled website with PHP.exe ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=13388edit=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 #13389: mail() function will not connect SMTP server when IIS config w/ php4isapi.dll
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.0.6 PHP Bug Type: *General Issues Bug description: mail() function will not connect SMTP server when IIS config w/ php4isapi.dll I read your www.php.net/bugs-dos-and-donts.php file. Here is your information. Explain the type of information you require to answer this problem, and explain why this bug is rejected, on what grounds? Remember, I am providing this information for FREE, you are getting free pairwise/integration testing. You should take more than 2 minutes to evaluate a problem. Here are your details.follow this procedure to replicate. This is very simple. 1. Windows 2000 server with SP2 running IIS 5.0. 2. There are 2 ways to setup PHP with IIS. First way: a) IIS manager b) Select Website properties c) Select Home Directory Tab d) Select Configuration e) Select Add f) Select Executable: c:\php\php.exe (this is where I installed it) g) Select Extention: .php h) Select All Verbs and Script Engine check boxes. THIS METHOD WORKS CORRECTLY WITH OUR SMTP SERVER AND THE PHP MAIL FUNCTION WE CAN SEND OUT MAIL NO PROBLEM. Second way: a) IIS manager b) Select Website properties c) Select Home Directory Tab d) Select Configuration e) Select Add f) Select Executable: c:\php\sapi\php4isapi.dll (this is where I installed it) g) Select Extention: .php h) Select All Verbs and Script Engine check boxes. THIS METHOD DOES NOT WORK WITH OUR SMTP SERVER. WE CANNOT SEND OUT MAIL NO PROBLEM. Derek, I suggest you give some more details as to why you rejected this problem. How can you determine it is bogus within 2 minutes, please provide your rational. -- Edit bug report at: http://bugs.php.net/?id=13389edit=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 #13389 Updated: mail() function will not connect SMTP server when IIS config w/ php4isapi.dll
ID: 13389 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: *General Issues Operating System: Windows 2000 PHP Version: 4.0.6 New Comment: Ok, one more time: This is probably not a bug, please ask for support questions on the [EMAIL PROTECTED] mailing list. And there is no need to create a new bug report (if there is any bug) for the same bug, just update the original one. Derick (and not Derek) Previous Comments: [2001-09-22 10:06:55] [EMAIL PROTECTED] I read your www.php.net/bugs-dos-and-donts.php file. Here is your information. Explain the type of information you require to answer this problem, and explain why this bug is rejected, on what grounds? Remember, I am providing this information for FREE, you are getting free pairwise/integration testing. You should take more than 2 minutes to evaluate a problem. Here are your details.follow this procedure to replicate. This is very simple. 1. Windows 2000 server with SP2 running IIS 5.0. 2. There are 2 ways to setup PHP with IIS. First way: a) IIS manager b) Select Website properties c) Select Home Directory Tab d) Select Configuration e) Select Add f) Select Executable: c:\php\php.exe (this is where I installed it) g) Select Extention: .php h) Select All Verbs and Script Engine check boxes. THIS METHOD WORKS CORRECTLY WITH OUR SMTP SERVER AND THE PHP MAIL FUNCTION WE CAN SEND OUT MAIL NO PROBLEM. Second way: a) IIS manager b) Select Website properties c) Select Home Directory Tab d) Select Configuration e) Select Add f) Select Executable: c:\php\sapi\php4isapi.dll (this is where I installed it) g) Select Extention: .php h) Select All Verbs and Script Engine check boxes. THIS METHOD DOES NOT WORK WITH OUR SMTP SERVER. WE CANNOT SEND OUT MAIL NO PROBLEM. Derek, I suggest you give some more details as to why you rejected this problem. How can you determine it is bogus within 2 minutes, please provide your rational. Edit this bug report at http://bugs.php.net/?id=13389edit=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: Bug #13388 Updated: Could not connect to server
Hello, please use the webform to update your reports. On Fri, 21 Sep 2001, Gossi, Dean wrote: How could you say this is bogus? What does this mean? Do you reject the bug? On what grounds. Too less information. This is very simple. 1. Windows 2000 server with SP2 running IIS 5.0. 2. There are 2 ways to setup PHP with IIS. First way: a) IIS manager b) Select Website properties c) Select Home Directory Tab d) Select Configuration e) Select Add f) Select Executable: c:\php\php.exe (this is where I installed it) g) Select Extention: .php h) Select All Verbs and Script Engine check boxes. THIS METHOD WORKS CORRECTLY WITH OUR SMTP SERVER AND THE PHP MAIL FUNCTION WE CAN SEND OUT MAIL NO PROBLEM. Second way: a) IIS manager b) Select Website properties c) Select Home Directory Tab d) Select Configuration e) Select Add f) Select Executable: c:\php\sapi\php4isapi.dll (this is where I installed it) g) Select Extention: .php h) Select All Verbs and Script Engine check boxes. THIS METHOD DOES NOT WORK WITH OUR SMTP SERVER. WE CANNOT SEND OUT MAIL NO PROBLEM. Derek, I suggest you give some more details as to why you rejected this problem. As I said, too less information, and this is probably not a bug. Please try to ask on the [EMAIL PROTECTED] or [EMAIL PROTECTED] for support questions. How can you determine it is bogus within 2 minutes, please provide your rational. I just did. Derick -- PHP Development Mailing List http://www.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: Bug #13388 Updated: Could not connect to server
What information are you looking for..I just told you how to reproduce it. What me to fix it for you... I guess I should just use asp. With this type of developer support (2-5 word responses to your emails) I don't think php will cause any stir in the marketplace Thank-You, Dean Gossi PSG Network Systems Software Engineering The Document Company, XEROX Office: 716.422.1062 Lab: 716.422.0068 Pager: 716.921.0489 Email: [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 4:04 PM To: Gossi, Dean Cc: 'Bug Database' Subject: Re: [PHP-DEV] RE: Bug #13388 Updated: Could not connect to server Hello, please use the webform to update your reports. On Fri, 21 Sep 2001, Gossi, Dean wrote: How could you say this is bogus? What does this mean? Do you reject the bug? On what grounds. Too less information. This is very simple. 1. Windows 2000 server with SP2 running IIS 5.0. 2. There are 2 ways to setup PHP with IIS. First way: a) IIS manager b) Select Website properties c) Select Home Directory Tab d) Select Configuration e) Select Add f) Select Executable: c:\php\php.exe (this is where I installed it) g) Select Extention: .php h) Select All Verbs and Script Engine check boxes. THIS METHOD WORKS CORRECTLY WITH OUR SMTP SERVER AND THE PHP MAIL FUNCTION WE CAN SEND OUT MAIL NO PROBLEM. Second way: a) IIS manager b) Select Website properties c) Select Home Directory Tab d) Select Configuration e) Select Add f) Select Executable: c:\php\sapi\php4isapi.dll (this is where I installed it) g) Select Extention: .php h) Select All Verbs and Script Engine check boxes. THIS METHOD DOES NOT WORK WITH OUR SMTP SERVER. WE CANNOT SEND OUT MAIL NO PROBLEM. Derek, I suggest you give some more details as to why you rejected this problem. As I said, too less information, and this is probably not a bug. Please try to ask on the [EMAIL PROTECTED] or [EMAIL PROTECTED] for support questions. How can you determine it is bogus within 2 minutes, please provide your rational. I just did. Derick -- PHP Development Mailing List http://www.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: Bug #13388 Updated: Could not connect to server
As I said, too less information, and this is probably not a bug. Please try to ask on the [EMAIL PROTECTED] or [EMAIL PROTECTED] for support questions. This is probably not a bug ? Are you kidding me ? I hope you are not closing any real nasty bugs because of this reasoning :) How can you determine it is bogus within 2 minutes, please provide your rational. I just did. Yeah, I guess you did. Joao -- João Prado Maia [EMAIL PROTECTED] http://phpbrasil.com - php com um jeitinho brasileiro -- Precisando de consultoria em desenvolvimento para a Internet ? Impleo.net - http://impleo.net/?lang=br -- PHP Development Mailing List http://www.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: Bug #13388 Updated: Could not connect to server
How can you determine it is bogus within 2 minutes, please provide your rational. (...) This is probably not a bug ? Are you kidding me ? I hope you are not closing any real nasty bugs because of this reasoning :) From http://www.chiark.greenend.org.uk/~sgtatham/bugs.html Give the programmer some credit for basic intelligence: if the program really didn't work at all, they would probably have noticed. Since they haven't noticed, it must be working for them. Therefore, either you are doing something differently from them, or your environment is different from theirs. They need information; providing this information is the purpose of a bug report. More information is almost always better than less. This isn't really a case of a program not working at all, but somebody coded this feature, and it does work. So you're either doing something wrong, or the cause is in your specific enviroment. Since you're using windows (a popular and widely-used platform, and therefore much tested), Derick guessed - and I think he's right - that you were doing something wrong. To find it out, see the support forums, (http://www.php.net/support.php), because they are there for things like this. If they come to the conclusing this is a bug, you can report it again. --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 #11945 Updated: ignore
ID: 11945 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: ugly bug PHP Version: 4.0.6 New Comment: Test timing settings of www.php.net (off by approx. 9 or 10 hours) Previous Comments: [2001-07-10 17:01:17] just testing [2001-07-07 12:33:09] [EMAIL PROTECTED] please ignore Edit this bug report at http://bugs.php.net/?id=11945edit=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] Time of www.php.net incorrect
I posted a bug-update 5 minutes ago, and from the mail headers: Date: 22 Sep 2001 10:34:57 - It is now GMT/UTC 21 sep 2001 22:30 or something. That means that bugs.php.net is off-time by 12 hours, which is very annoying. (chronology of posts is completely wrong). Can someone please fix this? --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]
Re: [PHP-DEV] RE: Bug #13388 Updated: Could not connect to server
Gossi, Dean wrote: What information are you looking for..I just told you how to reproduce it. What me to fix it for you... The information you provided boils down to that on Win2k SP2, IIS, mail() works for you when PHP runs as CGI, but not as a module. Since only mail() doesn't work for the module, and does for cgi, I (and probably you, too) assume that PHP is installed correctly. Module = CGI is the only difference, so this might be the problem. (side note: regarding how few information you provided, your report was a little too long) This is why you'd prefer this bug to be reproduced by someone of the qa-team rather than being bogusified. But a developer who knows PHP (and Derick sure does, far better than I do, anyway, he is in the php-dev team, not me) will notice that the change in the (server-API) should not affect the mail function, they are not related (I assume). This is either a pretty strange side-effect, or a configuration issue. IIS might be a little strange sometimes. And although IIS is not the most common webserver used with PHP, there is quite a userbase for this combination, many of them using PHP as a module. If mail() didn't work for all of them, it is quite strange nobody noticed. This makes it more probable that this is a configuration issue. This is why Derick bogusified the bug. I hope both sides see each others points now. Anyway, configuration issues are not bugs within PHP. Basically, what Derick and Jeroen ask you to do is to go ahead and ask on php-general and php-windows, two public mailinglists about php, if somebody knows this problem. If you don't find a solution, somebody else can reproduce this problem or you find out what the configuration problem was, feel free to ask for re-opening the bug-report (using the web-interface, not answering to the mail), request a change in the manual noting the config-problem or just add it yourself to the annotated manual. PHP is a community effort. You'd be part of this community then :-) If neither php-general nor php-windows can help you or you can prove that this bug can be reproduced on other systems, I'm sure the php-qa and dev teams will try to resolve this. You'd have to provide more information then. Like does PHP even try to connect to the SMTP-server or does it fail after the connect? Otherwise, it's hard to do remote diagnostics. I guess I should just use asp. With this type of developer support (2-5 word responses to your emails) I don't think php will cause any stir in the marketplace A response that basically says not enough input isn't required to be wordy, is it? Mind you, these people are volunteers. Also, for many of them english is not their native language, english is just the common ground they meet on. When you get something for free, please remember that you're not in a corporate environment. This is a community. If all parts (core-team and users in this case) are nice to each other, it makes the world a better place. Didn't Gartner just recommend not using IIS? Either having to install a patch every week or reinstalling the whole machine every few months? Is that a stir? When Microsoft tells you that with their software, you can do complicated things easily, you might not end up with what you wanted. I would recommend to try using Apache, it tends to be more reliable (this is just my opinion) and is more common (= tested) in combination with PHP. I heard a few really bad stories from people having used ASP who ended up with PHP and were happy. On the other hand, what else would you expect from the PHP-community? regards Wagner -- PHP Development Mailing List http://www.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] parsing
On Fri, Sep 21, 2001 at 01:09:49AM +0200, Dries Plessers wrote : Hello, [suuport question skipped] This is not a support forum, try asking on [EMAIL PROTECTED] . - Markus -- PHP Development Mailing List http://www.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] Zend CVS doesn't compile
Tried latest cvs update from zend and yy_state_type is typedef'ed in multiple places. Attached is a patch which should allow you to compile. I'm not sure what the procedure is for getting the fix back to zend. patch.zend -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
