[PHP-DEV] Bug #12751 Updated: Form.php Pear Class errors
ID: 12751 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: *Programming Data Structures Operating System: linux debian2.3 PHP Version: 4.0.6 New Comment: Can you please resend your patch to [EMAIL PROTECTED]? (As attachment) Derick Previous Comments: [2001-08-14 22:35:33] [EMAIL PROTECTED] Here's a copy of the diff between your Form.php and the corrected one I made. === RCS file: Form.php,v retrieving revision 1.1 diff -r1.1 Form.php 302c302 $size = 1, $blank = '', $multiple = false) --- $size = 1, $blank = '', $multiple = false, $attrib = '') 305c305 $blank, $multiple); --- $blank, $multiple, $attrib); 501c501 $blank = '', $multiple = false) --- $blank = '', $multiple = false, $attrib = '') 506c506 $str .= $this-returnSelect($name, $entries, $default, $size, $blank, $multiple); --- $str .= $this-returnSelect($name, $entries, $default, $size, $blank, $multiple, $attrib); Edit this bug report at http://bugs.php.net/?id=12751edit=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] Setting up RFC
On Tue, 14 Aug 2001, John Donagher wrote: With what end in mind is an RFC to be created for? In the IETF, RFC's are typically long, complex, and authoritative. They are often referenced for years after their inception. Do you honestly think we could (or want to) achieve this with PHP feature RFC's? Or will they be used only before initial feature implementation, then quickly outdated and discarded? That is my biggest problem with documents: they take a lot of effort to create, are often difficult to grok, and _almost always_ have a very short lifecycle. Although probable PHP RFC's won't be as complex as IETF RFC's, I still think the main problem is that almost every developer hates it to write docs. Doc writing is the most worse thing of software developing, I think most people will agree with me on this. However I think the whole RFC will lurk up too much of our precious time. The idea may be good, but I don't think it will work out as it is intended to be. 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 #12755: Viewing and inserting the data in the table
From: [EMAIL PROTECTED] Operating system: unix PHP version: 4.0.6 PHP Bug Type: Any Bug description: Viewing and inserting the data in the table 1.If I want to view the content of the table ,Iam getting this message,Please suggest me the solution mala= select * from APPFORMtable; Field| Value (0 rows) 2.If I want to add the data in the table which is in the word format.Please suggest me the solution for which I can add the data at one shot . -- Edit bug report at: http://bugs.php.net/?id=12755edit=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 #12755 Updated: Viewing and inserting the data in the table
ID: 12755 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Old Bug Type: Any Bug Type: *General Issues Operating System: unix PHP Version: 4.0.6 New Comment: not php problem. Ask this kind of support questions on some mailing list. http://www.php.net/support.php Previous Comments: [2001-08-15 02:59:04] [EMAIL PROTECTED] 1.If I want to view the content of the table ,Iam getting this message,Please suggest me the solution mala= select * from APPFORMtable; Field| Value (0 rows) 2.If I want to add the data in the table which is in the word format.Please suggest me the solution for which I can add the data at one shot . Edit this bug report at http://bugs.php.net/?id=12755edit=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 #12515 Updated: PHP-Compilation sucks: php_mnogo.h:76: Floating point numbers not allowed in #i
ID: 12515 Updated by: gluke Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: mnoGoSearch related Operating System: Suse Linux 7.2, Kernel 2.4.x PHP Version: 4.0.6 New Comment: To be more exact i can tell that i will update mnogosearch php extenstion after release of mnogosearch-3.2.x, because of its fast API changes. Previous Comments: [2001-08-01 13:49:34] [EMAIL PROTECTED] A development version of Mnogosearch won't work with PHP 4.0.6..you should use the 3.1.3.5 version instead. --Jani [2001-08-01 11:39:43] [EMAIL PROTECTED] Hi, I can't compile my PHP 4.0.6+Apache 1.3.20 with mnogosearch support. I get the followíng error: ## /main -I/usr/local/src/php-4.0.6 -I/usr/local/apache/1.3.20/include -I/usr/local/src/php-4.0.6/Zend -I/usr/local/openssl/current/include -I/usr/include/freetype -I/usr/local/mnoGoSearch/current/include -I/usr/local/mysql/current/include/mysql -I/usr/lib/db2/db2inst1/sqllib/include -I/usr/local/lib/libswf/include -I/usr/local/src/php-4.0.6/ext/xml/expat/xmltok -I/usr/local/src/php-4.0.6/ext/xml/expat/xmlparse -I/usr/local/src/php-4.0.6/TSRM -DLINUX=22 -DDEV_RANDOM=/dev/random -DMOD_SSL=208104 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2 -c internal_functions.c In file included from internal_functions.c:37: /usr/local/src/php-4.0.6/ext/mnogosearch/php_mnogo.h:76: Floating point numbers not allowed in #if expressions In file included from /usr/lib/db2/db2inst1/sqllib/include/sqlcli1.h:42, from /usr/local/src/php-4.0.6/ext/odbc/php_odbc.h:170, from internal_functions.c:39: /usr/lib/db2/db2inst1/sqllib/include/sqlcli.h:718: warning: `ODBCVER' redefined /usr/local/src/php-4.0.6/ext/odbc/php_odbc.h:27: warning: this is the location of the previous definition make[2]: *** [internal_functions.lo] Error 1 make[2]: Leaving directory `/usr/local/src/php-4.0.6/main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/php-4.0.6/main' make: *** [all-recursive] Error 1 # Without mnogosearch support I can compile Apache with PHP. I have mnogosearch 3.2.0.b0. Can somebody help me? Thanks Stefan Edit this bug report at http://bugs.php.net/?id=12515edit=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 #12747 Updated: ***BUG in Autoconf--please report***
ID: 12747 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Old Bug Type: *Compile Issues Bug Type: Compile Failure Operating System: Mandrake Linux 8.0 PHP Version: 4.0CVS-2001-08-14 New Comment: I think your cvs checkout isn't quite 'clean'. Try to do a clean checkout first. To be sure which tools PHP finds, run: # build/buildcheck.sh As the first error would indicate that there is something wrong with those.. --Jani Previous Comments: [2001-08-14 20:05:37] [EMAIL PROTECTED] autoconf-2.13-7.mdk automake-1.4-15mdk libtool-1.4 Trying to compile the cvs version of PHP. After updating from the CVS server and running ./buildconf. [onaias@frodo php4]$ ./buildconf aclocal: configure.in: 895: macro `AM_PROG_LIBTOOL' not found in library rebuilding Makefile templates rebuilding Makefile templates rebuilding configure autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_ADD_INCLUDE configure.in:442:PHP_AC_BROKEN_SPRINTF rebuilding main/php_config.h.in [onaias@frodo php4]$ Edit this bug report at http://bugs.php.net/?id=12747edit=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 #12744 Updated: Command line option -c failing
ID: 12744
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: PHP options/info functions
Operating System:
PHP Version: 4.0.6
New Comment:
Works for me with latest CVS so it seems to have been
fixed. Try a snapshot: http://snaps.php.net/
--Jani
Previous Comments:
[2001-08-14 18:49:56] [EMAIL PROTECTED]
In file sapi/cgi/cgi_main.c
on line 400 the ini search path is set from the code:
if (php_module_startup(cgi_sapi_module)==FAILURE) {
return FAILURE;
}
but the actual -c option is not read until line 442 from the code:
if (!cgi) {
while ((c=ap_php_getopt(argc, argv, OPTSTRING))!=-1) {
...
}
...
}
Once I moved the code from line 400 after the -c option was read, it worked prefectly.
Edit this bug report at http://bugs.php.net/?id=12744edit=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] Setting up RFC
[Jeroen van Wolffelaar [EMAIL PROTECTED]] Hi, About a month ago there was a discussion on the Engine 2 mailing list, about a possible RFC-proces for the more imporant PHP-issues. In the end, there was some consensus that it would be good if such a system exists. I'm simply writing to get some comments, to hear what the general opinion is. If that is not negative, I think it should be tried to set it up. About the details, there needs to be discussion of course, but it would be more efficient to discuss those things after a proposal has been made, in stead of construct such a proposal by discussion. Joey Smith and Zak Great supported the idea on the list, but the discussion went dead. Below I quote some of their mails. Hi, I think one of the problems with this is that even if php-dev comes up with a system for determining which feature it wants to see in PHP, we still depend on Zeev, Andi or someone else @ Zend to implement them. An RFC system would be a support for Zend's decision-making. At the end of the day, due to the licensing issues, php-dev is not the body governing the language, it has an advisory role only. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12745 Updated: problem with the randomic generation of salt when a use crypt(pass)
ID: 12745
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: *Encryption and hash functions
Operating System: Linux Slackware 7.1
PHP Version: 4.0.6
New Comment:
So what is the 'bug' here??
--Jani
Previous Comments:
[2001-08-14 19:40:26] [EMAIL PROTECTED]
problem with the randomic generation of salt when a use $string =
crypt(11lei11lao11) it allways generates a salt ( the first 2 chars from encrypted
string ) that if use crypt(11lei11lao11blablabla) would work, and also
crypt(11lei11lao11anythingwouldworkhere).
the code is
$cryptedpass = crypt(11lei11lao11);
if (crypt ( 11lei11lao11anythingwouldworkhere, substr ( $cryptedpass, 0, 2)) ==
$cryptedpass) {
echo this is extremely strange for me;
}
and this works with this pass but not whit others!
Edit this bug report at http://bugs.php.net/?id=12745edit=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] fileperms(), fileinode(), filesize(), is_readable(), etc.
[Sterling Hughes [EMAIL PROTECTED]] As an issue for PHP 5 (or PHP 4.1 for that matter), perhaps we should remove these functions and just stick with stat() and lstat() calls? This would remove a bunch of functions which aren't really that necessary (I'm probably just being a minimalist, but I figured I'd bring it up :) Hey, let's not become C, I think they're just right. Usually when I stat a file, I only need one attribute. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] fileperms(), fileinode(), filesize(), is_readable(), etc.
On Wed, Aug 15, 2001 at 01:22:22AM -0400, Sterling Hughes wrote : As an issue for PHP 5 (or PHP 4.1 for that matter), perhaps we should remove these functions and just stick with stat() and lstat() calls? This would remove a bunch of functions which aren't really that necessary (I'm probably just being a minimalist, but I figured I'd bring it up :) Oh No! (Lemming style) For all the 'is_()' functions I think we shouldn't remove them. Its that what makes PHP. You read ne source and with one glance you know whats going on. Sometimes reading PHP source is nothing harder then reading english; I personally like this. And, hey, internally they're all just calling to php_stat(); whats wrong with it ? What is it you think we (you?) gain from the change (apart from many end-users knowing you name well then :) - Markus -- Markus Fischer, http://guru.josefine.at/~mfischer/ EMail: [EMAIL PROTECTED] PGP Public Key: http://guru.josefine.at/~mfischer/C2272BD0.asc PGP Fingerprint: D3B0 DD4F E12B F911 3CE1 C2B5 D674 B445 C227 2BD0 -All your scripts are belong to 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]
Re: [PHP-DEV] libmysql and MS Visual Studio .NET
Sebastian Bergmann wrote: It still chokes on the strtoll.c file. I wonder if someone else has tried to build PHP (or MySQL) with this next version of the standard Win32 compiler. Just tried it again, and now it compiles strtoll.c with a compiler error. This is odd. Making a clean rebuild gives an error, but when I just build (without cleaning up from the previous - failed - try to build it compiles. (I'm now trying to resolve a linkage error. MSVC can't resolve symbol _bc_out_num in function _pn, and I can't fine _bc_out_num and _pn on lxr.php.net) Sorry for bothering, Sebastian -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.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] Setting up RFC
At 10:23 15-08-01, Stig Sæther Bakken wrote: [Hi, I think one of the problems with this is that even if php-dev comes up with a system for determining which feature it wants to see in PHP, we still depend on Zeev, Andi or someone else @ Zend to implement them. An RFC system would be a support for Zend's decision-making. At the end of the day, due to the licensing issues, php-dev is not the body governing the language, it has an advisory role only. Generally, I agree with you, except it's not because of licensing issues (will we end up with a load of features suddenly getting into PHP if/when the engine license changes?). Many other projects behave that way. With a language definition, vox populi, vox Dei doesn't tend to work very well. 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 #12715 Updated: IE download file twice when serve from DB.
ID: 12715 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Output Control Operating System: Linux PHP Version: 4.0.6 New Comment: found a way around, but I had to drop: header(Content-Disposition: filename=$file_name); when ever Content-Disposition found in the code IE load the page twice. Or no one know the answer ( with Content-Disposition ) or its a bug. Any way I think the solution need to apear on the manual to avoid lots of site that double the dl time. Previous Comments: [2001-08-13 10:23:41] [EMAIL PROTECTED] Not a bug. Ask further support questions on the appropriate mailing list: http://www.php.net/support.php [2001-08-13 09:53:08] [EMAIL PROTECTED] When I download file stored on DB using IE, Its take me double the time then Netscape takes. I discovered that IE download the file twice. one when the headers are read and latter when the file is requested again. here is the code: ? $query = select * from files where issue_id='$id'; $result = mysql_query ($query) or die (Invalid query); $data = @MYSQL_RESULT($result,0, file_data); $type = @MYSQL_RESULT($result,0, file_type); $file_name = @MYSQL_RESULT($result,0, file_name); $file_size = @MYSQL_RESULT($result,0, file_size); // # To force save file //header(Content-disposition: attachment; filename=\$file_name\); Header(Content-type: $type); header(Content-Length: $file_size); header(Content-Disposition: filename=$file_name); echo $data; ? Edit this bug report at http://bugs.php.net/?id=12715edit=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 #12756: Downloadable HTML Docs - Filenames should be limited to 31 chars.
From: [EMAIL PROTECTED] Operating system: PHP version: 4.0.6 PHP Bug Type: Unknown/Other Function Bug description: Downloadable HTML Docs - Filenames should be limited to 31 chars. Downloadable HTML Docs - Filenames should be limited to 31 chars. Note that when the HTML version of the docs are downloaded, they do not work on a Macintosh, because some of the filenames are over the 31 character limit. This means that when the zip file is extracted that the filenames get cropped, so the links to those pages do not work. For example, this is too long: language.basic-syntax.instruction-separation.php -- Edit bug report at: http://bugs.php.net/?id=12756edit=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] ±M¿ì¶U´Ú
±M¿ì¶U´Ú
±z·Q¿ì¶U´Ú¶Ü¡H
§Ú̬O¬F©²¥¿¦¡®Öã¥ß®×¡A»E¿n12¦~¥H¤W¸gÅç¡A
¤@³eªÃ«ù¸Û«Hì«h¡A»P¥ÃÄò¸gÀç²z©À¡A
¨Ï±z°U¥Iªº¨Æ±¡¡A³£¥²¶·n¶êº¡§¹¦¨¡I
¿ì¶U´Ú§Ú̳̱M·~¡A§Q®§³Ì§C¡AºÞ¹D¥¿¦¡¡I
±M ¿ì ¤U ¦C ·~ °È¡G
1.«H«O°òª÷±M®×¿Ä¸ê
µ´¹ï÷í¡A®ÄªG¨³³t¡A±M¿ìºÃÃø¡A°h¥ó¡C
2.L/CÂà²{
°t¦X¥Á¶¡§C§Q¿Ä¸ê¡A¹j¤é¥I´Ú¡A¯u¥¿Ã°·¥i¾a¡C
3.Ó¤H§C§Q«H¥Î¶U´Ú
¤u§@º¡¤@¦~¥H¤W©Îxĵ·~¬Éµ¥¬Ò¥i©Î¦³¦Û¦í©Ð«Î¡A
¤u§@¤£¡A³Ì°ª¥iÉ100¸U«H¥Î¶U´Ú¡C
4.¤½¥q¤á«H¥Î¶U´Ú
¤½¥q«H¥Î¥¿±`¡A¤@¦~¥H¤W¹êÁZ¡A
¥i°t¦X»È¦æµo¦æ¥»°Ó·~²¼¡A®§§C§K¾á«O«~
5.¤¤¤p¥ø·~±M®×¶U´Ú
¦³Àç§Q¨Æ·~µn°OÃÒ¡A¤@¦~¥H¤W¹êÁZ¡A
«H¥Î¥¿±`§Y¥i¿ì²z¡A³Ì°ª¥i¶U100-2000¸U¡A
¤âÄò²«K¡A»È¦æ¿ì²z¡C
6.Ó¤H°ªÃB©Ð«Î¶U´Ú
º¦¸ÁʫζU´Ú¡A©Ð«ÎÂà¼W¶U¡A»È¦æ¤GL¡A
ÃB«×°ª¡B§Q®§§C¡A¥i°t¦X¥ý¦æ½ÕÉÀ³«æ¡C
7.¥Á¶¡§C§Q¶U´Ú
¤½¥qÓ¤H«H¥Î¦³·å²«¡A°t¦X¤£°Ê²£³]©w©è©ã¡A
¤ë®§¯u¥¿¤@¤À¤T°_¡A¥þÃB¼·´Ú¡A¤£¹w¦©§Q®§¡A
´Á¶¡¥i¹F¤G¦~¡A³Æ¤ä²¼¡A3¤é¤º§¹¦¨¼·´Ú¡C
8.«È²¼¶K²{
°t¦X¥Á¶¡§C§Q¿Ä¸ê¡A¨C¸U¤¸/¨C¤é¯u¥¿7¤¸¡A
²¼±¶K²{¤£¥´§é¥þÃB¶K²{¡C
9.«ù¥d±Ú²©ö¶U
«ù¥dº¡¤@¦~¥H¤W¦³¤u§@¡Aú´Ú¥¿±`¡C
10.»È¦æ±M®×¾Ç¥Í²©ö¶U
¤j¾Ç(¾Ç°|)²¦·~¤T¦~¤º¡A30·³¥H¤U¡A«H¥Î¥¿±`¤W¯Z±Ú¡C
¦Ñ¦r¸¹¶U´ÚªA°È¡A
¬O³Ìȱo±z«H¿àªº¥N®Ñ¨Æ°È©Ò¡I
¿ì¤£¨ì¡A¿ì¤£°ª¡H¤@³q¹q¸Ü§ä¨ì§ÚÌ´N¹ï¤F¡I
Åwªï±z¨Ó¹q¬¢¸ß¬ÛÃö²Ó¸`¡C
¹q¸Ü¡G02-27039827 ¡]±i¥N®Ñ¡^
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Setting up RFC
On Wed, 15 Aug 2001, Zeev Suraski wrote: At 10:23 15-08-01, Stig Sæther Bakken wrote: [Hi, I think one of the problems with this is that even if php-dev comes up with a system for determining which feature it wants to see in PHP, we still depend on Zeev, Andi or someone else @ Zend to implement them. An RFC system would be a support for Zend's decision-making. At the end of the day, due to the licensing issues, php-dev is not the body governing the language, it has an advisory role only. Generally, I agree with you, except it's not because of licensing issues (will we end up with a load of features suddenly getting into PHP if/when the engine license changes?). Many other projects behave that way. With a language definition, vox populi, vox Dei doesn't tend to work very well. Yes, the difference is, this creates a situation where the PHP Development team does not have control of the core language, Zend Technologies Ltd. does. Whether this is a issue with a basis in principle or a basis in practicality is up to debate, however, the problem remains. Zend having control of the language has nothing to do with vox Populi, vox Dei (translated the voice of the People, the voice of the Gods), its more of a matter of *who* has control -- Zend Technologies or the PHP Developers. And tell me, what other languages have a commercial body controlling the evolution? Certainly not any that I know of. Yes, they may have a person, or a small group of people deciding what goes in the language and what doesn't, however, this differs in three manners: 1) The leaders are elected by the community -- this makes it so there are signifigantly fewer power struggles (or dick size wars to use a Zak term). 2) This small group usually consists of all the core developers, not just two. 3) The leaders are not a commercial company. The relationship between a commercial company and a group of open source developers is a delicate thing, which requires work to maintain and foster, the feeling in the community, that I am picking up is that Zend has dropped the ball -- the licensing issues, and some of the commercial products surrounding the Zend engine have created in many a feeling of alienation, and that Zend is exploiting its position as the creator of the Zend engine to corner the PHP market. While this does not bode well for either side -- I don't think that means the relationship cannot be repaired, however, I do think that a couple of things do need to happen in order for the relationship to continue with any level of civility. 1) The Zend Engine should be moved to a separate project, outside of the exclusive control of Zend Technologies Ltd., under a BSD (or some other, more friendly license, ie, Apache or MIT). The PHP project should be able to have control of this engine with the same, or greater voice than Zend.. 2) The communication between Zend PHP with relation to internal Zend developments that effect the future of PHP should be improved. PHP 3.1 is a perfect example of a breakdown in communication. 3) (I think this'd be nice) Developments that Zend makes -- such as the Zend optimizer -- that make technical sense to be natively supported in the engine, should be added. A good candidate for this would be the Zend Optimizer. Zend can still make a business around PHP -- however it shouldn't be in forms that detract from the average programmers ability to make use of PHP (Zend IDE, Zend Debugger and Zend Launchpad are steps in the right direction, imho). Perhaps what I'm saying sounds a bit radical, but I do believe that Zend PHP can co-exist with some level of harmony, but changes do need to me made, and communication needs to occur where people on both sides listen to each others concerns. -Sterling Any man is liable to error, but only a fool persists in error. -Cicero (Since we're doing the whole latin thing :) -- PHP Development Mailing List http://www.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 #12757: utf8_encode doesn't terminate strings with '\0'
From: [EMAIL PROTECTED]
Operating system: any
PHP version: 4.0.6
PHP Bug Type: Strings related
Bug description: utf8_encode doesn't terminate strings with '\0'
The enclosed patch fixes the problem.
--- php-4.0.6/ext/xml/xml.c Thu May 24 14:42:12 2001
+++ php-rnyberg/ext/xml/xml.c Wed Aug 15 10:45:03 2001
@@ -494,14 +494,14 @@
if (encoder == NULL) {
/* If no encoder function was specified, return the data
as-is.
*/
- newbuf = emalloc(len);
- memcpy(newbuf, s, len);
+ newbuf = emalloc(len + 1);
+ memcpy(newbuf, s, len + 1);
*newlen = len;
return newbuf;
}
/* This is the theoretical max (will never get beyond len * 2 as
long
* as we are converting from single-byte characters, though) */
- newbuf = emalloc(len * 4);
+ newbuf = emalloc(len * 4 + 1);
while (pos 0) {
c = encoder ? encoder((unsigned char)(*s)) : (unsigned
short)(*s);
if (c 0x80) {
@@ -522,9 +522,10 @@
pos--;
s++;
}
- if (*newlen len * 4) {
- newbuf = erealloc(newbuf, *newlen);
+ if (*newlen len * 4 + 1) {
+ newbuf = erealloc(newbuf, *newlen + 1);
}
+ newbuf[*newlen] = '\0';
return newbuf;
}
/* }}} */
--
Edit bug report at: http://bugs.php.net/?id=12757edit=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] Setting up RFC
At 12:15 15-08-01, Sterling Hughes wrote: On Wed, 15 Aug 2001, Zeev Suraski wrote: At 10:23 15-08-01, Stig Sæther Bakken wrote: [Hi, I think one of the problems with this is that even if php-dev comes up with a system for determining which feature it wants to see in PHP, we still depend on Zeev, Andi or someone else @ Zend to implement them. An RFC system would be a support for Zend's decision-making. At the end of the day, due to the licensing issues, php-dev is not the body governing the language, it has an advisory role only. Generally, I agree with you, except it's not because of licensing issues (will we end up with a load of features suddenly getting into PHP if/when the engine license changes?). Many other projects behave that way. With a language definition, vox populi, vox Dei doesn't tend to work very well. Yes, the difference is, this creates a situation where the PHP Development team does not have control of the core language, Zend Technologies Ltd. does. Whether this is a issue with a basis in principle or a basis in practicality is up to debate, however, the problem remains. Sterling, that's bull - popular perhaps - but still, bull. Zend as a commercial entity doesn't decide on PHP's features. Nobody in Zend has control over the language just because he's a Zend employee. Other Zend employees participate in the discussions just like the rest of you, and often make quite constructive remarks, just like the rest. However, it's not as if Zend employees can muck around the language, whereas php-dev can just stand on the side watching. We all like to look up at corporations, blame them for the problems and rebel. It's basic human nature. It just has very little to do with reality in this case. Nothing, in practice, except for that license everybody enjoys bashing (and I claim again and again, that it won't make a radical change if it changes, except for perception). Andi and myself regulate the engine, on a personal basis, since 1997, and it has nothing to do with Zend (which was founded towards the end of 1999). Between us, as a commercial entity, nobody could care less whether there are advices, namespaces or how exactly the object model would look like. That's why the situation wouldn't change radically if/when the engine license changes, much like it wasn't any different *before* the engine license was even introduced, in the PHP 3.0 days. Having regulators over the 'kernel' of the project is certainly not very unique to the PHP, and had a significant role in bringing PHP to where it is today, and not where Perl is today, for example. 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 #12757 Updated: utf8_encode doesn't terminate strings with '\0'
ID: 12757
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Strings related
Operating System: any
PHP Version: 4.0.6
New Comment:
Seems like at least some of those have already been
fixed in CVS. Could you check the latest CVS snapshot:
http://snaps.php.net/
--Jani
Previous Comments:
[2001-08-15 05:25:54] [EMAIL PROTECTED]
The enclosed patch fixes the problem.
--- php-4.0.6/ext/xml/xml.c Thu May 24 14:42:12 2001
+++ php-rnyberg/ext/xml/xml.c Wed Aug 15 10:45:03 2001
@@ -494,14 +494,14 @@
if (encoder == NULL) {
/* If no encoder function was specified, return the data as-is.
*/
- newbuf = emalloc(len);
- memcpy(newbuf, s, len);
+ newbuf = emalloc(len + 1);
+ memcpy(newbuf, s, len + 1);
*newlen = len;
return newbuf;
}
/* This is the theoretical max (will never get beyond len * 2 as long
* as we are converting from single-byte characters, though) */
- newbuf = emalloc(len * 4);
+ newbuf = emalloc(len * 4 + 1);
while (pos 0) {
c = encoder ? encoder((unsigned char)(*s)) : (unsigned short)(*s);
if (c 0x80) {
@@ -522,9 +522,10 @@
pos--;
s++;
}
- if (*newlen len * 4) {
- newbuf = erealloc(newbuf, *newlen);
+ if (*newlen len * 4 + 1) {
+ newbuf = erealloc(newbuf, *newlen + 1);
}
+ newbuf[*newlen] = '\0';
return newbuf;
}
/* }}} */
Edit this bug report at http://bugs.php.net/?id=12757edit=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 #12752 Updated: preg_replace eats '$' characters
ID: 12752
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: PCRE related
Operating System: Linux Redhat 7.1
PHP Version: 4.0.6
New Comment:
http://www.php.net/manual/en/function.preg-replace.php
Previous Comments:
[2001-08-15 00:15:08] [EMAIL PROTECTED]
The preg_replace function seems to dissapear '$' characters, and up to two more
numeric characters after it. If the character after the dollar sign is not a number,
it works as expected.
$string = 'sum: {token} pesos.';
$number= '$123,456.78';
$number2='$ 123,456.78';
echo Wrong: .preg_replace(/\{token\}/i,$number,$string);
echo brRight: .preg_replace(/\{token\}/i,$number2,$string);
My configure line:
'./configure' '--with-apxs' '--with-pgsql' '--without-mysql' '--with-openssl'
'--enable-ftp' '--with-gd' '--enable-gd-native-ttf'
Edit this bug report at http://bugs.php.net/?id=12752edit=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 #12758: Segfault in zend_execute_API.c
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.6 PHP Bug Type: Apache related Bug description: Segfault in zend_execute_API.c #0 0x40368d62 in zend_get_executed_lineno () at zend_execute_API.c:239 #1 0x4106f101 in OPArrayHandler (op_array=0x8350284) at asdbg.c:982 #2 0x4036af66 in zend_extension_op_array_handler (extension=0x816ce40, op_array=0x8350284) at zend_opcode.c:270 #3 0x4036a8dd in zend_llist_apply_with_argument (l=0x4053750c, func=0x4036af40 zend_extension_op_array_handler, arg=0x8350284) at zend_llist.c:213 #4 0x4036afd1 in pass_two (op_array=0x8350284) at zend_opcode.c:287 #5 0x4037aec6 in compile_file (file_handle=0xb680, type=2) at zend_language_scanner.c:3049 #6 0x40371c83 in zend_execute_scripts (type=8, file_count=3) at zend.c:749 #7 0x403845a4 in php_execute_script (primary_file=0xb680) at main.c:1206 #8 0x40380880 in apache_php_module_main (r=0x81764e4, display_source_mode=0) at sapi_apache.c:89 #9 0x403812c1 in send_php (r=0x81764e4, display_source_mode=0, filename=0x0) at mod_php4.c:536 #10 0x40381303 in send_parsed_php (r=0x81764e4) at mod_php4.c:547 #11 0x80554f9 in ap_invoke_handler () at md4.c:255 #12 0x806a4ef in process_request_internal () at md4.c:255 #13 0x806a55a in ap_process_request () at md4.c:255 #14 0x8061376 in child_main () at md4.c:255 #15 0x8061551 in make_child () at md4.c:255 #16 0x80616cc in startup_children () at md4.c:255 #17 0x8061d3c in standalone_main () at md4.c:255 #18 0x806258c in main () at md4.c:255 #19 0x40097cae in __libc_start_main () at md4.c:255 I recently started working on an old site, and tried to access it on my development environment (sepearate apache installation) and get segfaults. The site does use phplib/postgres. If I comment out the autoprepend for the phplib stuff, I don't get the segfault (just a useless site) Thanks, -Rob -- Edit bug report at: http://bugs.php.net/?id=12758edit=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] Please..
On Wed, 15 Aug 2001, Jani Taskinen wrote: Can you guys give up these childish fights and just code? Telling people to just shut up will not resolve the issues which many of us think have to be addressed (regardless of how profane your language becomes). It is very unlikely that the bickering will stop, if a single company continues to exercise so much control over the future of an open system such as PHP. - 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] Please..
At 13:06 15-08-01, Jani Taskinen wrote: p.s. Zeev, did you forget to tag the Zend / TSRM for 4.0.7 ?? Nah, I even did that last night at 2am... But I got a bug report in the CGI that required fixing, and there's some COM patch that should go in before RC1, so RC1 will be delayed in a few hours... 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] Please..
At 13:13 15-08-01, Sascha Schumann wrote: On Wed, 15 Aug 2001, Jani Taskinen wrote: Can you guys give up these childish fights and just code? Telling people to just shut up will not resolve the issues which many of us think have to be addressed (regardless of how profane your language becomes). It is very unlikely that the bickering will stop, if a single company continues to exercise so much control over the future of an open system such as PHP. If you feel like bickering, go on bicker and make populist statements as much as you'd like, just let the rest of us do what we're good at, which is developing PHP. Perhaps setting up a separate mailing list like Sterling suggested, a-la [EMAIL PROTECTED] isn't such a bad idea. 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 #12760: The uploaded image are not available.
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.6 PHP Bug Type: *Directory/Filesystem functions Bug description: The uploaded image are not available. I am not sure about the PHP version of by hosting. I use script of upload in my website. The upload is OK : the file is in my server but, when I want to open and read the image file (jpeg or gif), the image is not available. When I open the file in a text editor, I notice that the file in my server containt 2 lines, in the top of the file, not present in the original file : - first line : Content-Type: image/jpeg (for a jpeg file) - second line : a blank line I have not this problem in my development server (a NT server). Thanks to your help. Cohen Jean-Claude -- Edit bug report at: http://bugs.php.net/?id=12760edit=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 #12758 Updated: Segfault in zend_execute_API.c
ID: 12758 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: Linux PHP Version: 4.0.6 New Comment: The segfault only occurs if the file is auto_prepend'ed from a .htaccess file if the file is just included, it works fine. This is the line I am using in my .htaccess php_value auto_prepend_file tracker_prepend.php Previous Comments: [2001-08-15 05:59:49] [EMAIL PROTECTED] #0 0x40368d62 in zend_get_executed_lineno () at zend_execute_API.c:239 #1 0x4106f101 in OPArrayHandler (op_array=0x8350284) at asdbg.c:982 #2 0x4036af66 in zend_extension_op_array_handler (extension=0x816ce40, op_array=0x8350284) at zend_opcode.c:270 #3 0x4036a8dd in zend_llist_apply_with_argument (l=0x4053750c, func=0x4036af40 zend_extension_op_array_handler, arg=0x8350284) at zend_llist.c:213 #4 0x4036afd1 in pass_two (op_array=0x8350284) at zend_opcode.c:287 #5 0x4037aec6 in compile_file (file_handle=0xb680, type=2) at zend_language_scanner.c:3049 #6 0x40371c83 in zend_execute_scripts (type=8, file_count=3) at zend.c:749 #7 0x403845a4 in php_execute_script (primary_file=0xb680) at main.c:1206 #8 0x40380880 in apache_php_module_main (r=0x81764e4, display_source_mode=0) at sapi_apache.c:89 #9 0x403812c1 in send_php (r=0x81764e4, display_source_mode=0, filename=0x0) at mod_php4.c:536 #10 0x40381303 in send_parsed_php (r=0x81764e4) at mod_php4.c:547 #11 0x80554f9 in ap_invoke_handler () at md4.c:255 #12 0x806a4ef in process_request_internal () at md4.c:255 #13 0x806a55a in ap_process_request () at md4.c:255 #14 0x8061376 in child_main () at md4.c:255 #15 0x8061551 in make_child () at md4.c:255 #16 0x80616cc in startup_children () at md4.c:255 #17 0x8061d3c in standalone_main () at md4.c:255 #18 0x806258c in main () at md4.c:255 #19 0x40097cae in __libc_start_main () at md4.c:255 I recently started working on an old site, and tried to access it on my development environment (sepearate apache installation) and get segfaults. The site does use phplib/postgres. If I comment out the autoprepend for the phplib stuff, I don't get the segfault (just a useless site) Thanks, -Rob Edit this bug report at http://bugs.php.net/?id=12758edit=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] Please..
On Wed, 15 Aug 2001, Jani Taskinen wrote: Instead of continuing this endless thread, do something useful once and go fix some bugs.. Jani, try to chill.. - 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] Please..
If you feel like bickering, go on bicker and make populist statements as much as you'd like, just let the rest of us do what we're good at, which is developing PHP. Perhaps setting up a separate mailing list like Sterling suggested, a-la [EMAIL PROTECTED] isn't such a bad idea. Thanks for proving that you are not interested in a dialogue. That is the usual problem of people who are in charge and who just get too used to their power that the concept of releasing some of their power is too remote to be even considerable. - 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] Please..
Jani Taskinen wrote: Can you guys give up these childish fights and just code? These are not childish fights. And I assume there are some people out there, just like Sascha and Thies, who are waiting to code and contribute the Zend Engine, once the license gets changed. But chaning the license is only one step that Andi and Zeev need to take, IMHO. A second one would be documenting the Zend Engine's internals. And this can only be done properly by Andi and Zeev, since they planned and coded it. Looking at zend_compile.c and zend_execute.c today just gives me the creeps, from a software developer's view: nearly no comments. Of course, I can guess what is done where, since I know a bit on compiler theory. But with a proper documentation, people like Sascha and Thies could start with their work on the engine right away -- without learning (by guessing) how the Zend Engine actually does what it does. While the Zend API could easily be documented, or updated from what's in ZendAPI on cvs.zend.com, from any developer who wrote some PHP extensions, the documentation of the Zend Engine itself and its internals can IMHO only be done by its creators. Haven't you get any pussy lately or what? And this isn't childish now, is it? -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12761: ereg and preg problems
From: [EMAIL PROTECTED]
Operating system: win me/freebsd
PHP version: 4.0.6
PHP Bug Type: Output Control
Bug description: ereg and preg problems
$data = eregi_replace((.*), prodwebsearch('\\1'), $data);
function prodwebsearch($search) {
# here search is fine
# search = ultra 5
return prodsearch($search);
}
function prodsearch($search) {
#here its not
# search = \1
return $search;
}
(this is just an example)
why does $search change to \1?
--
Edit bug report at: http://bugs.php.net/?id=12761edit=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] Please..
Hi, First of all, in the last couple of days I have seen a number of very unconstructive mails being fired off, these simply seem to be people bitching rather than trying to write in a precise and concise way, what their problem is. It is correct that telling people to shut up won't resolve the issue, but apparently theres no agreement on what the issue is. Within the last couple of days there has been a number of different issues all being related to some people fearing that Zend controlling the engine being used in PHP will mean the end of PHP (or something). Does Zend really have control over PHP, and thereby the PHP core language. According to the grant that Zend gave to the PHP Group [1] it says that if PHP decides to modify the ZendEngine (ZE), it has to be done under the QPL 1.0 -- this means that (AFAIK and I am NOT a lawyer) IF there are modifications to the ZE, these MAY be freely distributed as long as the patch/modifications are available to Zend (which they would be anyway since PHP is governed by the PHP OSL) and that we do not modify the license that the ZE is released under. For me this means that no matter what happens to Zend, the PHP Group can, if it wishes to do so, continue to develop the ZE without any restrictions except to keep the ZE under the license that it is currently under, am I missing something? Besides the QPL is (again AFAIK) defined as OpenSource, which garantees us that we can continue to work on it, no matter what Zend decides in the future [2]. So what control does Zend really have? They contribute to the development of PHP with the engine, freely, and generally have also made some of the modules for PHP, and under their license we can still modifyredistribute ZE, and if this is not in PHPs interest then frankly, I don't know what is. Is ZE not an integral part of PHP, because if it isn't, then we have a problem because PHP relies on it, now on the other hand if ZE is a part of PHP why do we need an abstraction layer, doesn't that just tell the folks over at Zend, that: 1) we don't like them. 2) we'd rather have someone else make the engine because we are troubled by license/control/... And if its 2), then let us write exactly what the problem is. Now what is really the issue? HTH. Kind regards, David. [1] Zend Grant: http://www.php.net/license/ZendGrant [2] OSD Definition: http://www.opensource.org/docs/definition_plain.html -- PHP Development Mailing List http://www.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 #12761 Updated: ereg and preg problems
ID: 12761
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Output Control
Operating System: win me/freebsd
PHP Version: 4.0.6
New Comment:
This is no bug (As discussed on #Php).
Derick
Previous Comments:
[2001-08-15 06:50:47] [EMAIL PROTECTED]
$data = eregi_replace((.*), prodwebsearch('\\1'), $data);
function prodwebsearch($search) {
# here search is fine
# search = ultra 5
return prodsearch($search);
}
function prodsearch($search) {
#here its not
# search = \1
return $search;
}
(this is just an example)
why does $search change to \1?
Edit this bug report at http://bugs.php.net/?id=12761edit=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 #12762: nl2br -- Converts newlines to HTML line breaks
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.0.6
PHP Bug Type: Unknown/Other Function
Bug description: nl2br -- Converts newlines to HTML line breaks
?
$test = fopen(test1.txt, r) or die(unable to open file);
while (!feof($test))
{
$line = fgets($test, 1024);
$line = nl2br($line);
print $line;
}
?
contents of file test1.txt:
test
test
test
In HTML:
testbr /
testbr /
testbr /
That is to say br / instead of br
--
Edit bug report at: http://bugs.php.net/?id=12762edit=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 #12762 Updated: nl2br -- Converts newlines to HTML line breaks
ID: 12762
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Linux
PHP Version: 4.0.6
New Comment:
This is intended. Search the bug db for better explanation..and read the
bugs-dos-and-donts next time
BEFORE submitting bug reports.
Previous Comments:
[2001-08-15 07:25:51] [EMAIL PROTECTED]
?
$test = fopen(test1.txt, r) or die(unable to open file);
while (!feof($test))
{
$line = fgets($test, 1024);
$line = nl2br($line);
print $line;
}
?
contents of file test1.txt:
test
test
test
In HTML:
testbr /
testbr /
testbr /
That is to say br / instead of br
Edit this bug report at http://bugs.php.net/?id=12762edit=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 #12760 Updated: The uploaded image are not available.
ID: 12760 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: *Directory/Filesystem functions Operating System: Linux PHP Version: 4.0.6 New Comment: Ask your service provider to update the PHP to 4.0.6. This is fixed. --Jani Previous Comments: [2001-08-15 06:14:03] [EMAIL PROTECTED] I am not sure about the PHP version of by hosting. I use script of upload in my website. The upload is OK : the file is in my server but, when I want to open and read the image file (jpeg or gif), the image is not available. When I open the file in a text editor, I notice that the file in my server containt 2 lines, in the top of the file, not present in the original file : - first line : Content-Type: image/jpeg (for a jpeg file) - second line : a blank line I have not this problem in my development server (a NT server). Thanks to your help. Cohen Jean-Claude Edit this bug report at http://bugs.php.net/?id=12760edit=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 #12763: No GIF support in this PHP build in
From: [EMAIL PROTECTED] Operating system: WIN NT 4.0 sp 6 PHP version: 4.0.5 PHP Bug Type: GD related Bug description: No GIF support in this PHP build in I have iis and instal php 4.0.5 When I run my php flle my ie5 print me: ImageGif: No GIF support in this PHP build in What is a problem? Your Konrad ? Header (Content-type: image/gif); dl(extensions/php_gd.dll); $img = ImageCreate (250 ,250); $czarny = Imagecolorallocate($img, 0, 0, 0); $bialy = Imagecolorallocate($img, 225, 225, 225); imagefill ($img, 0, 0, $czarny); imageline ($img, 0, 0, 250, 250, $bialy); imageline ($img, 250, 0, 0, 250, $bialy); Imagegif ($img); imagedestroy ($img); ? -- Edit bug report at: http://bugs.php.net/?id=12763edit=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 #12764: php4isapi.dll module clashes with exchange server
From: [EMAIL PROTECTED] Operating system: WIN2000 5.00.2195 service pac 2 PHP version: 4.0.6 PHP Bug Type: IIS related Bug description: php4isapi.dll module clashes with exchange server Runing an IIS server, it seams like the php4isapi.dll module interfears with the Exchange server on the same machine. PHP also seams to encounter several acces-violations randomly during runtime. The errorlogg on the machine shows (from startup): A fatal error occurred while creating an SSL server credential The errorlogg on the machine shows (during IIS failiure): The HTTP server encountered an unhandled exception while processing the ISAPI Application ' php4ts!hashpjw + 0x13 + 0xA05E5983 '. We are possitive that it's the module causing the problem since when the IIS runs the CGI version everything works perfectly (except from the header function, wich we require). The module is not installed as a filter, only as an ISAPI application. would be thankfull for anny help! -- Edit bug report at: http://bugs.php.net/?id=12764edit=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 #12759: What's new
From: [EMAIL PROTECTED] Operating system: PHP version: 4.0.6 PHP Bug Type: Documentation problem Bug description: What's new I have a suggestion which could make the PHP documentation even easier to use for the experienced PHP programmer. As can easily observed, you guys keep up the documentation very quickly to the new versions. One thing I miss though is a way of quickly finding out where the *documentation* has changed from one PHP release to the next. Maybe you could have a New in x.y.z and/or Changed in x.y.z section. I guess that there would be a way of rather easily auto-creating those indexes from the present documentation. I'll give two examples to illustrate. From browsing the manual I found out today that one is not encouraged to use mysql_db_query from 4.0.6. Another example is the function mysql_unbuffered_query, which I found out about somewhere at zend.com. By quickly having an overview over new and changed information, PHP programmers could more easily adopt their scripts to new versions. Stefan -- Edit bug report at: http://bugs.php.net/?id=12759edit=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 #12750 Updated: No echo call in example code
ID: 12750
Updated by: goba
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Documentation problem
Operating System: N/A
PHP Version: 4.0.6
New Comment:
You are right. Echo is added now. Thanks for the spot.
Goba
Previous Comments:
[2001-08-14 22:34:31] [EMAIL PROTECTED]
On the manual page:
http://www.php.net/manual/en/language.oop.constructor.php
The following code lacks an echo in function C (shown in square brackets).
---
class A {
function A() {
echo I am the constructor of A.br\n;
}
}
class B extends A {
function C() {
[should have echo here?] I am a regular function.br\n;
}
}
// no constructor is being called in PHP 3.
$b = new B;
Edit this bug report at http://bugs.php.net/?id=12750edit=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 #12763 Updated: No GIF support in this PHP build in
ID: 12763 Updated by: cynic Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: GD related Operating System: WIN NT 4.0 sp 6 PHP Version: 4.0.5 New Comment: GIF images are no longer supported in GD. Patent issues. Previous Comments: [2001-08-15 07:51:27] [EMAIL PROTECTED] I have iis and instal php 4.0.5 When I run my php flle my ie5 print me: ImageGif: No GIF support in this PHP build in What is a problem? Your Konrad ? Header (Content-type: image/gif); dl(extensions/php_gd.dll); $img = ImageCreate (250 ,250); $czarny = Imagecolorallocate($img, 0, 0, 0); $bialy = Imagecolorallocate($img, 225, 225, 225); imagefill ($img, 0, 0, $czarny); imageline ($img, 0, 0, 250, 250, $bialy); imageline ($img, 250, 0, 0, 250, $bialy); Imagegif ($img); imagedestroy ($img); ? Edit this bug report at http://bugs.php.net/?id=12763edit=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 #12757 Updated: utf8_encode doesn't terminate strings with '\0'
ID: 12757
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Strings related
Operating System: any
PHP Version: 4.0.6
New Comment:
It's fixed in one place, but it still doesn't set the trailing '\0'
if encoder == NULL, if I understand it correctly.
-Richard
Previous Comments:
[2001-08-15 05:44:25] [EMAIL PROTECTED]
Seems like at least some of those have already been
fixed in CVS. Could you check the latest CVS snapshot:
http://snaps.php.net/
--Jani
[2001-08-15 05:25:54] [EMAIL PROTECTED]
The enclosed patch fixes the problem.
--- php-4.0.6/ext/xml/xml.c Thu May 24 14:42:12 2001
+++ php-rnyberg/ext/xml/xml.c Wed Aug 15 10:45:03 2001
@@ -494,14 +494,14 @@
if (encoder == NULL) {
/* If no encoder function was specified, return the data as-is.
*/
- newbuf = emalloc(len);
- memcpy(newbuf, s, len);
+ newbuf = emalloc(len + 1);
+ memcpy(newbuf, s, len + 1);
*newlen = len;
return newbuf;
}
/* This is the theoretical max (will never get beyond len * 2 as long
* as we are converting from single-byte characters, though) */
- newbuf = emalloc(len * 4);
+ newbuf = emalloc(len * 4 + 1);
while (pos 0) {
c = encoder ? encoder((unsigned char)(*s)) : (unsigned short)(*s);
if (c 0x80) {
@@ -522,9 +522,10 @@
pos--;
s++;
}
- if (*newlen len * 4) {
- newbuf = erealloc(newbuf, *newlen);
+ if (*newlen len * 4 + 1) {
+ newbuf = erealloc(newbuf, *newlen + 1);
}
+ newbuf[*newlen] = '\0';
return newbuf;
}
/* }}} */
Edit this bug report at http://bugs.php.net/?id=12757edit=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] Please..
At 13:43 15-08-01, Sebastian Bergmann wrote: Jani Taskinen wrote: Can you guys give up these childish fights and just code? These are not childish fights. Yes they are. They are on childish topics, lead nowhere and consume lots of our time. And I assume there are some people out there, just like Sascha and Thies, who are waiting to code and contribute the Zend Engine, once the license gets changed. You have absolutely no reason to assume that this is the case, except for the license noise that was spawned by the same people who spawn these pointless threads on php-dev. I believe Hartmut will help documenting the API, but that's about it. But chaning the license is only one step that Andi and Zeev need to take, IMHO. A second one would be documenting the Zend Engine's internals. And this can only be done properly by Andi and Zeev, since they planned and coded it. Looking at zend_compile.c and zend_execute.c today just gives me the creeps, from a software developer's view: nearly no comments. Of course, I can guess what is done where, since I know a bit on compiler theory. But with a proper documentation, people like Sascha and Thies could start with their work on the engine right away -- without learning (by guessing) how the Zend Engine actually does what it does. While the Zend API could easily be documented, or updated from what's in ZendAPI on cvs.zend.com, from any developer who wrote some PHP extensions, the documentation of the Zend Engine itself and its internals can IMHO only be done by its creators. With all due respect, 'you get what you pay for' works as far as documentation goes in open source. Fact is, we don't *need* to do *anything*. Nobody in an opensource project does. What we do we do because it's fun (which these threads do a good job of ruining) and because it's interesting. Not because we have to do it. I never liked writing documentation. I don't think that developers in most other opensource projects are significantly different, neither are most of the other developers in the PHP circle (it's not as if the rest of PHP is too documented... Where are the SAPI docs, or the fopen wrappers docs, or the session docs?). Try to understand the Perl source code, for example. For me, things work just fine the way they are, and I'm not searching for extra stuff to do. If somebody finds the entry level too steep to contribute to the engine, by all means, either try to document it, or go away. Don't say that I *have* to do it, because I don't. Sorry for the somewhat aggressive tone, but it's kind of annoying to see people demanding things from you, when you're a volunteer. 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] Please..
At 13:41 15-08-01, Sascha Schumann wrote: If you feel like bickering, go on bicker and make populist statements as much as you'd like, just let the rest of us do what we're good at, which is developing PHP. Perhaps setting up a separate mailing list like Sterling suggested, a-la [EMAIL PROTECTED] isn't such a bad idea. Thanks for proving that you are not interested in a dialogue. If bickering is your definition of dialogue then all I can say is - you're quite welcome! 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 #12765: Bug with inserting NULLs using ibase_prepare()/ibase_execute()
From: [EMAIL PROTECTED]
Operating system: Windows 2000 Server
PHP version: 4.0.6
PHP Bug Type: InterBase related
Bug description: Bug with inserting NULLs using ibase_prepare()/ibase_execute()
Environment:
- Windows 2000 Server
- Apache v1.3.20 (binaries from www.apache.org)
- PHP v4.0.6 (binaries from www.php.net)
- InterBase v6.0.0.627 (binaries from www.borland.com)
1. Let's create very simple database:
-
CREATE DATABASE 'c:\db\test.gdb'
USER 'user' PASSWORD 'password';
CREATE TABLE TEST_TABLE (
INT_VALUE INTEGER,
STR_VALUE VARCHAR(50));
COMMIT WORK;
-
2. Create very simple PHP script:
-
?php
$ib = ibase_connect('c:\db\test.gdb','user','password');
$query = ibase_prepare($ib,'insert into TEST_TABLE_2(INT_VALUE, STR_VALUE)
values (?, ?)');
$rs = ibase_execute($query,1,null);
ibase_close($ib);
?
-
After this script will be executed, TEST_TABLE table will contain a row
with STR_VALUE='' instead of NULL!
However inserting the same data through ibase_query() works properly.
--
Edit bug report at: http://bugs.php.net/?id=12765edit=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] Please..
At 13:53 15-08-01, David Hjortsoe wrote: For me this means that no matter what happens to Zend, the PHP Group can, if it wishes to do so, continue to develop the ZE without any restrictions except to keep the ZE under the license that it is currently under, am I missing something? The only thing you're missing is the point of these threads. They have very little to do with the situation itself, and everything to do with politics. If, God forbid, you only look at the facts - then you're not missing anything. Thanks for providing a rational look! 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] Re: Bug #12745: problem with the randomic generation of salt when a use crypt(pass)
der
I supose that is must not work but works, did you tested ?
- Original Message -
From: PHP Bug Database [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 14, 2001 8:40 PM
Subject: Bug #12745: problem with the randomic generation of salt when a use
crypt(pass)
From: [EMAIL PROTECTED]
Operating system: Linux Slackware 7.1
PHP version: 4.0.6
PHP Bug Type: *Encryption and hash functions
Bug description: problem with the randomic generation of salt when a use
crypt(pass)
problem with the randomic generation of salt when a use $string =
crypt(11lei11lao11) it allways generates a salt ( the first 2 chars from
encrypted string ) that if use crypt(11lei11lao11blablabla) would work,
and also crypt(11lei11lao11anythingwouldworkhere).
the code is
$cryptedpass = crypt(11lei11lao11);
if (crypt ( 11lei11lao11anythingwouldworkhere, substr ( $cryptedpass, 0,
2)) == $cryptedpass) {
echo this is extremely strange for me;
}
and this works with this pass but not whit others!
--
Edit bug report at: http://bugs.php.net/?id=12745edit=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 #12635 Updated: href=#botton gives wrong url
ID: 12635 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: ? PHP Version: 4.0.4 New Comment: You are right that there is no bug so far as concerns the position of #bottom. I tried with Explorer 4.5: link no 1, 2 and 4 are OK, but still the page is reloaded. With Netscape 4.6 the first link does not work. Maybe it also depends on the reload preferences of the navigator. So all this is rather tricky, isn't it ? But what about the following suggestion: php could refrain from inserting the session_id if the link contains only an anchor (like: href=#bottom), because this means that the page is not to be reload. Previous Comments: [2001-08-13 15:45:13] [EMAIL PROTECTED] Sorry, I put protection 777, but that was too much. Now it should work : http://webcour.swisszone.ch/a/essais/session.php?f=1 [2001-08-12 19:59:47] [EMAIL PROTECTED] Works correctly (that #bottom is left alone) since oktober 2000 (version 1.17 of ext/standard/url_scanner_ex.re) That means it worked since 4.0.4 exactly. (I only tested 4.0.7, so I'm not 100% certain) And I was correct that # came _after_ the ?, so there's no bug (anymore). [2001-08-12 18:11:48] [EMAIL PROTECTED] http://webcour.swisszone.ch/a/essais/session.php?f=1 Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, root@localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request. Apache/1.3.14 Server at www.webcour.swisszone.ch Port 80 [2001-08-11 17:53:17] [EMAIL PROTECTED] Try the following file: http://webcour.swisszone.ch/a/essais/session.php?f=1 [2001-08-09 17:32:05] [EMAIL PROTECTED] It should, or am I wrong? the ?-part is of the page-part of it, and the # is for the section. Doesn't ? go BEFORE the # in HTTP-specs? Can someone verify that, since I 'forgot' the RFC-nr ;-) Since PHP is inserting it between, I'm quite sure it should go before, otherwise the person who wrote it wouldn't have taken the trouble to do so :) Does your browser have problems with that? 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=12635 Edit this bug report at http://bugs.php.net/?id=12635edit=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 #12764 Updated: php4isapi.dll module clashes with exchange server
ID: 12764 Updated by: phildriscoll Reported By: [EMAIL PROTECTED] Old Status: Open Status: Duplicate Bug Type: IIS related Operating System: WIN2000 5.00.2195 service pac 2 PHP Version: 4.0.6 New Comment: As it says in the PHP installation notes, the ISAPI module is not stable. When it goes wrong it can bring down the whole of IIS. Your best bet is to either use the cgi version which is rock solid, though with a slight performance penalty, or if you can, switch from IIS to Apache and run the Apache Module. Previous Comments: [2001-08-15 07:52:08] [EMAIL PROTECTED] Runing an IIS server, it seams like the php4isapi.dll module interfears with the Exchange server on the same machine. PHP also seams to encounter several acces-violations randomly during runtime. The errorlogg on the machine shows (from startup): A fatal error occurred while creating an SSL server credential The errorlogg on the machine shows (during IIS failiure): The HTTP server encountered an unhandled exception while processing the ISAPI Application ' php4ts!hashpjw + 0x13 + 0xA05E5983 '. We are possitive that it's the module causing the problem since when the IIS runs the CGI version everything works perfectly (except from the header function, wich we require). The module is not installed as a filter, only as an ISAPI application. would be thankfull for anny help! Edit this bug report at http://bugs.php.net/?id=12764edit=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] libmysql and MS Visual Studio .NET
Hi! As this isn't a php problem, please post any answer only to the [EMAIL PROTECTED] list. Sebastian == Sebastian Bergmann [EMAIL PROTECTED] writes: Sebastian Hi, Sebastian while cleaning up my room today I found my copy of the MS Visual Sebastian Studio .NET Beta 1 again. Since I was a little bored I installed Sebastian it and tried again to build PHP 4 with it. Sebastian It still chokes on the strtoll.c file. I wonder if someone else Sebastian has tried to build PHP (or MySQL) with this next version of the Sebastian standard Win32 compiler. Sebastian Have a look at Sebastian http://www.sebastian-bergmann.de/libmysql.htm Sebastian for the exact error messages. Sorry, I only own the german Sebastian version of Visual Studio. Sebastian Note: This is currently not important, but better support it Sebastian sooner than later, I think. I have compiled MySQL with Visual Studio 6, so this should work... It's strange that strtoull.c compiles but not strtoll.c, as they both include the same include files and is basicly the same source. Could you email the lines 380-445 from .NET\Vc7\include\winnt.h so that I can take a look at this. Regards, Monty -- PHP Development Mailing List http://www.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] CVS Account Request
Full name: Vincent Blavet Email: [EMAIL PROTECTED] ID:vblavet Purpose: Adding a class Archive_Tar in the experimental part of PEAR. Stig Bakken is aware of this request. -- PHP Development Mailing List http://www.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] Please..
Zeev Suraski wrote: Don't say that I *have* to do it, because I don't. I didn't say that you have to do it. What I meant to make clean was that the best choice of authors for a documentation of a piece of software like the Zend Engine are its inventors. With the Zend Engine this happens to be you and Andi. I did not _demand_ this from you. -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12766: easter_days breaks for year before 1753
From: [EMAIL PROTECTED]
Operating system: Linux 2.4.x
PHP version: 4.0.6
PHP Bug Type: Calendar related
Bug description: easter_days breaks for year before 1753
The easter_days function returns bad data for years = 1752. Here is a way
to verify. Because Easter always falls on a Sunday, the following function
should always return Sunday:
function EasterDOW($year) {
$jdayc = easter_days($year);
$jdmar21 = gregoriantojd(3, 21, $year);
$jdeaster = $jdmar21 + $jdayc;
return JDDayOfWeek($jdeaster, 1);
}
The formula for calculating easter has been the same since 1582. The
standerd Delambre Easter algorithm is able to generate the date of easter
for any gregorian date after 1582. The following function may be used to
duplicate the functionality of easter_days for any date since 1582:
function easter_days2($year) {
#First calculate the date of easter using
#Delambre's algorithm.
$a = $year % 19;
$b = floor($year / 100);
$c = $year % 100;
$d = floor($b / 4);
$e = $b % 4;
$f = floor(($b + 8) / 25);
$g = floor(($b - $f + 1) / 3);
$h = (19 * $a + $b - $d - $g + 15) % 30;
$i = floor($c / 4);
$k = $c % 4;
$l = (32 + 2 * $e + 2 * $i - $h - $k) % 7;
$m = floor(($a + 11 * $h + 22 * $l) / 451);
$n = ($h + $l - 7 * $m + 114);
$month = floor($n / 31);
$day = $n % 31 + 1;
#Return the difference between the JulianDayCount
#for easter and March 21'st of the same year,
#in order to duplicate the functionality of the
#easter_days function
return GregorianToJD($month, $day, $year) -
GregorianToJD(3,21,$year);
}
--
Edit bug report at: http://bugs.php.net/?id=12766edit=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] SAPI_API glitch
hi currently if extensions want to define their own SAPI_POST_*_FUNC (fdf, mbstring) they'll run into trouble, because they are defined as 'SAPI_API void ... my_handler'. this however doesn't work, because you'll need to define SAPI_EXPORTS (to export it) and are thus loosing the sapi_globals_id (which must be imported). nuking SAPI_API from the macro, and using (SAPI_API || PHP_EXT_API) SAPI_POST_*_FUNC would avoid this glitch. anyone objects? daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Bug #12745: problem with the randomic generation of salt when a use crypt(pass)
Not a bug in PHP. Verified with htpasswd (couldn't get a simple
crypt-demonstration-script working :-)
$ ./htpasswd -d -nb test 11lei11lao11
returned test:Au7LW/UPElj0c
$ ./htpasswd -d -nb test 11lei11lao11whatever
returned test:Au7LW/UPElj0c
I guess it's a bug (or an undocumented behaviour) of the crypt()-algoritm.
The problem is not the random salt. The problem seems to be that crypt (at
least, in this case) only uses the first 12 characters (or less).
Sander
- Original Message -
From: Marcus Vinicius [EMAIL PROTECTED]
To: PHP Bug Database [EMAIL PROTECTED]
Sent: Wednesday, August 15, 2001 2:31 PM
Subject: [PHP-DEV] Re: Bug #12745: problem with the randomic generation of
salt when a use crypt(pass)
der
I supose that is must not work but works, did you tested ?
- Original Message -
From: PHP Bug Database [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 14, 2001 8:40 PM
Subject: Bug #12745: problem with the randomic generation of salt when a
use
crypt(pass)
From: [EMAIL PROTECTED]
Operating system: Linux Slackware 7.1
PHP version: 4.0.6
PHP Bug Type: *Encryption and hash functions
Bug description: problem with the randomic generation of salt when a
use
crypt(pass)
problem with the randomic generation of salt when a use $string =
crypt(11lei11lao11) it allways generates a salt ( the first 2 chars
from
encrypted string ) that if use crypt(11lei11lao11blablabla) would
work,
and also crypt(11lei11lao11anythingwouldworkhere).
the code is
$cryptedpass = crypt(11lei11lao11);
if (crypt ( 11lei11lao11anythingwouldworkhere, substr ( $cryptedpass,
0,
2)) == $cryptedpass) {
echo this is extremely strange for me;
}
and this works with this pass but not whit others!
--
Edit bug report at: http://bugs.php.net/?id=12745edit=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]
Re: [PHP-DEV] Setting up RFC
On Wed, 15 Aug 2001, Zeev Suraski wrote: like. That's why the situation wouldn't change radically if/when the engine license changes, much like it wasn't any different *before* the engine license was even introduced, in the PHP 3.0 days. Having regulators over the 'kernel' of the project is certainly not very unique to the PHP, and had a significant role in bringing PHP to where it is today, and not where Perl is today, for example. You always compare PHP to Perl. How about Python? It's a well designed language that's pretty open for development.. Look at their PEPs system. -Andrei In this age, which believes that there is a short cut to everything, the greatest lesson to be learned is that the most difficult way is, in the long run, the easiest. -Henry Miller, The Books in My Life -- PHP Development Mailing List http://www.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 #12767: Apache compile with php4.0.6
From: [EMAIL PROTECTED] Operating system: AIX 4.3.3.0 PHP version: 4.0.6 PHP Bug Type: *Compile Issues Bug description: Apache compile with php4.0.6 Whenever I try to compile Apache server 1.3.20 including the libphp4.a module, make crashes with a code 8. It compiles just fine if I don't include the php directive. It is complaining about .alloc symbol. -- Edit bug report at: http://bugs.php.net/?id=12767edit=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] Setting up RFC
At 18:13 15-08-01, Andrei Zmievski wrote: On Wed, 15 Aug 2001, Zeev Suraski wrote: like. That's why the situation wouldn't change radically if/when the engine license changes, much like it wasn't any different *before* the engine license was even introduced, in the PHP 3.0 days. Having regulators over the 'kernel' of the project is certainly not very unique to the PHP, and had a significant role in bringing PHP to where it is today, and not where Perl is today, for example. You always compare PHP to Perl. How about Python? It's a well designed language that's pretty open for development.. Look at their PEPs system. And you always compare to Python :) I try to compare apples and apples. I don't see Python as an equivalent of PHP, whereas I do see Perl as something that had to potential to be a good thing, and blew it. There are also many other, non-language examples, of opensource projects that work in the same way. 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] SAPI_API glitch
Is there any reason to have them even exported? I think we can just nuke SAPI_API altogether (I could be wrong, we might be referencing them somewhere, but I don't think we do) At 17:58 15-08-01, Daniel Beulshausen wrote: hi currently if extensions want to define their own SAPI_POST_*_FUNC (fdf, mbstring) they'll run into trouble, because they are defined as 'SAPI_API void ... my_handler'. this however doesn't work, because you'll need to define SAPI_EXPORTS (to export it) and are thus loosing the sapi_globals_id (which must be imported). nuking SAPI_API from the macro, and using (SAPI_API || PHP_EXT_API) SAPI_POST_*_FUNC would avoid this glitch. anyone objects? daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- 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] SAPI_API glitch
At 18:20 15.08.2001 +0300, Zeev Suraski wrote: Is there any reason to have them even exported? I think we can just nuke SAPI_API altogether (I could be wrong, we might be referencing them somewhere, but I don't think we do) not sure, but we can add it later if it breaks :) daniel At 17:58 15-08-01, Daniel Beulshausen wrote: hi currently if extensions want to define their own SAPI_POST_*_FUNC (fdf, mbstring) they'll run into trouble, because they are defined as 'SAPI_API void ... my_handler'. this however doesn't work, because you'll need to define SAPI_EXPORTS (to export it) and are thus loosing the sapi_globals_id (which must be imported). nuking SAPI_API from the macro, and using (SAPI_API || PHP_EXT_API) SAPI_POST_*_FUNC would avoid this glitch. anyone objects? daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] SAPI_API glitch
At 17:36 15.08.2001 +0200, Daniel Beulshausen wrote: At 18:20 15.08.2001 +0300, Zeev Suraski wrote: Is there any reason to have them even exported? I think we can just nuke SAPI_API altogether (I could be wrong, we might be referencing them somewhere, but I don't think we do) not sure, but we can add it later if it breaks :) no i just looked, they are (i.e. sapi_read_standard_form_data in the fdf extension) daniel daniel At 17:58 15-08-01, Daniel Beulshausen wrote: hi currently if extensions want to define their own SAPI_POST_*_FUNC (fdf, mbstring) they'll run into trouble, because they are defined as 'SAPI_API void ... my_handler'. this however doesn't work, because you'll need to define SAPI_EXPORTS (to export it) and are thus loosing the sapi_globals_id (which must be imported). nuking SAPI_API from the macro, and using (SAPI_API || PHP_EXT_API) SAPI_POST_*_FUNC would avoid this glitch. anyone objects? daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Setting up RFC
Hi Andrei! On Wed, 15 Aug 2001, Andrei Zmievski wrote: On Wed, 15 Aug 2001, Zeev Suraski wrote: like. That's why the situation wouldn't change radically if/when the engine license changes, much like it wasn't any different *before* the engine license was even introduced, in the PHP 3.0 days. Having regulators over the 'kernel' of the project is certainly not very unique to the PHP, and had a significant role in bringing PHP to where it is today, and not where Perl is today, for example. You always compare PHP to Perl. How about Python? It's a well designed language that's pretty open for development.. Look at their PEPs system. maybe cause PHP it's better than Perl but not than Python? :) -- teodor -- PHP Development Mailing List http://www.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] Console Work
Hi there, I'm new to the list (only subscribed 2 mins ago!). I have subscribed a) to say bloody well done on a great language! and b) I am trying to find information on a few things related to console php (php -q)... First off, I wrote a small addition to ext/standard/exec.c that adds a fork () function. I haven't been testing it much yet (I've started to write a web server in it to see how well it works), but was wondering, is there a reason why the official PHP 4 currently lacks fork functionality? Obviously this wouldn't work very well in a web server module environment, but compiled as a CGI (for shell script style use), it is very handy. PHP seems pretty complete as far as console work goes, I have a 'standard' read ($prompt) function I can use that will determine the current TTY, open it, and get a line from the user. Readline is also extremely useful. My problem is with beutified output however. The day I untar php-x.xx.tar.gz and see ext/ncurses/php_ncurses.c flying past my terminal is a day I will be very preoccupied with code hacking into the early hours! My last 'feature request' is that of either a select () ability (I see 4.0.6 has a function called select in ext/standard/file.c (and ext/sockets/???.c) but I have not played with it), or another ability to read from files / fifos / character devices in a non-blocking way. Particularly, /dev/modem work is to my knowledge impossible at present. To round up, an ncurses module would be nice, a select function like that in C would be sex (!), a fork function (like that in C..). Thanks for your time taken reading the e-mail, and thanks for a bloody brilliant language (I have used it for web work too). If PHP had the above functionality, I can't see much left that stops it from being a rather complete and feature-packed general shell scripting language! (doh! signal handling would be nice too!) Cherio, -dw PS Another thing I noticed, I wrote a diary.php script that allows me 'ninja speed' access to an OpenSSL'd diary in a very secure way. The code behind it is relatively tight, yet when I run it strace'd, I notice that there are a good 50 or so getuid ()'s before the EDITOR is exec'd. The speed at which the program runs is fine, but I was just wondering if it might indicate an underlying problem, or is that just the nature of interpreted languages (not very optimal)! On request, I'll make diary.php available, I intend sticking it on a public site soon anyway. Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie -- PHP Development Mailing List http://www.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 #12768: wordwrap crashes with 4 parameters and width=0
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.6 PHP Bug Type: Reproducible crash Bug description: wordwrap crashes with 4 parameters and width=0 hi, i discovered a small bug in wordwrap. if you call this function with 4 parameters and a width of 0 your php-script will crash/timeout. pre ?php $string = the quick brown fox ...; echo wordwrap($string, 0, \n, 1),\n; ? /pre here is an inconsistency with the 2-parameter version, which returns all words separated by \n in this case regards marc -- Edit bug report at: http://bugs.php.net/?id=12768edit=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] Console Work
fork is already implemented, along with signals, waitpid, and all the wait.h macros in the pcntl extension. -Jason - Original Message - From: Dave Wilson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 15, 2001 11:04 AM Subject: [PHP-DEV] Console Work Hi there, I'm new to the list (only subscribed 2 mins ago!). I have subscribed a) to say bloody well done on a great language! and b) I am trying to find information on a few things related to console php (php -q)... First off, I wrote a small addition to ext/standard/exec.c that adds a fork () function. I haven't been testing it much yet (I've started to write a web server in it to see how well it works), but was wondering, is there a reason why the official PHP 4 currently lacks fork functionality? Obviously this wouldn't work very well in a web server module environment, but compiled as a CGI (for shell script style use), it is very handy. PHP seems pretty complete as far as console work goes, I have a 'standard' read ($prompt) function I can use that will determine the current TTY, open it, and get a line from the user. Readline is also extremely useful. My problem is with beutified output however. The day I untar php-x.xx.tar.gz and see ext/ncurses/php_ncurses.c flying past my terminal is a day I will be very preoccupied with code hacking into the early hours! My last 'feature request' is that of either a select () ability (I see 4.0.6 has a function called select in ext/standard/file.c (and ext/sockets/???.c) but I have not played with it), or another ability to read from files / fifos / character devices in a non-blocking way. Particularly, /dev/modem work is to my knowledge impossible at present. To round up, an ncurses module would be nice, a select function like that in C would be sex (!), a fork function (like that in C..). Thanks for your time taken reading the e-mail, and thanks for a bloody brilliant language (I have used it for web work too). If PHP had the above functionality, I can't see much left that stops it from being a rather complete and feature-packed general shell scripting language! (doh! signal handling would be nice too!) Cherio, -dw PS Another thing I noticed, I wrote a diary.php script that allows me 'ninja speed' access to an OpenSSL'd diary in a very secure way. The code behind it is relatively tight, yet when I run it strace'd, I notice that there are a good 50 or so getuid ()'s before the EDITOR is exec'd. The speed at which the program runs is fine, but I was just wondering if it might indicate an underlying problem, or is that just the nature of interpreted languages (not very optimal)! On request, I'll make diary.php available, I intend sticking it on a public site soon anyway. Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie -- PHP Development Mailing List http://www.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] Setting up RFC
Everyone loves to hate Perl don't they? Daniel - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Andrei Zmievski [EMAIL PROTECTED]; Zeev Suraski [EMAIL PROTECTED]; Sterling Hughes [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sæther Bakken @gecadsoftware.com [EMAIL PROTECTED] Sent: Wednesday, August 15, 2001 10:43 AM Subject: Re: [PHP-DEV] Setting up RFC Hi Andrei! On Wed, 15 Aug 2001, Andrei Zmievski wrote: On Wed, 15 Aug 2001, Zeev Suraski wrote: like. That's why the situation wouldn't change radically if/when the engine license changes, much like it wasn't any different *before* the engine license was even introduced, in the PHP 3.0 days. Having regulators over the 'kernel' of the project is certainly not very unique to the PHP, and had a significant role in bringing PHP to where it is today, and not where Perl is today, for example. You always compare PHP to Perl. How about Python? It's a well designed language that's pretty open for development.. Look at their PEPs system. maybe cause PHP it's better than Perl but not than Python? :) -- teodor -- PHP Development Mailing List http://www.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] Console Work
My last 'feature request' is that of either a select () ability (I see 4.0.6 has a function called select in ext/standard/file.c (and ext/sockets/???.c) but I have not played with it), or another ability to read from files / fifos / character devices in a non-blocking way. Particularly, /dev/modem work is to my knowledge impossible at present oh ya, socket_select in the sockets module is a full implementation of the C select To round up, an ncurses module would be nice, a select function like that in C /ext/ncurses would be sex (!), a fork function (like that in C..). Thanks for your time taken reading the e-mail, and thanks for a bloody brilliant language (I have used it for web work too). If PHP had the above functionality, I can't see much left that stops it from being a rather complete and feature-packed general shell scripting language! (doh! signal handling would be nice too!) Cherio, -dw PS Another thing I noticed, I wrote a diary.php script that allows me 'ninja speed' access to an OpenSSL'd diary in a very secure way. The code behind it is relatively tight, yet when I run it strace'd, I notice that there are a good 50 or so getuid ()'s before the EDITOR is exec'd. The speed at which the program runs is fine, but I was just wondering if it might indicate an underlying problem, or is that just the nature of interpreted languages (not very optimal)! On request, I'll make diary.php available, I intend sticking it on a public site soon anyway. Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie -- PHP Development Mailing List http://www.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] Console Work [woah]
ext/pcntrl/ ext/ncurses [!] select () Wooah! I posted 15 mins ago and, well, umm, that's the fastest and most complete response I've ever got from a list. :] PHP * :P -dw Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie -- PHP Development Mailing List http://www.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 #12767 Updated: Apache compile with php4.0.6
ID: 12767 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Old Bug Type: *Compile Issues Bug Type: Compile Failure Operating System: AIX 4.3.3.0 PHP Version: 4.0.6 New Comment: Could you please try the latest CVS snapshot from http://snaps.php.net/ since this should have been fixed already. --Jani Previous Comments: [2001-08-15 11:12:56] [EMAIL PROTECTED] Whenever I try to compile Apache server 1.3.20 including the libphp4.a module, make crashes with a code 8. It compiles just fine if I don't include the php directive. It is complaining about .alloc symbol. Edit this bug report at http://bugs.php.net/?id=12767edit=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] SAPI_API glitch
At 18:40 15-08-01, Daniel Beulshausen wrote: At 17:36 15.08.2001 +0200, Daniel Beulshausen wrote: At 18:20 15.08.2001 +0300, Zeev Suraski wrote: Is there any reason to have them even exported? I think we can just nuke SAPI_API altogether (I could be wrong, we might be referencing them somewhere, but I don't think we do) not sure, but we can add it later if it breaks :) no i just looked, they are (i.e. sapi_read_standard_form_data in the fdf extension) They are what? :) 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] weirdness on make install
This is with using the 4.0.6 release tarball. config and make work fine, but make install fails with a weird message I've never seen before: Making install in pear make[1]: Entering directory `/home/cmv/sources/php-4.0.6/pear' make[2]: Entering directory `/home/cmv/sources/php-4.0.6/pear' shtool:mkdir:Error: invalid number of arguments (at least 1 expected) shtool:mkdir:Hint: run `/home/cmv/sources/php-4.0.6/build/shtool mkdir -h' or `man shtool' for details +--+ | The installation process is incomplete. The following resources were | | not installed: | | | | Self-contained Extension Support | | PEAR: PHP Extension and Add-on Repository | | | | To install these components, become the superuser and execute: | | | | # make install-su | +--+ make[2]: *** [install-data-local] Error 5 make[2]: Leaving directory `/home/cmv/sources/php-4.0.6/pear' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/cmv/sources/php-4.0.6/pear' make: *** [install-recursive] Error 1 Yes, I am root when doing this. Configure line is: ./configure \ --with-apxs=/usr/local/apache/bin/apxs \ --enable-versioning \ --with-mysql=/usr/local/mysql \ --enable-sysvshm \ --enable-sysvsem \ --disable-debug \ --enable-track-vars \ --disable-magic-quotes \ --with-ttf \ --with-pear=/pear \ --with-config-file-path=/usr/local/php Now, this machine already has Apache with PHP3 compiled as a DSO. I'm just following the instructions in the manual about getting both working as DSOs. Ideas? - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: weirdness on make install
Nevermind ... I just saw the bug report and notice that it's fixed in CVS. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] SAPI_API glitch
At 19:33 15.08.2001 +0300, Zeev Suraski wrote: At 18:40 15-08-01, Daniel Beulshausen wrote: At 17:36 15.08.2001 +0200, Daniel Beulshausen wrote: At 18:20 15.08.2001 +0300, Zeev Suraski wrote: Is there any reason to have them even exported? I think we can just nuke SAPI_API altogether (I could be wrong, we might be referencing them somewhere, but I don't think we do) not sure, but we can add it later if it breaks :) no i just looked, they are (i.e. sapi_read_standard_form_data in the fdf extension) They are what? :) breaking using exported SAPI_POST_* functions. i conclude, they still should get exported. :) daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] SAPI_API glitch
At 20:20 15-08-01, Daniel Beulshausen wrote: At 19:33 15.08.2001 +0300, Zeev Suraski wrote: At 18:40 15-08-01, Daniel Beulshausen wrote: At 17:36 15.08.2001 +0200, Daniel Beulshausen wrote: At 18:20 15.08.2001 +0300, Zeev Suraski wrote: Is there any reason to have them even exported? I think we can just nuke SAPI_API altogether (I could be wrong, we might be referencing them somewhere, but I don't think we do) not sure, but we can add it later if it breaks :) no i just looked, they are (i.e. sapi_read_standard_form_data in the fdf extension) They are what? :) breaking using exported SAPI_POST_* functions. i conclude, they still should get exported. :) Why? Are modules using any SAPI_POST functions which are defined in PHP? If they are, we should probably change the SAPI_POST_HANDLER definition not to include SAPI_API, and add the SAPI_API explicitly before those functions which are referenced by modules. 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] SAPI_API glitch
At 20:23 15.08.2001 +0300, Zeev Suraski wrote: At 20:20 15-08-01, Daniel Beulshausen wrote: At 19:33 15.08.2001 +0300, Zeev Suraski wrote: At 18:40 15-08-01, Daniel Beulshausen wrote: At 17:36 15.08.2001 +0200, Daniel Beulshausen wrote: At 18:20 15.08.2001 +0300, Zeev Suraski wrote: Is there any reason to have them even exported? I think we can just nuke SAPI_API altogether (I could be wrong, we might be referencing them somewhere, but I don't think we do) not sure, but we can add it later if it breaks :) no i just looked, they are (i.e. sapi_read_standard_form_data in the fdf extension) They are what? :) breaking using exported SAPI_POST_* functions. i conclude, they still should get exported. :) Why? Are modules using any SAPI_POST functions which are defined in PHP? If they are, we should probably change the yep. SAPI_POST_HANDLER definition not to include SAPI_API, and add the SAPI_API explicitly before those functions which are referenced by modules. isn't that exactly what i meant in my first mail? :) we would use SAPI_API SAPI_POST... to export them and extensions should use PHP_EXT_API SAPI_POST... if they want to export their functions. daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] 4.0.7RC1 rolled
http://www.php.net/~zeev/php-4.0.7RC1.tar.gz (not mirrored) -- PHP Development Mailing List http://www.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] SAPI_API glitch
At 20:35 15-08-01, Daniel Beulshausen wrote: isn't that exactly what i meant in my first mail? :) I'm thick ;) 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 #12769: php.exe cannot execute
From: [EMAIL PROTECTED] Operating system: win2k server PHP version: 4.0.6 PHP Bug Type: Unknown/Other Function Bug description: php.exe cannot execute Event Type: Information Event Source: Application Popup Event Category: None Event ID: 26 Date: 8/15/2001 Time: 6:40:17 PM User: N/A Computer: SERVER Description: Application popup: php.exe - Application Error : The instruction at 0x100321e3 referenced memory at 0x00080bdc. The memory could not be read. Click on OK to terminate the program -- Edit bug report at: http://bugs.php.net/?id=12769edit=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 #12769 Updated: php.exe cannot execute
ID: 12769 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Unknown/Other Function Operating System: win2k server PHP Version: 4.0.6 New Comment: We here are not at Microsoft, so we can't guess the error from that number. Please post your script in the report too. Derick Previous Comments: [2001-08-15 13:38:02] [EMAIL PROTECTED] Event Type: Information Event Source: Application Popup Event Category: None Event ID: 26 Date: 8/15/2001 Time: 6:40:17 PM User: N/A Computer: SERVER Description: Application popup: php.exe - Application Error : The instruction at 0x100321e3 referenced memory at 0x00080bdc. The memory could not be read. Click on OK to terminate the program Edit this bug report at http://bugs.php.net/?id=12769edit=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 #12770: ODBC and PHP help needed.. Advanced
From: [EMAIL PROTECTED]
Operating system: win98 with PWS
PHP version: 4.0.6
PHP Bug Type: ODBC related
Bug description: ODBC and PHP help needed.. Advanced
What i want to do is retrieve data from a table in access using odbc. I can
retrieve info correctly, except from when i want to retrieve specific
information.
I want to create a table on a webpage that retrieves a column of info, and
uses this info to make a link. With this link there will be a querystring
called id, and this comes from the ID field in my DB which i also have
retrieved using my select statement.
So how do i use odbc_result and odbc_fetch_row together to achieve this. Or
is there another method using ODBC that i dont have knowledge of.
Beneath is my code::
Thnx in advance
HTML
HEAD
TITLEMXManiaWorld :: Tracks - Download/TITLE
STYLE TYPE=text/css
TH {color: white; background-color: gray}
TD {background-color: silver; text : black }
/STYLE
/HEAD
BODY bgcolor=navy text=
CENTER
?php
//retrieve data from DB and show in browser.
//Img, then at side details.
//Declare DB variables
$odbc_dsn = 'mxm_db';
$odbc_userid = '**';
$odbc_userpassword = '**';
//CONNECT to DB
if(!($odbc_db=odbc_connect($odbc_dsn, $odbc_userid,
$odbc_userpassword)))
die(Couldn't connect to odbc database - $odbc_dsn);
//---
echo TABLE WIDTH='98%' border='1' bordercolor='#ff';
$query2 = SELECT ID, FileName FROM tbl_uploads;
//submit query
if(!($odbc_rs2 = odbc_exec($odbc_db, $query2)))
die(Error executing query. Please inform the webmaster);
?
TRTHID/THTHTrackname/TH/TR
?php
while($query_data = odbc_fetch_row($odbc_rs2)) {
$num_cols = odbc_num_fields($odbc_rs2);
for($a = 1; $a = $num_cols; $a++) {
if(!($track_id = odbc_result($query2, $a)))
die(Couldn't get result);
if(!($tracks = odbc_result($query2, $a)))
die(Couldn't get result) ;
echo TR;
echo TD$track_id/TD;
echo TDa href='./tracks.php?id= . $track_id . ' . $tracks .
/a;
echo /TD/TR;
}
}
echo /TABLE
?
/CENTER
/BODY
/HTML
--
Edit bug report at: http://bugs.php.net/?id=12770edit=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] Engine 2
Fresh tree doesn't build w/ ZE2: zend_variables.c: In function `zval_persist': zend_variables.c:155: structure has no member named `properties' zend_variables.c:156: structure has no member named `properties' *** Error code 1 Stop in /usr/local/src/php4/Zend. *** Error code 1 Stop in /usr/local/src/php4. At 16:20 8/10/2001, Andi Gutmans wrote the following: -- Hey, The Engine 2 CVS pretty much implements the first step of the new object model. Objects are now handles which reference the same object and $obj-method1()-method2() is supported now. Quite a few places in PHP that use objects like call_user_function() might still not work though. If anyone can try and run PHP with the Engine 2 CVS and send feedback on how well or badly their old object code runs that'll be great. I'm also interested in how many scripts are actually broken by the fact that objects are not copied when sent to functions by value and so on. To check it out just checkout the ZendEngine2 CVS tree from cvs.zend.com and rename it from ZendEngine2 - Zend before building PHP. 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] --end of quote-- [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12771: new_object_array()
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.0.6
PHP Bug Type: Feature/Change Request
Bug description: new_object_array()
I was hoping that the dynamic creation of objects could be extended to
support it's parameters in an array format like the functions
call_user_method_array and call_user_func_array(). This would be great for
test suites.
eg
function test_suite_object_test($class, $args) {
if (!class_exists($class)) error();
else {
$obj = new_object_array($class, $args);
...
futher tests on the object
...
}
}
This would useful, not having to hard code the constructors parameter
list, with obvious limitations, with something like:
function test_suite_object_test($class, $arg1, $arg2, $arg3, $arg4) {
if (!class_exists($class)) error();
else {
$obj = new $class($arg1, $arg2, $arg3, $arg4);
...
futher tests on the object
...
}
}
--
Edit bug report at: http://bugs.php.net/?id=12771edit=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] Setting up RFC
On Wed, 15 Aug 2001, Zeev Suraski wrote: At 12:15 15-08-01, Sterling Hughes wrote: On Wed, 15 Aug 2001, Zeev Suraski wrote: At 10:23 15-08-01, Stig Sæther Bakken wrote: [Hi, I think one of the problems with this is that even if php-dev comes up with a system for determining which feature it wants to see in PHP, we still depend on Zeev, Andi or someone else @ Zend to implement them. An RFC system would be a support for Zend's decision-making. At the end of the day, due to the licensing issues, php-dev is not the body governing the language, it has an advisory role only. Generally, I agree with you, except it's not because of licensing issues (will we end up with a load of features suddenly getting into PHP if/when the engine license changes?). Many other projects behave that way. With a language definition, vox populi, vox Dei doesn't tend to work very well. Yes, the difference is, this creates a situation where the PHP Development team does not have control of the core language, Zend Technologies Ltd. does. Whether this is a issue with a basis in principle or a basis in practicality is up to debate, however, the problem remains. Sterling, that's bull - popular perhaps - but still, bull. Zend as a commercial entity doesn't decide on PHP's features. Nobody in Zend has control over the language just because he's a Zend employee. Other Zend employees participate in the discussions just like the rest of you, and often make quite constructive remarks, just like the rest. However, it's not as if Zend employees can muck around the language, whereas php-dev can just stand on the side watching. We all like to look up at corporations, blame them for the problems and rebel. It's basic human nature. It just has very little to do with reality in this case. Nothing, in practice, except for that license everybody enjoys bashing (and I claim again and again, that it won't make a radical change if it changes, except for perception). Andi and myself regulate the engine, on a personal basis, since 1997, and it has nothing to do with Zend (which was founded towards the end of 1999). Between us, as a commercial entity, nobody could care less whether there are advices, namespaces or how exactly the object model would look like. That's why the situation wouldn't change radically if/when the engine license changes, much like it wasn't any different *before* the engine license was even introduced, in the PHP 3.0 days. Having regulators over the 'kernel' of the project is certainly not very unique to the PHP, and had a significant role in bringing PHP to where it is today, and not where Perl is today, for example. Oh - I see! So the Zend on the License is really just shorthand for Zeev and Andi, has nothing to do with Zend Technologies Ltd. Good to know. ;)) As I said -- this may have no basis in practicality -- I think it does to some extent, otherwise you wouldn't hear this many reasonable (but sometimes passionate) people complaining. Still, taking your assumption that the license and Zend's control of it is meaningless, why not go ahead and change the license today? If it means nothing, why are you with a license that causes such strife in the PHP community? If you'd like, I'll go setup a sourceforge project for the Zend engine today! -Sterling -- PHP Development Mailing List http://www.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 #12766 Updated: easter_days breaks for year before 1753
ID: 12766
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Calendar related
Operating System: Linux 2.4.x
PHP Version: 4.0.6
New Comment:
Based on the documentation for the easter_days command, this behaviour would appear to
be deliberate. It seems that the easter calculation is changed over to the Julian
formula for all dates prior to 1753, because that is the year that Britain and its
colonies finally switched to the Gregorian calendar. However, that does not change the
fact that since 1582, the rest of Europe was using the Gregorian calendar.
This being the case, it would make since to be able to calculate the date of Easter
for the range 1582-1752 using either the Julian formula (which is simply based on
cycles of the moon) or the Gregorian formula (which is far more complex). To implement
this, an optional switch could be added to the easter_days function which defaults to
the Julian formula for that date range, but allows the user to specify the Gregorian
formula instead.
Previous Comments:
[2001-08-15 10:51:32] [EMAIL PROTECTED]
The easter_days function returns bad data for years = 1752. Here is a way to verify.
Because Easter always falls on a Sunday, the following function should always return
Sunday:
function EasterDOW($year) {
$jdayc = easter_days($year);
$jdmar21 = gregoriantojd(3, 21, $year);
$jdeaster = $jdmar21 + $jdayc;
return JDDayOfWeek($jdeaster, 1);
}
The formula for calculating easter has been the same since 1582. The standerd Delambre
Easter algorithm is able to generate the date of easter for any gregorian date after
1582. The following function may be used to duplicate the functionality of easter_days
for any date since 1582:
function easter_days2($year) {
#First calculate the date of easter using
#Delambre's algorithm.
$a = $year % 19;
$b = floor($year / 100);
$c = $year % 100;
$d = floor($b / 4);
$e = $b % 4;
$f = floor(($b + 8) / 25);
$g = floor(($b - $f + 1) / 3);
$h = (19 * $a + $b - $d - $g + 15) % 30;
$i = floor($c / 4);
$k = $c % 4;
$l = (32 + 2 * $e + 2 * $i - $h - $k) % 7;
$m = floor(($a + 11 * $h + 22 * $l) / 451);
$n = ($h + $l - 7 * $m + 114);
$month = floor($n / 31);
$day = $n % 31 + 1;
#Return the difference between the JulianDayCount
#for easter and March 21'st of the same year,
#in order to duplicate the functionality of the
#easter_days function
return GregorianToJD($month, $day, $year) - GregorianToJD(3,21,$year);
}
Edit this bug report at http://bugs.php.net/?id=12766edit=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] Please..
On Wed, 15 Aug 2001, Zeev Suraski wrote: At 13:41 15-08-01, Sascha Schumann wrote: If you feel like bickering, go on bicker and make populist statements as much as you'd like, just let the rest of us do what we're good at, which is developing PHP. Perhaps setting up a separate mailing list like Sterling suggested, a-la [EMAIL PROTECTED] isn't such a bad idea. Thanks for proving that you are not interested in a dialogue. If bickering is your definition of dialogue then all I can say is - you're quite welcome! What's your definition of dialogue? I'm more than welcome to accomidate you, and Zend, so we can get these issues resolved instead of having these constant bad feelings. The reason I'm speaking out is that its beginning to make PHP something that is no longer enjoyable to develop for -- and the project is important enough to me -- that I'd rather see this resolved to some level than just forget it all together. I would be happy to talk on a temporary list, which could perhaps contain all interested parties -- or all effected parties (invite only, to make it a smaller group). -Sterling Ps: Jani sometimes I feel the same way, but ignore this problem is just going to make it bigger, its been ignored for awhile now, and is slowly causing an explosion. -- PHP Development Mailing List http://www.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] Please..
Hi, I'm more than welcome to accomidate you, and Zend, so we can get these issues resolved instead of having these constant bad feelings. As I wrote in my last email, what are those issues -- it would be nice to have them outlined in a comprehensible manner instead of, as now, they being implicitly refered to in various snide comments. A lot of people may have an opinion on these issues, and unless they know what they are, there cannot be a semi-democratic, let alone open way to discuss them. Kind regards, David. -- PHP Development Mailing List http://www.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 #12635 Updated: href=#botton gives wrong url
ID: 12635 Updated by: jeroen Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: ? PHP Version: 4.0.4 New Comment: php could refrain from inserting the session_id if the link contains only an anchor (like: href=#bottom), because this means that the page is not to be reload. But that's exactly what it does (as of 4.0.4, according to CVS, tested that it works right with 4.0.4pl1)! Therefore, there is no bug in PHP=404, see the html-source! (there was a bug, however, in PHP=403 And PHP has nothing to do with how browsers handle things... Previous Comments: [2001-08-15 08:26:55] [EMAIL PROTECTED] You are right that there is no bug so far as concerns the position of #bottom. I tried with Explorer 4.5: link no 1, 2 and 4 are OK, but still the page is reloaded. With Netscape 4.6 the first link does not work. Maybe it also depends on the reload preferences of the navigator. So all this is rather tricky, isn't it ? But what about the following suggestion: php could refrain from inserting the session_id if the link contains only an anchor (like: href=#bottom), because this means that the page is not to be reload. [2001-08-13 15:45:13] [EMAIL PROTECTED] Sorry, I put protection 777, but that was too much. Now it should work : http://webcour.swisszone.ch/a/essais/session.php?f=1 [2001-08-12 19:59:47] [EMAIL PROTECTED] Works correctly (that #bottom is left alone) since oktober 2000 (version 1.17 of ext/standard/url_scanner_ex.re) That means it worked since 4.0.4 exactly. (I only tested 4.0.7, so I'm not 100% certain) And I was correct that # came _after_ the ?, so there's no bug (anymore). [2001-08-12 18:11:48] [EMAIL PROTECTED] http://webcour.swisszone.ch/a/essais/session.php?f=1 Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, root@localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request. Apache/1.3.14 Server at www.webcour.swisszone.ch Port 80 [2001-08-11 17:53:17] [EMAIL PROTECTED] Try the following file: http://webcour.swisszone.ch/a/essais/session.php?f=1 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=12635 Edit this bug report at http://bugs.php.net/?id=12635edit=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 #12723 Updated: Addition to bug 12507
ID: 12723 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Scripting Engine problem Operating System: RedHat 6.2 (2.2.19) PHP Version: 4.0.6 New Comment: Have been running past two days with out problem. Did a total recompile of apache+php+patch and have not seen any issues. Peter Previous Comments: [2001-08-13 14:30:42] [EMAIL PROTECTED] You may notice the the file is libphp4.so.bak - it is the same file as libphp4.so that the server is running. Peter [2001-08-13 14:26:32] [EMAIL PROTECTED] You may notice the the file is libphp4.so.bak - it is the same file as libphp4.so that the server is running. Peter [2001-08-13 14:22:48] [EMAIL PROTECTED] I have noticed the same problem as the user in bug #12507. [root@www libexec]# mtrace ./libphp4.so.bak Memory not freed: - Address Size Caller 000 at __ This version has the php-4.0.6-memlimit.diff patch applied. A few httpd processes will consume large amounts of memory and processor, Apache must be stopped and restarted to free it. We did not notice these issues untill v4.0.5/4.0.6 _ System Linux www..com 2.2.19pre7 #1 SMP Wed Jan 24 17:04:44 CST 2001 alpha unknown Build Date Aug 13 2001 Configure Command './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-config-file-path=/usr/local/apache' '--with-gd' '--with-zlib' '--with-gettext' '--enable-versioning' '--enable-inline-optimization' '--disable-debug' '--enable-memory-limit' '--disable-display-source' '--enable-sysvshm' '--enable-sysvsem' '--with-mysql=/usr' '--with-bz2' '--with-freetype' '--enable-shared' Server API Apache Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/apache/php.ini ZEND_DEBUG disabled Thread Safety disabled ___ memory_limit 24M 24M _ APACHE_INCLUDE APACHE_TARGET Apache Version Apache/1.3.20 Apache Release 10320100 Apache API Version 19990320 Hostname:Port www.goquest.com:80 User/Group nobody(99)/99 Max Requests Per Child: 1brKeep Alive: onbrMax Per Connection: 75 Timeouts Connection: 300brKeep-Alive: 15 Server Root /usr/local/apache Loaded Modules mod_gzip, mod_php4, mod_setenvif, mod_access, mod_so, mod_auth, mod_alias, mod_userdir, mod_asis, mod_cgi, mod_dir, mod_autoindex, mod_include, mod_status, mod_negotiation, mod_mime, mod_log_config, mod_env, mod_php3, http_core Peter Edit this bug report at http://bugs.php.net/?id=12723edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] 4.0.7RC1 rolled
Done! At 21:32 15-08-01, Jani Taskinen wrote: Could you add a symbolic link for it: php-4.0.7RC-latest.tar.gz And keep that linked to the latest. --Jani On Wed, 15 Aug 2001, Zeev Suraski wrote: http://www.php.net/~zeev/php-4.0.7RC1.tar.gz (not mirrored) -- 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] problem with gcc datetime
i'm getting a rather wierd problem here. i'm trying a standard make of the php source (actually of the php-4.0.6 source.) i keep getting this compile error on the datetime.c file. i've also gone to cvs and grabbed the latest datetime.c and gotten the same results. is anyone else getting something simular. this is on a win2k box with cygwin. i also included an version of gcc at the bottom if it any help . . . - gcc -I. -I//e/php-4.0.6/ext/standard -I//e/php-4.0.6/main -I//e/php-4.0.6 - I//e /php-4.0.6/Zend -I//e/php-4.0.6/ext/mysql/libmysql -I//e/php-4.0.6/ext/xml/e xpat /xmltok -I//e/php-4.0.6/ext/xml/expat/xmlparse -I//e/php-4.0.6/TSRM -DSUPPO RT_U TF8 -DXML_BYTE_ORDER=12 -g -O2 -c datetime.c touch datetime.lo datetime.c: In function `php_mktime': datetime.c:188: wrong type argument to unary minus datetime.c: In function `php_date': datetime.c:442: invalid operands to binary / datetime.c:442: invalid operands to binary % datetime.c:450: wrong type argument to unary minus datetime.c:450: wrong type argument to unary minus datetime.c:503: invalid operands to binary / datetime.c:504: invalid operands to binary % datetime.c: In function `php_if_checkdate': datetime.c:693: too many arguments to function `is_numeric_string' make[3]: *** [datetime.lo] Error 1 make[3]: Leaving directory `//e/php-4.0.6/ext/standard' $ gcc --version 2.95.3-5 - Chris Gardner Book Systems, Inc. [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] Setting up RFC
At 21:24 15-08-01, Sterling Hughes wrote: Oh - I see! So the Zend on the License is really just shorthand for Zeev and Andi, has nothing to do with Zend Technologies Ltd. Good to know. ;)) In practice, pretty much, yes. I don't remember Doron's, Adi's or Daniel's last contributions :) As I said -- this may have no basis in practicality -- I think it does to some extent, otherwise you wouldn't hear this many reasonable (but sometimes passionate) people complaining. Still, taking your assumption that the license and Zend's control of it is meaningless, why not go ahead and change the license today? If it means nothing, why are you with a license that causes such strife in the PHP community? A small part in the PHP developer community, mind you. As I told Stig, it is what you make of it - practically, it's nothing. If you'd like, I'll go setup a sourceforge project for the Zend engine today! I don't want to see the engine as a sourceforge project today, tomorrow, or anytime in the future, thank you very much :) As I said in LinuxTag, the license issue was blown out of proportion completely. It has no practical meaning for any PHP user or developer. Changing the license only means that we will no longer be able to re-license the engine to other companies who make commercial use of it. So basically, changing it means a loss of a source of possible income for Zend, while giving the PHP community nothing (MySQL AB *lives* from that source of income exactly). Perception wise, it might make the world much more rosy. To be bluntly honest, I seriously doubt it (we're not in a bad shape today, plus I have every reason to believe that things won't change radically ifwhen we change the license). As far as Zend is perceived, much like the license issue was a non issue until some made it an issue, I fear that once it's gone, there'll be something else to replace it. When you don't like somebody or something, you can find whatever suite of 'objective' reasons to back you up. 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 #12733 Updated: cURL crash (reproducible)
ID: 12733 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: cURL related Operating System: Linux 2.2.19-x86 PHP Version: 4.0CVS-2001-08-14 New Comment: Its a cURL bug (so quoth the author of cURL). the problem is your supplying the CURLOPT_POST argument, but no postfields. this will be fixed in cURL's cvs. Previous Comments: [2001-08-14 03:14:44] [EMAIL PROTECTED] PHP - latest CVS curl 7.8 (i686-pc-linux-gnu) libcurl 7.8 (SSL 0.9.5) OpenSSL 0.9.6b 9 Jul 2001 I've just noticed the version problem in the curl line above even tho they're all fresh compiles. It may bea curl bug but I'll file here just in case. Script is in SOAP/Client.php in PEAR repository. Running test scropt also in the repository causes segfault either in http or https Relevant code is: curl_setopt($ch, CURLOPT_HTTPHEADER, array(Content-Type: text/xml)); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_FAILONERROR, 1); curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); curl_setopt($ch, CURLOPT_USERAGENT, $this-_userAgent); curl_setopt($ch, CURLOPT_RETURNTRANSFER,1); curl_setopt($ch, CURLOPT_VERBOSE,1); curl_setopt($ch, CURLOPT_POST, 1); $result=curl_exec ($ch); curl_close ($ch); Backtrace: #0 0x40091d11 in Curl_http (conn=0x8282860) at http.c:771 #1 0x40097dc2 in Curl_do (conn=0x8282860) at url.c:2308 #2 0x4009f50e in Curl_perform (curl=0x8275a50) at transfer.c:868 #3 0x4009f818 in curl_easy_perform (curl=0x8275a50) at easy.c:163 #4 0x808118d in zif_curl_exec (ht=1, return_value=0x8273bf4, this_ptr=0x0, return_value_used=1) at curl.c:841 #5 0x8117a96 in execute (op_array=0x8261b5c) at ./zend_execute.c:1589 #6 0x8117c8a in execute (op_array=0x8246e4c) at ./zend_execute.c:1629 #7 0x80ff1ed in zend_execute_scripts (type=8, file_count=3) at zend.c:806 #8 0x807a558 in php_execute_script (primary_file=0xba64) at main.c:1308 #9 0x80788eb in main (argc=3, argv=0xbac4) at cgi_main.c:737 Edit this bug report at http://bugs.php.net/?id=12733edit=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] CVS Compile Problem
Hi, if anyone has a moment, could you tell me what I'm doing wrong? Along with the checked out PHP CVS I took today, I also downloaded and compiled the latest libtool, autoconf, and automake (as recommended) to avoid any difficulty. I compiled all three tools in /usr (--prefix=/usr). When I tried to compile PHP, I got the following problem: ./aclocal.m4:813: error: m4_defn: undefined macro: _m4_divert_diversion ./aclocal.m4:359: PHP_SUBST is expanded from... ./aclocal.m4:813: the top level autoconf: tracing failed Upon attempting to php-ize the particular module I wanted (ext/pcntl; i didn't expect this to work): aclocal: macro `AC_ADD_LIBPATH' defined in acinclude.m4 but never used aclocal: macro `AC_ADD_LIBRARY_WITH_PATH' defined in acinclude.m4 but never used aclocal: macro `AC_ADD_LIBRARY' defined in acinclude.m4 but never used aclocal: macro `AC_ADD_INCLUDE' defined in acinclude.m4 but never used ./aclocal.m4:813: error: m4_defn: undefined macro: _m4_divert_diversion ./aclocal.m4:359: PHP_SUBST is expanded from... ./aclocal.m4:813: the top level ./aclocal.m4:813: error: m4_defn: undefined macro: _m4_divert_diversion ./aclocal.m4:359: PHP_SUBST is expanded from... ./aclocal.m4:813: the top level autoconf: tracing failed You should update your `aclocal.m4' by running aclocal. Running aclocal like it asks produces the following warnings: aclocal: macro `AC_ADD_LIBPATH' defined in acinclude.m4 but never used aclocal: macro `AC_ADD_LIBRARY_WITH_PATH' defined in acinclude.m4 but never used aclocal: macro `AC_ADD_LIBRARY' defined in acinclude.m4 but never used aclocal: macro `AC_ADD_INCLUDE' defined in acinclude.m4 but never used -- If any of this makes sense, I'd be grateful for a reply. Cheers. Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie -- PHP Development Mailing List http://www.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 #12747 Updated: ***BUG in Autoconf--please report***
ID: 12747 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Compile Failure Operating System: Mandrake Linux 8.0 PHP Version: 4.0CVS-2001-08-14 New Comment: Thanks. I had libtool installed in /usr/local while the others are in /usr. Previous Comments: [2001-08-15 03:12:57] [EMAIL PROTECTED] I think your cvs checkout isn't quite 'clean'. Try to do a clean checkout first. To be sure which tools PHP finds, run: # build/buildcheck.sh As the first error would indicate that there is something wrong with those.. --Jani [2001-08-14 20:05:37] [EMAIL PROTECTED] autoconf-2.13-7.mdk automake-1.4-15mdk libtool-1.4 Trying to compile the cvs version of PHP. After updating from the CVS server and running ./buildconf. [onaias@frodo php4]$ ./buildconf aclocal: configure.in: 895: macro `AM_PROG_LIBTOOL' not found in library rebuilding Makefile templates rebuilding Makefile templates rebuilding configure autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_ADD_INCLUDE configure.in:442:PHP_AC_BROKEN_SPRINTF rebuilding main/php_config.h.in [onaias@frodo php4]$ Edit this bug report at http://bugs.php.net/?id=12747edit=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] Linux Today Article
http://linuxtoday.com/news_story.php3?ltsn=2001-08-13-009-20-OP This guy claims that PHP has been 'left in the dust' by ASP.NET. Any truth in that observation? Has anyone tried it (ASP.NET and the whole .NET thingy). Edin From the article: There will be Apache defenders who will bristle at the suggestion that it is a vanilla webserver. Look at PHP, they will say. PHP actually has greater market share than ASP. You can build fantastic web applications with PHP at a fraction of the cost of any commercial alternatives, including Microsoft. That's great, but when will PHP grow to become something more than a web scripting language? Where is the PHP enterprise component architecture? What about clustering and failover? Where are the WSDL and UDDI implementations? Don't show me bits and pieces here and there. Show me a framework. Show me a reference implementation. Show me a friendly interface. Not there yet? So PHP has been left in the dust as well, while ASP is morphing into ASP.NET, the browser delivery front-end of the Microsoft web services platform. -- PHP Development Mailing List http://www.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: libmysql and MS Visual Studio .NET
Michael Widenius wrote: The fix is to change in strtoll.c the define LONGLONG to USE_LONGLONG and do the same change in strto.c libmysql now builds fine, but the stranke linkage error (Unresolved external symbol _bc_out_num in function _pn) remains. As far as I can tell, this is not a MySQL issue. Thanks for your help, Monty, Sebastian -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.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] Linux Today Article
Edin Kadribasic wrote: Where is the PHP enterprise component architecture? What exactly would that be? What about clustering and failover? This has nothing to do with the language, IMHO, but with the platform, ie. the web server. I guess there are solutions to provide clustering and fail-over to Apache and MySQL, for instance. Where are the WSDL and UDDI implementations? What are WSDL and UDDI? Are there libraries out there can be wrapped into an extension? Show me a framework. Horde is a framework, and I guess there are some more out there. But I fear that there is truth in this. We should analyze what, besides the upcoming changes on the language level (with the Zend Engine 2.0), we need to make PHP compatible with ASP.NET. Maybe Zend has some feedback from their enterprise clients on what features are requested, etc. -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.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] Setting up RFC
[Sterling Hughes [EMAIL PROTECTED]] On Wed, 15 Aug 2001, Zeev Suraski wrote: At 10:23 15-08-01, Stig Sæther Bakken wrote: [Hi, I think one of the problems with this is that even if php-dev comes up with a system for determining which feature it wants to see in PHP, we still depend on Zeev, Andi or someone else @ Zend to implement them. An RFC system would be a support for Zend's decision-making. At the end of the day, due to the licensing issues, php-dev is not the body governing the language, it has an advisory role only. Generally, I agree with you, except it's not because of licensing issues (will we end up with a load of features suddenly getting into PHP if/when the engine license changes?). Many other projects behave that way. With a language definition, vox populi, vox Dei doesn't tend to work very well. Yes, the difference is, this creates a situation where the PHP Development team does not have control of the core language, Zend Technologies Ltd. does. Whether this is a issue with a basis in principle or a basis in practicality is up to debate, however, the problem remains. Zend having control of the language has nothing to do with vox Populi, vox Dei (translated the voice of the People, the voice of the Gods), its more of a matter of *who* has control -- Zend Technologies or the PHP Developers. Historical note: we had, ahem, feature discussions in 3.0 before Zend existed, so it doesn't have only to do with the fact that Zend is a commercial company. An important issue here is that for us, control of the language also means writing code. Granted, there's reduced motivation for people willing to dive into the Zend code, since their contributions would become the property of Zend, but so far Andi Zeev are probably the only members of the community who understand the code well enough to implement stuff like ticks and namespaces. So there's really no point in broadening the control of the language until Zend has a license that makes people like Sascha willing to put a lot of their time into the Zend code. Kristian thinks a dual GPL/QPL license would be a good idea for Zend (it apparently works for Troll Tech), but that's _definitely_ for another thread. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12772 Updated: gd functions saving jpgs in blue/black/white/grey
ID: 12772 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Old Operating System: w2k Operating System: w2k/NT 4.0 PHP Version: 4.0.6 New Comment: I tested this and found the same problem is also happening with WinNT 4.0 Previous Comments: [2001-08-15 16:17:54] [EMAIL PROTECTED] (using IIS 5.0) I upgraded php 4.0.4 to 4.0.6. I had these lines in my code to resize images: $im2 = ImageCreate($twidth,$theight) or die(couldn't create image); ImageCopyResized($im2,$im,0,0,0,0,$twidth,$theight,$width,$height); ImageJpeg($im2, $dir_root.$files[$i]); with the old 1.6 version of the gd dll, the resize worked fine, but the new version is saving these pictures in shades of blue and black and sometimes grey and black. Is this maybe an Indian issue? To test, I didn't touch the php version but simply replaced the new 2.0 gd dll with the old 1.6 gd dll and the pictures went back to full color when being resized. Please let me know when this dll is fixed so I can implement it, for now I'm leaving the old gd dll in my extensions folder. Edit this bug report at http://bugs.php.net/?id=12772edit=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 #12773: gethostbyname with timeout
From: [EMAIL PROTECTED] Operating system: PHP version: 4.0.6 PHP Bug Type: Feature/Change Request Bug description: gethostbyname with timeout gethostbyname can appear to hang indefinitely; I assume that this happens if the expected DNS responses are not forthcoming. Unfortunately if this happens in a webpage it can cause a cache or browser timeout, losing the entire page. A variant of this function with an optional timeout parameter would solve this problem. -- Edit bug report at: http://bugs.php.net/?id=12773edit=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]
